Remote authorization required even for building locally

[pziggo]

I am trying to build a project locally that has a dependency on boost. While compiling the dependencies the build gets stuck at the configuring stage with the following last lines before it fails without a reasoning after a very long time:

[...]
Compiling "." for linux-cxx17
⏳ {iguring          conf}

After enabling verbose mode -vv, the reasoning becomes more obvious:

[tipi.build] provide_dependency for Boost
[tipi.build] retrieving https://github.com/boostorg/boost.git, rev: 32da69a36f84c5255af8a994951918c258bac601 
[tipi.build] attempting restore in /workspaces/vsomeip.b/a4d7881/bin/_deps/boost-src 
tipi needs your tipi.build account to work remotely, authorize this machine by visiting: 

         https://tipi.build/dashboard/tokens/validate?exchange=<ID>


         Pairing code : XXXXX

Expected behaviour
Since I was following the documentation to build locally, I would not expect tipi to build dependencies remotely or require authentication to a remote service. Also, the actual authentication request should not be hidden without enabling verbose output and timeout with no indication why.

Repro available here:
https://github.com/pziggo/vsomeip/tree/8fe616d0e239eb86f9731555e361ad15974c8ea1
https://github.com/pziggo/vsomeip/tree/9297983453c752adee6bdf98ca612ec27d0e0ecf

tipi version: v0.0.55

.tipi/deps:

{
   "u" : true,
    "boostorg/boost": { "@" : "boost-1.80.0", "u" : true }
}

tipi command: tipi -t linux-cxx17 .
tipi command:

export CMAKE_TIPI_PROVIDER_ENABLE=ON
tipi -t linux-cxx17 -u .

[daminetreg]

Thank you for this report, it looks like you activated the early-preview feature from cmake-tipi-provider by exporting on the environment export CMAKE_TIPI_PROVIDER_ENABLE=ON. This enabled build caching and faster build restore for FetchContent dependency.

Did you export CMAKE_TIPI_PROVIDER_ENABLE=ON ? Because if not I cannot make sense of the report.

It's requesting access to the tipi.build api to access the remote build cache feature.

This output that you see should come only when FetchContent is used, I cannot find any FetchContent call in your project linked :

https://github.com/pziggo/vsomeip/tree/8fe616d0e239eb86f9731555e361ad15974c8ea1

Am I missing something from your project ?

If this is the setup I'm assuming, you don't need a .tipi/deps file. It is fully redundant, when CMAKE_TIPI_PROVIDER_ENABLE is ON, FetchContent is the way to provide dependency. You can mix both but not recommended in my eyes.

But It's a pretty new feature, so we are learning from use cases.

[daminetreg]

To reply to the question in the title, you can use -n on the tipi command line -n, --no-refresh to have no remote connections (unless it needs to clone the dependency from github because it never was).

[pziggo]

Indeed, my bad. Yes, I am experimenting with the new cmake-tipi-provider, exported the variable and have set FetchContent accordingly. Forgot to push the corresponding changes:
https://github.com/pziggo/vsomeip/tree/9297983453c752adee6bdf98ca612ec27d0e0ecf

tipi command:

export CMAKE_TIPI_PROVIDER_ENABLE=ON
tipi -t linux-cxx17 -u .

Thanks for the info about redundant .tipi/deps (was already wondering if maintaining the dependency references twice is really necessary).

Updated the PR message accordingly.

[daminetreg]

Thanks. Currently cmake-tipi-provider will likely not work with -n but it's true that this should be forwarded, so that if the cache is already available locally it doesn't try to search for it in the user-scoped remote build cache.

[pziggo]

Yeah, with the following cmdline tipi -t linux-cxx17 . -u -v -n the build still gets stuck at the remote authorization point. I would still expect that local builds stay local even with the new provider enabled. Or the documentation should clearly state that the provider can only be used with a subscription which is also fine.