tarantool / tarantool-qa

QA related issues of Tarantool
3 stars 0 forks source link

ci: 'Needed a single revision' error #145

Closed Totktonada closed 2 years ago

Totktonada commented 2 years ago

Today I see the following on different Ubuntu machines in our pool:

Fetching submodules
  /usr/bin/git submodule sync --recursive
  Synchronizing submodule url for 'src/lib/msgpuck'
  Synchronizing submodule url for 'src/lib/small'
  Synchronizing submodule url for 'test-run'
  Synchronizing submodule url for 'test-run/lib/checks'
  Synchronizing submodule url for 'test-run/lib/luatest'
  Synchronizing submodule url for 'test-run/lib/msgpack-python'
  Synchronizing submodule url for 'test-run/lib/tarantool-python'
  Synchronizing submodule url for 'third_party/c-ares'
  Synchronizing submodule url for 'third_party/c-dt'
  Synchronizing submodule url for 'third_party/curl'
  Synchronizing submodule url for 'third_party/decNumber'
  Synchronizing submodule url for 'third_party/libyaml'
  Synchronizing submodule url for 'third_party/luafun'
  Synchronizing submodule url for 'third_party/luajit'
  Synchronizing submodule url for 'third_party/luarocks'
  Synchronizing submodule url for 'third_party/xxHash'
  Synchronizing submodule url for 'third_party/zstd'
  /usr/bin/git -c protocol.version=2 submodule update --init --force --recursive
  Submodule path 'src/lib/msgpuck': checked out '7f95b6fd7a5b928cfcbdab2d78bea88d1685821e'
  Submodule path 'src/lib/small': checked out '055458f1d45948f7d768e2499496926dcf78b26f'
  Submodule path 'test-run': checked out 'd16cbdc2702e7d939d5d34e41730fd83d2c65879'
  Submodule path 'test-run/lib/checks': checked out 'c97888c8d4a5ffb0255267d2d82fd60bae17916a'
  Submodule path 'test-run/lib/luatest': checked out '10590e70204d6e49a96e77cce2e8d80783f19000'
  Submodule path 'test-run/lib/msgpack-python': checked out 'd816aa80402dcce8fa806d4d43d0c087d86d6152'
  Submodule path 'test-run/lib/tarantool-python': checked out 'ea942f981158a3dcf7d5d343ad3acf89edd4b15b'
  Submodule path 'third_party/c-ares': checked out 'bbbffa4da8baf35b0e4e1c376e38018f9a8bcb4e'
  Submodule path 'third_party/c-dt': checked out 'cbb3fc27c104aa7703b01a4108ce7871e1a28a1c'
  Error: fatal: Needed a single revision
  Unable to find current revision in submodule path 'third_party/curl'
  Error: The process '/usr/bin/git' failed with exit code 1

Recipe to fix once:

$ cd actions-runner/_work/tarantool/tarantool
$ sudo git submodule update --init --recursive
fatal: Needed a single revision
Unable to find current revision in submodule path 'third_party/curl'
$ sudo rm -r third_party/curl
$ sudo git submodule update --init --recursive

I observed something like this once in the past with the test-run/lib/tarantool-python submodule. Don't remember, on which machines it was.

@ylobankov said that he is interested to look into the problem and asked me to trackerize it.

Totktonada commented 2 years ago

Don't know, but maybe this is relevant.

NickVolynkin commented 2 years ago

Examples of broken builds

coverage @ ghacts-2-8-90-5-2 https://github.com/tarantool/tarantool/actions/runs/1926998655/attempts/1

NickVolynkin commented 2 years ago

The problem was in the .git repository on the ghacts-2-8-90-5-2 runner. It couldn't fetch contents of the submodule in ./third_party/curl. Resolved with:

$ ssh ubuntu@ip
$ cd /home/ubuntu/actions-runner/_work/tarantool/tarantool
$ sudo su
# cd ./third_party/curl
# git remote -v
origin  https://github.com/tarantool/curl.git (fetch)
origin  https://github.com/tarantool/curl.git (push)
# git fetch
remote: Enumerating objects: 152856, done.
remote: Total 152856 (delta 0), reused 0 (delta 0), pack-reused 152856
Receiving objects: 100% (152856/152856), 67.93 MiB | 26.00 MiB/s, done.
Resolving deltas: 100% (119418/119418), done.
From https://github.com/tarantool/curl
 * branch                HEAD       -> FETCH_HEAD
# cd /home/ubuntu/actions-runner/_work/tarantool/tarantool
# git submodule update --init
From https://github.com/tarantool/curl
 * branch                HEAD       -> FETCH_HEAD
remote: Enumerating objects: 11326, done.
remote: Counting objects: 100% (7239/7239), done.
remote: Total 11326 (delta 7239), reused 7239 (delta 7239), pack-reused 4087
Receiving objects: 100% (11326/11326), 5.92 MiB | 6.28 MiB/s, done.
Resolving deltas: 100% (9833/9833), completed with 3082 local objects.
From https://github.com/tarantool/curl
 * branch                3266b35bbe21c68dea0dc7ccd991eb028e6d360c -> FETCH_HEAD
Submodule path 'third_party/curl': checked out '3266b35bbe21c68dea0dc7ccd991eb028e6d360c'
Submodule path 'third_party/luafun': checked out '04c99f9c393e54a604adde4b25b794f48104e0d0'
Submodule path 'third_party/xxHash': checked out '94e5f23e736f2bb67ebdf90727353e65344f9fc0'
Submodule path 'third_party/zstd': checked out 'a488ba114ec17ea1054b9057c26a046fc122b3b6'
Totktonada commented 2 years ago

I don't see any actions, which guarantee that it will not occur again.

NickVolynkin commented 2 years ago

Instead of repairing runners, we choose to drop and recreate them. This won't be fixed on this particular runner.

ligurio commented 2 years ago

Problem is still existing. PRs: