Closed MisterDA closed 2 weeks ago
Isn't the solution to yaml syntax issues to invoke a script stored as a separate file in the repo?
Isn't the solution to yaml syntax issues to invoke a script stored as a separate file in the repo?
Probably, yes… but the script stays really tiny. I'd keep it embedded in the yaml.
I wonder about having some info about that in a commit message: a regular (YAML) comment would be better for future discoverability, I’d think.
Done. Thanks for the reviews!
Note: I had to add an action to compute the key, because I did not find a way to get the host version from gha expressions. ${{ runner.os }}
only returns "Windows"
, there doesn't seem to be an env var with Windows' version. There exists a hashFile
function, but not one to hash a string or return a substring. We need the host version to be able to invalidate the cache when it changes.
The code is similar to the one used in AppVeyor for MinGW-w64 builds (prior art in #12701). This should speed up just a little bit the build. The cache is invalidated if the
configure
script changes, or if the host system changes.Note that the original yaml cannot contain line endings, because they'll be processed as CRLF line endings, which bash will reject. Indentation in the original code will propagate as newline in the processed code, leading to syntax errors in bash. Painful.
https://yaml-multiline.info/
As newlines are removed in the block, it cannot contain bash comments (except at the end).
(no change entry needed) cc @shym and @dra27