To avoid warnings like:
In file included from /usr/include/c++/13/regex:50,
from ../../components/lua/yamlloader.cpp:6:
In constructor 'std::function<_Res(_ArgTypes ...)>::function(std::function<_Res(_ArgTypes ...)>&&) [with _Res = bool; _ArgTypes = {char}]',
inlined from 'std::__detail::_State<_Char_type>::_State(std::__detail::_State<_Char_type>&&) [with _Char_type = char]' at /usr/include/c++/13/bits/regex_automaton.h:149:4,
inlined from 'std::__detail::_StateIdT std::__detail::_NFA<_TraitsT>::_M_insert_subexpr_begin() [with _TraitsT = std::__cxx11::regex_traits<char>]' at /usr/include/c++/13/bits/regex_automaton.h:281:24:
/usr/include/c++/13/bits/std_function.h:405:42: error: '*(std::function<bool(char)>*)((char*)&__tmp + offsetof(std::__detail::_StateT, std::__detail::_State<char>::<unnamed>.std::__detail::_State_base::<unnamed>)).std::function<bool(char)>::_M_invoker' may be used uninitialized [-Werror=maybe-uninitialized]
405 | : _Function_base(), _M_invoker(__x._M_invoker)
| ~~~~^~~~~~~~~~
In file included from /usr/include/c++/13/regex:65:
/usr/include/c++/13/bits/regex_automaton.h: In member function 'std::__detail::_StateIdT std::__detail::_NFA<_TraitsT>::_M_insert_subexpr_begin() [with _TraitsT = std::__cxx11::regex_traits<char>]':
/usr/include/c++/13/bits/regex_automaton.h:279:17: note: '__tmp' declared here
279 | _StateT __tmp(_S_opcode_subexpr_begin);
| ^~~~~
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562.
GitLab inserts a check for failure after each command in our `script`.
This is documented here https://docs.gitlab.com/runner/shells/#powershell
However, it doesn't detect failures if we run commands back to back.
This adds the checks GitLab would have added for us if we were able to make it do that.
2.23.0 had breaking changes, so we need to know if we're using it, and be able to diagnose anything else caused by breaking changes in the future now they're a possibility.
This is a combination of 3 commits.
This is the 1st commit message:
Use the correct path
This will be the last non-deranged commit message on this branch.
This is the commit message #2:
🤨🤨🤨🤨
This is the commit message #3:
🙈🙉🙊
pick e140f1aa3a Use the correct path
squash 28744e367c 🤨🤨🤨🤨
squash b57bde40a2 🙈🙉🙊
We have to get it from Amazon directly and run an install script as
aws-cli v2 (which is what we use on Windows) is only shipped as a snap,
and snaps don't work on Docker, which the GitLab runners use.
This is a combination of 4 commits.
This is the 1st commit message:
Install aws-cli
Get it from snap because apt only has 1.x versions.
Pass --classic so it can actually see files.
This is the commit message #2:
But snapd isn't installed by default even though it's Ubuntu's recommended way to install everything
This is the commit message #3:
Mysterious snap-fixing incantation
I guess the service isn't running my default until the next reboot?
This is the commit message #4:
Snap doesn't work in Docker, apt doesn't have awscli v2+, let's just install random binaries wherever they want to put themselves
pick 5f0dfbf768 Install aws-cli
squash 1ed2a711fc But snapd isn't installed by default even though it's Ubuntu's recommended way to install everything
squash 230c917993 Mysterious snap-fixing incantation
squash 75142ff3c2 Snap doesn't work in Docker, apt doesn't have awscli v2+, let's just install random binaries wherever they want to put themselves
You can only use variables to specify the dependency job if you also
specify the project and ref. I couldn't find a built-in variable that
evaluated to the current ref or particularly clear documentation of what
ref even meant in this context (GitLab uses it for a few different
things in CI as far as I can tell).
This is a combination of 2 commits.
This is the 1st commit message:
Project permits variables in job names?
This is the commit message #2:
Using a variable is getting too hard, just copy and paste some stuff
pick cf1c4dfa73 Project permits variables in job names?
squash e5e888ac77 Using a variable is getting too hard, just copy and paste some stuff
Originally this had a double closing '' which wasn't noticed until
several commits later when it was fixed well enough to actually reach
that line. That change has been time-travelled and squashed after a big
argument.
This is a combination of 2 commits.
This is the 1st commit message:
Compress symbols in separate job
Typo
pick 9c27586080 Compress symbols in separate job
squash b072d7e33f Typo
To avoid having jobs being unable to generate the cache like
https://gitlab.com/OpenMW/openmw/-/jobs/5766643208:
Creating cache Ubuntu_GCC.ubuntu_22.04.v1-3-non_protected...
apt-cache/: found 1082 matching artifact files and directories
ccache/: found 7443 matching artifact files and directories
FATAL: write ../../../cache/OpenMW/openmw/Ubuntu_GCC.ubuntu_22.04.v1-3-non_protected/archive_991882895: no space left on device
Failed to create cache
