tipi-build / cli Goto Github PK

View Code? Open in Web Editor NEW

12.0 12.0 0.0 18.18 MB

tipi command line client releases

Home Page: https://tipi.build

License: Other

Shell 34.71% PowerShell 65.29%

cli's People

Contributors

Stargazers

Watchers

cli's Issues

[Windows] Systems that have PATH and Path case sensitive environment variable fails to start any action

The windows process fails with "CreateProcess : executable file not found" or "CreateProcess: Access Denied" when there is a mismatch in case sensitivity of the Path and PATH variable in windows.

This is due to a bug in which tipi only appends path from it's distro tool to the "Path" variable and not the "PATH" one.

It's possible to work it around by going in the system environment and clicking : Edit Variable Text, then one can make sure the casing is the official windows one : "Path".

Some APIs don't make the difference between Path and PATH but the winapi one to set such var do.

Install script has some note about "tipi.io" in error message

cli/install/install_for_windows.ps1

Line 79 in 578bb5e

 Abort "Installation failed, please contact us via tipi.io. We would be happy to help you." 

tipi build and toolchain isolation

Currently tipi remote build are perfectly reproducible and isolated as an environment is created for them, however for local builds our CMake toolchains are not always correct in selecting only tipi provided tooling.

At the moment we have the following known issues :

Ensure the right compiler is used currently on windows if a clang.exe is available it will find this one.
- (https://cmake.org/cmake/help/latest/command/find_program.html, step 2 is looking in the CMAKE_PREFIX_PATH and the 5th is looking in the system PATH variables only, )
On macos the standard libary from the system might be taken instead of the libc++ clang provided one.

As soon as we solve that we can also generalize the build cache for local use.

tipi cannot be installed by default on a fresh Windows

tipi cli doesn't ship vcredist and a fresh windows installation without any other tools fails.

Fetching boost submodule as dep fails with object not found

I am trying to build a project locally that has a dependency on boost. While fetching the boost dependency, tipi runs into an exception claiming that the corresponding SHA1 of the submodule could not be found.

[...]
Initializing submodule context
⣻ Indexing - 100.00% (objects: 7645 of 7645 / deltas: 4872 of 4872)
⏳ done.          
● [err] Dynamic exception type: std::runtime_error
std::exception::what: Error updating and cloning submodule: context [-3] - object not found - no match for id (dbe0b27303c2a834b87ef67ac07e6a8e22f7ad8e)

● [err] Something went wrong, for help on your issue, we would enjoy getting your report at https://tipi.build/#contact

Cloning and initialising the boost repo outside of tipi works and the SHA1 exists.

Repro available here:
https://github.com/pziggo/vsomeip/tree/5a28c2dc59a15232a9e4b38be0a11fe447d44058

tipi version: v0.0.55

.tipi/deps:

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

tipi command: tipi -t linux-cxx17 .

After upgrade, my initial command is not executed

When you want to execute a command and tipi offers an update, at the end of the update the original command is not executed.

To give a concrete example.
I want to run tipi connect. Tipi went on with an update from v.0.0.27 to v.0.0.28. When it finished with the update, it didn't run tipi connect.

It would be nice if it went on with the original command.

Confirmation request could be more user friendly

After running tipi . -t linux-cxx17 for the first time, it asks whether the user is OK with downloading some 7GB:

By default tipi installs a subset of the build tools to build remotely on tipi.build. For local builds you can install them locally. This will download 7GB.
 Confirmation with : [y]es

I hit enter and I leave for a coffee. I came back and nothing happened. I realized that I should have typed y or yes. After all, the request is clear. But it would be more user-friendly if we received an error message if we entered anything else, even if it's just an "enter".

While writing this issue, Grammarly reported that there are two missing commas in the above message.

According to Grammarly, the correct version is:

By default, tipi installs a subset of the build tools to build remotely on tipi.build. For local builds, you can install them locally. This will download 7GB.

Missing newline at the end of error returns

I'm not completely sure if it's only with erroneous returns, but usually if a command fails, there is no newline at the end of the error message.

Example:

std::exception::what: Impossible to localize the working directory /home/dev/mosze-projects on the remote build
● [err] Something went wrong, for help on your issue, we would enjoy getting your report at https://tipi.build/#contactroot@fbd8a81d9ea4:/home/dev/mosze-projects#

Not a big deal, but not nice.

[Windows] Install script mixes up user and machine PATH definitions

When the script runs in non-privileged mode, we set the User's PATH but fill it with the amended Machine path.

  [Environment]::SetEnvironmentVariable(
      "Path",
      [Environment]::GetEnvironmentVariable("Path", [EnvironmentVariableTarget]::Machine) + ";$INSTALL_FOLDER",
      [EnvironmentVariableTarget]::User)

On windows righs are not available by default to create build folders symlinks

Description

As reported on discord by @mrexodia, On windows 10 pro x64 :

?? .tipi/
· [err] Dynamic exception type: class std::filesystem::filesystem_error
std::exception::what: create_directory_symlink: A required privilege is not held by the client.: "../41d9c90-basic.b/08fea58", "../41d9c90-basic.b/wasm-cxx17"
· [err] Something went wrong, for help on your issue, we would enjoy getting your report at https://tipi.build/#contact

Either https://stackoverflow.com/questions/58038683/allow-mklink-for-a-non-admin-user
Or as git seems to do in it's installation process it's possible to give that specific right to a binary.

.tip/deps with invalid entries does not produce an error

Hi,

in .tipi/deps I had

"google/googletest": {
        "u": true,
        "package": "GTest"
    },

this produced a CMake error because I wrote package instead of packages. I think that having an incorrect entry in .tipi/deps should produce a hard error, otherwise it's easy to lose a lot of time troubleshooting the wrong problem.

tipi cannot be installed by default on a fresh macOS

The python installed by default on macbooks are 2.7 and have an outdated certstore. The python installed by tipi on macOS fails with :

▶ Shipping tool with name 'emsdk'
initializing emsdk.
`update-tags` is not longer needed.  To install the latest tot release just run `install tot`
Installing SDK 'sdk-releases-upstream-89202930a98fe7f9ed59b574469a9471b0bda7dd-64bit'..
Installing tool 'node-14.15.5-64bit'..
Error: Downloading URL 'https://storage.googleapis.com/webassembly/emscripten-releases-builds/deps/node-v14.15.5-darwin-x64.tar.gz': <urlopen error unknown url type: https>
Warning: Possibly SSL/TLS issue. Update or install Python SSL root certificates (2048-bit or greater) supplied in Python folder or https://pypi.org/project/certifi/ and try again.
Installation failed!
● [err] failed.
● [err] Dynamic exception type: std::runtime_error
std::exception::what: CTest failed
● [err] Something went wrong, for help on your issue, we would enjoy getting your report at https://tipi.build/#contact
➜  ~ Error: Downloading URL 'https://storage.googleapis.com/webassembly/emscripten-releases-builds/deps/node-v14.15.5-darwin-x64.tar.gz': <urlopen error unknown url type: https>
Warning: Possibly SSL/TLS issue. Update or install Python SSL root certificates (2048-bit or greater) supplied in Python folder or https://pypi.org/project/certifi/ and try again.
Installation failed!
➜  ~ Error: Downloading URL 'https://storage.googleapis.com/webassembly/emscripten-releases-builds/deps/node-v14.15.5-darwin-x64.tar.gz': <urlopen error unknown url type: https>
Warning: Possibly SSL/TLS issue. Update or install Python SSL root certificates (2048-bit or greater) supplied in Python folder or https://pypi.org/project/certifi/ and try again.
Installation failed!

Crash in the git functions on windows

When trying to build https://github.com/build-cpp/cmkr commit c0df63c907947aed985337a0767f43970afa4258 on windows 10 pro x64

tipi crashes almost immediately:

00 00000007`a4df7ce0 00007ff6`ead448b3     tipi!git_indexer_free+0x11cc
01 00000007`a4df7d10 00007ff6`eacd8227     tipi!git_indexer_free+0x1343
02 00000007`a4df7d40 00007ff6`eacd82e5     tipi!git_repository__cleanup+0x57
03 00000007`a4df7d70 00007ff6`eae74806     tipi!git_repository_free+0x25
04 00000007`a4df7db0 00007ff6`eb276c13     tipi!git_oidarray_dispose+0x90a86
05 00000007`a4df7de0 00007fff`7a061030     tipi!git_oidarray_dispose+0x492e93
06 00000007`a4df7e10 00007fff`7a062cc8     VCRUNTIME140_1!_CallSettingFrame+0x20 [D:\a\_work\1\s\src\vctools\crt\vcruntime\src\eh\amd64\handlers.asm @ 50] 
07 00000007`a4df7e40 00007fff`7a063b3d     VCRUNTIME140_1!__FrameHandler4::FrameUnwindToState+0x250 [D:\a\_work\1\s\src\vctools\crt\vcruntime\src\eh\frame.cpp @ 1138] 
08 00000007`a4df7f80 00007fff`7a062244     VCRUNTIME140_1!__FrameHandler4::FrameUnwindToEmptyState+0x2d [D:\a\_work\1\s\src\vctools\crt\vcruntime\src\eh\risctrnsctrl.cpp @ 234] 
09 00000007`a4df7fb0 00007fff`7a06237a     VCRUNTIME140_1!__InternalCxxFrameHandler<__FrameHandler4>+0x194 [D:\a\_work\1\s\src\vctools\crt\vcruntime\src\eh\frame.cpp @ 351] 
0a 00000007`a4df8050 00007fff`7a064149     VCRUNTIME140_1!__InternalCxxFrameHandlerWrapper<__FrameHandler4>+0x3e [D:\a\_work\1\s\src\vctools\crt\vcruntime\src\eh\frame.cpp @ 234] 
0b 00000007`a4df80b0 00007ff6`eb26817c     VCRUNTIME140_1!__CxxFrameHandler4+0xa9 [D:\a\_work\1\s\src\vctools\crt\vcruntime\src\eh\risctrnsctrl.cpp @ 306] 
0c 00000007`a4df8120 00007fff`a12f249f     tipi!git_oidarray_dispose+0x4843fc
0d 00000007`a4df8150 00007fff`a1280939     ntdll!RtlpExecuteHandlerForUnwind+0xf
0e 00000007`a4df8180 00007fff`7a063dde     ntdll!RtlUnwindEx+0x339
0f 00000007`a4df88a0 00007fff`7a061635     VCRUNTIME140_1!__FrameHandler4::UnwindNestedFrames+0x10a [D:\a\_work\1\s\src\vctools\crt\vcruntime\src\eh\risctrnsctrl.cpp @ 685] 
10 00000007`a4df8990 00007fff`7a0619d5     VCRUNTIME140_1!CatchIt<__FrameHandler4>+0xb9 [D:\a\_work\1\s\src\vctools\crt\vcruntime\src\eh\frame.cpp @ 1370] 
11 00000007`a4df8a30 00007fff`7a062317     VCRUNTIME140_1!FindHandler<__FrameHandler4>+0x385 [D:\a\_work\1\s\src\vctools\crt\vcruntime\src\eh\frame.cpp @ 625] 
12 00000007`a4df8c00 00007fff`7a06237a     VCRUNTIME140_1!__InternalCxxFrameHandler<__FrameHandler4>+0x267 [D:\a\_work\1\s\src\vctools\crt\vcruntime\src\eh\frame.cpp @ 399] 
13 00000007`a4df8ca0 00007fff`7a064149     VCRUNTIME140_1!__InternalCxxFrameHandlerWrapper<__FrameHandler4>+0x3e [D:\a\_work\1\s\src\vctools\crt\vcruntime\src\eh\frame.cpp @ 234] 
14 00000007`a4df8d00 00007ff6`eb26817c     VCRUNTIME140_1!__CxxFrameHandler4+0xa9 [D:\a\_work\1\s\src\vctools\crt\vcruntime\src\eh\risctrnsctrl.cpp @ 306] 
15 00000007`a4df8d70 00007fff`a12f241f     tipi!git_oidarray_dispose+0x4843fc
16 00000007`a4df8da0 00007fff`a12a14a4     ntdll!RtlpExecuteHandlerForException+0xf
17 00000007`a4df8dd0 00007fff`a12a11f5     ntdll!RtlDispatchException+0x244
18 00000007`a4df94e0 00007fff`9ec0cd29     ntdll!RtlRaiseException+0x185
19 00000007`a4df9cd0 00007fff`8db16720     KERNELBASE!RaiseException+0x69
1a 00000007`a4df9db0 00007ff6`eaeb8133     VCRUNTIME140!_CxxThrowException+0x90 [D:\a\_work\1\s\src\vctools\crt\vcruntime\src\eh\throw.cpp @ 75] 
1b 00000007`a4df9e10 00007ff6`eaebbbd5     tipi!git_oidarray_dispose+0xd43b3
1c 00000007`a4df9eb0 00007ff6`eaefc80c     tipi!git_oidarray_dispose+0xd7e55
1d 00000007`a4dfa710 00007ff6`eae67d73     tipi!git_oidarray_dispose+0x118a8c
1e 00000007`a4dfa990 00007ff6`eaf31b99     tipi!git_oidarray_dispose+0x83ff3
1f 00000007`a4dfab80 00007ff6`eae1a8d9     tipi!git_oidarray_dispose+0x14de19
20 00000007`a4dffbb0 00007ff6`eaecb330     tipi!git_oidarray_dispose+0x36b59
21 00000007`a4dffbe0 00007ff6`eaecd6a9     tipi!git_oidarray_dispose+0xe75b0
22 00000007`a4dffc50 00007ff6`eaf1b89e     tipi!git_oidarray_dispose+0xe9929
23 00000007`a4dffd30 00007ff6`eaf19a6f     tipi!git_oidarray_dispose+0x137b1e
24 00000007`a4dffd90 00007ff6`eaf5202a     tipi!git_oidarray_dispose+0x135cef
25 00000007`a4dffdd0 00007fff`9f041bb2     tipi!git_oidarray_dispose+0x16e2aa
26 00000007`a4dffe00 00007fff`a11074b4     ucrtbase!thread_start<unsigned int (__cdecl*)(void *),1>+0x42
27 00000007`a4dffe30 00007fff`a12a26a1     KERNEL32!BaseThreadInitThunk+0x14
28 00000007`a4dffe60 00000000`00000000     ntdll!RtlUserThreadStart+0x21
``

On light vs full install mode : present the list of elements getting installed

Currently users aren't informed about what tipi installs and what it doesn't. Listing the components could help people take the decision.

Change tipi installation location with TIPI_HOME_DIR doesn't work

Hi,

I try to change my tipi "Home"-Dir to ~/.local/share/tipi via TIPI_HOME_DIR, but it doesn't work. The tipi command still expected the tipi home folder in /usr/local/share/.tipi

I saw in the [install_for_macos_linux.sh(https://github.com/tipi-build/cli/blob/master/install/install_for_macos_linux.sh#L97) script that it set TIPI_DATA_DIR. I try to set this also, but it's also not working.

Should I set this before I install tipi?

Btw. as workaround I created a "symlink" from /usr/local/share/.tipi to ~/.local/share/tipi

May I ask a question, is there any reason why you use /usr/local/share/.tipi ? In linux/freedesktop they specified that user-specific data files should be stored to $XDG_DATA_HOME as default equal to $HOME/.local/share. See also https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables

Broken contact link

When tipi hits an error it spits out this blurb:

[err] Something went wrong, for help on your issue, we would enjoy getting your report at https://tipi.build/#contact

The link appears to be broken, I don't think there is a contact anchor and from a ctrl+f I don't see contact info listed. The closest thing is the "Community Support" link in the very bottom left of the home page.

Build With Dependencies Fails

Cloud build stops at dependencies:

$ tipi build . -t windows
Mirroring : "tipi_example"
⣾ Checking out - 4 of 4 (100.00%) done.
- ⣾ Checking out - 5 of 5 (100.00%) done.{
  ...        }⚙️ finding target mtime of 3 files
⣻ 3 files processed - 100.00%
⚙️ setting target mtime of 3 files
⢿ 3 files processed - 100.00%
⚙️ setting target mtime of 2 folders
✔ done
- done.
⚠️ Failed to create build folder symlink - proceeding without (run again with -vvv to get more details)
⚠️ Failed to create build folder symlink - proceeding without (run again with -vvv to get more details)
- vault synchronized.
processed file: C:/.tipi\.ssh\id_rsa_windows
Successfully processed 1 files; Failed processing 0 files
✔ tipi.build remote env : windows, hash : c32aa9ea614d3504e87e682ade00d8e5bec4b7b4 ready.
- {   ...       }Initial remote repository clone from 
⣽ Pushing objects - 0 of 0 (32 B - -nan(ind)%)
- done.
Mirroring : "52af180-tipi_example"
⣾ Checking out - 3 of 3 (100.00%) done.
¤ finding target mtime of 3 files
⣻ 3 files processed - 100.00%
¤ setting target mtime of 3 files
⢿ 3 files processed - 100.00%
¤ setting target mtime of 2 folders
✓ done
- done.
ikalnytskyi/termcolor up-to-date check.
- {  ...        }

tipi_example.zip

"Failed to create build folder symlink"

I get the following local build errors:

⚠️ Failed to create build folder symlink - proceeding without (run again with -vvv to get more details)
⚠️ Failed to create build folder symlink - proceeding without (run again with -vvv to get more details)
ikalnytskyi/termcolor up-to-date check.

done.
● [err] Dynamic exception type: class std::bad_alloc
std::exception::what: bad allocation
● [err] Something went wrong, for help on your issue, we would enjoy getting your report at https://tipi.build/#contact

tipi_example.zip

Remote authorization required even for building locally

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 .

[vscode] dropdown menu for executable/test selection

The vscode plugin should provide an executable selection to run the tests ( as currently the cmdline presents the built binaries ) it could provide them in the vscode plugin as well.

On the command line it's possible to say : tipi build . -t linux --monitor -o some_test --test some_test, enabling this selection to be done directly from the graphical editor would be a better experience.

This has been discussed in a separate thread with @GregorPfirter-EH.

[Chromium] failed to access specific tag

Hey guys,
I want to test your build system with a complex example build.

For this I test to build a specific version of https://github.com/chromiumembedded/cef/ that required https://github.com/chromium/chromium as dependency.

I write this .tipi/deps file :

{
    "chromiumembedded/cef": {
        "@": "5481",
        "requires": {
            "chromium/chromium": {
                "@": "110.0.5481.0"
            }
        }
    }
}

I can access to specific tag https://github.com/chromium/chromium/tree/110.0.5481.0 but tipi failed to get it.

PS C:\Users\pcorbineau\Documents\personal_workspace\tipi_sandbox> tipi -t windows .
Looking for 4 files
Found cache meta
 - Checking cache status for: chromiumembedded/cef<605475778197b8725fc2659a58859cc46974516b> ⚙️ update required
chromiumembedded/cef up-to-date check.
- done.
 ⚙️ querying and downloading cache for chromiumembedded/cef@: 5481 [605475778197b8725fc2659a58859cc46974516b]
- done.
Fetching : https://github.com/chromiumembedded/cef.git
- done.
chromiumembedded/cef@: 5481 [605475778197b8725fc2659a58859cc46974516b]
Looking for 2115 files
chromium/chromium up-to-date check.
- done.
● [err] Dynamic exception type: class std::runtime_error
std::exception::what: err : error:0 OKstatus: 502 accessing : https://api.github.com/repos/chromium/chromium/git/refs/tags
● [err] Something went wrong, for help on your issue, we would enjoy getting your report at https://tipi.build/#contact

Any idea how to deal with it ?

Here is the simple code to test it :

#include <iostream>

#include <include/cef_process_message.h>

int main(){
  auto message = CefProcessMessage::Create("test");

  auto args = message->GetArgumentList();
  args->SetString(0, "Hello");
  args->SetString(1, "World");

  auto arg0 = args->GetString(0);
  auto arg1 = args->GetString(1);

  std::cout << arg0 << " " << arg1 << std::endl;

  return 0;
}

[local build] Incomplete executable path upon build completion

When I build something local, I get a build summary.
For example:

  executables
  ===========

    * 2021/OOP-Paths-Solution-W-Doxygen/OOP-gyak-path-solution

The mentioned path is incomplete, in should be preprended with ./build/<env>/bin/, in this case with ./build/linux-cxx17/bin/

[Windows] Running the install script as non-admin after an earlier installation don't refresh tipi

Motivation

To install the new version of tipi some users might rely on the install script, it might not update the tipi version and simply do the download and run the old version without sending any errors.

Steps to reproduce

Install tipi v0.0.29 as admin in powershell via the install script :

[Net.ServicePointManager]::SecurityProtocol = "Tls, Tls11, Tls12, Ssl3"
. { `
  iwr -useb https://raw.githubusercontent.com/tipi-build/cli/master/install/install_for_windows.ps1 `
} | iex

Install another version with $env:TIPI_INSTALL_VERSION = "v0.0.30" set for example in the Non-admin powershell window

The installation finishes without error but it's still v0.0.29 🙉

Expected behaviour

Error that the file cannot be replaced and installation failed.

`tipi . -t linux-cxx17 --test all` runs non-test executables

When I run tipi . -t linux-cxx17 --test all I see executables run which aren't related to tests.

Repro here: https://github.com/matthew-dews/tipi-build-starter/tree/17d24ad137bd5298249707bd5f0743a6584af78d
where the "HelloTest" runs, as does "main" which is for the executable itself. The "main" executable always fails since it expects command line arguments.

Full output:

tipi@fda948a1a2dd /w/tipi-build-starter (main)> tipi . -t linux-cxx17 --test all
Mirroring : "tipi-build-starter"
⣾ Checking out - 16 of 16 (100.00%) done.
⣾ Checking out - 1 of 1 (100.00%) done.
⚙️ finding target mtime of 16 files
⣽ 16 files processed - 100.00%
⚙️ setting target mtime of 16 files
⣻ 16 files processed - 100.00%
⚙️ setting target mtime of 7 folders
✔ done
⏳ done.          
Found cache meta
 - Checking cache status for: boostorg/boost<564e2ac16907019696cdaba8a93e3588ec596062> ● correct version on disk
 - Checking cache status for: google/googletest<2dd1c131950043a8ad5ab0d2dda0e0970596586a> ● correct version on disk
google/googletest up-to-date check.
⏳ done.          
Writing build cache meta
scanning project...
⏳ done.          
convention build summary :
==========================

  tipi-build-starter library
  ====================

  .cpp files : "src/app/minigrep/minigrep_lib/minigrep.cpp" 

  executables
  ===========

    * src/app/minigrep/main
       + cpps : src/app/minigrep/main.cpp


e . /usr/local/share/.tipi/vF.w/929e88f-tipi-build-starter/src/app/minigrep/main.cpp
✔ [ok] CMake build recipes inferred by convention in "../929e88f-tipi-build-starter.b/a4d7881/recipe"
Compiling "." for linux-cxx17
⏳ ✔ [ok] built.        
Compiled executables:
▶ src/app/minigrep:
  ● main -> tipi run ./build/linux-cxx17/bin/src/app/minigrep/main
UpdateCTestConfiguration  from :/usr/local/share/.tipi/vF.w/929e88f-tipi-build-starter.b/a4d7881/bin/DartConfiguration.tcl
UpdateCTestConfiguration  from :/usr/local/share/.tipi/vF.w/929e88f-tipi-build-starter.b/a4d7881/bin/DartConfiguration.tcl
Test project /usr/local/share/.tipi/vF.w/929e88f-tipi-build-starter.b/a4d7881/bin
Constructing a list of tests
Done constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements
Checking test dependency graph...
Checking test dependency graph end
test 1
    Start 1: main

1: Test command: /usr/local/share/.tipi/vF.w/929e88f-tipi-build-starter.b/a4d7881/bin/src/app/minigrep/main
1: Test timeout computed to be: 10000000
test 2
    Start 2: HelloTest.BasicAssertions

2: Test command: /usr/local/share/.tipi/vF.w/929e88f-tipi-build-starter.b/a4d7881/bin/src/app/minigrep/minigrep_lib/test/minigrep_lib_test "--gtest_filter=HelloTest.BasicAssertions" "--gtest_also_run_disabled_tests"
2: Test timeout computed to be: 10000000
1: Error: Empty query not allowed.
1/2 Test #1: main .............................***Failed    0.00 sec
2: Running main() from /usr/local/share/.tipi/vF.w/9a3bc02-googletest/googletest/src/gtest_main.cc
2: Note: Google Test filter = HelloTest.BasicAssertions
2: [==========] Running 1 test from 1 test suite.
2: [----------] Global test environment set-up.
2: [----------] 1 test from HelloTest
2: [ RUN      ] HelloTest.BasicAssertions
2: [       OK ] HelloTest.BasicAssertions (0 ms)
2: [----------] 1 test from HelloTest (0 ms total)
2: 
2: [----------] Global test environment tear-down
2: [==========] 1 test from 1 test suite ran. (0 ms total)
2: [  PASSED  ] 1 test.
2/2 Test #2: HelloTest.BasicAssertions ........   Passed    0.00 sec

50% tests passed, 1 tests failed out of 2

Total Test time (real) =   0.00 sec

The following tests FAILED:
          1 - main (Failed)
Errors while running CTest
Output from these tests are in: /usr/local/share/.tipi/vF.w/929e88f-tipi-build-starter.b/a4d7881/bin/Testing/Temporary/LastTest.log
Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely.
● [err] failed.
● [err] Dynamic exception type: std::runtime_error
std::exception::what: CTest failed
● [err] Something went wrong, for help on your issue, we would enjoy getting your report at https://tipi.build/#contact
tipi@fda948a1a2dd /w/tipi-build-starter (main) [1]>