Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Minor changes from ripgrep workflow + simplify + clarify quoting
The release.yml workflow adapts from the corresponding workflow in
the ripgrep project, but drawing from multiple revisions of it and
also including substantial gitoxide-specific changes.
ripgrep's licensing permits this even with respect to any material
that is original to that project, since one of the licenses ripgrep
is offered under is the Unlicense, which allows arbitrary use and
adaptation without requiring even attribution.
This commit makes these changes related to that relationship:
- Note the relationship, linking to the ripgrep workflow.
- Bring in the new ripgrep comment explaining the workflow, which,
as there, is shorter and just above the `create-release` job, not
at the top. This makes a slight change, so as not to refer to a
version tag scheme that differs and that we do not enforce.
- Renames both *_VERSION variables to just `VERSION`, as they now
are in the ripgrep workflow. These variables have conceptually
the same meaning, always take the same value, and do not clash
because each job in the workflow has exactly one of them.
- Bring in the simplification of using `github.ref_name` to get the
tag name to use as the version string.
There remain other significant changes to that workflow that can
and should be applied or adapted into this one, but which are not
included in this commit.
This commit also makes some other changes for simplification and
stylistic clarity:
- Change the trigger tag pattern to the glob-like `v*`, which seems
to be what the GHA docs say will make it work (though this may
have been tried unsuccessfully before).
- Don't specify the fetch depth, because `actions-checkout`
defaults to a depth of 1 already.
- Remove ad-hoc echos that inadvertently performed empty parameter
expansion because they used a variable that had just been written
in `$GITHUB_ENV`. Writes to `$GITHUB_ENV` only affect the
environment of subsequent steps, not of subsequent commands run
as part of the same script step. These could have been shown in a
different way, or by expanding them straightforwardly but in a
subsequent script step (like the existing "Show command used for
Cargo" step), but the removed echos did not seem very important
and the information they were showing is mostly available by
detailed log inspection.
- Simplify some commands whose complexity was just to support those
ineffective echos.
- Use the bash `$(< path)` syntax where applicable. This is a more
efficient alternative to `$(cat path)`. It's a bash-ism, but bash
is now being used to run all steps on all platforms.
- Where both (a) quoting was clearly unnecessary because of the way
YAML parses strings and (b) quoting was being used in some places
and not analogous other places, so the style was inconsistent,
this removes the quoting. (This does not remove quoting in other
situations, not even when one but not the other condition holds.)
- When quoting inline, this always uses the strongest form, of
those that are readily available and easily readable. This
applies both to the formation of YAML strings, which now prefer
single quotes to double quotes, and to quotation marks that
appear inside YAML strings that are executed by the shell. Now
double quotes are only used when both (a) quoting for a shell
rather than the YAML parser and (b) deliberately causing the
shell to perform its own `$...` expansions.
This is because double-quoted `${{ }}` interpolation can falsely
appear to be a shell expansion, when really all `${{ }}`
interpolation is done after YAML parsing but before the shell
receives the code that it runs in a script step.
- Double-quote `$GITHUB_ENV` (rather than not quoting it), so all
shell parameter expansion is double quoted except where expansion
that quoting would suppress is wanted (currently, nowhere).
- When shell quoting is optional because the item being `${{ }}`
interpolated is guaranteed to be parsed by the shell as a single
argument, and where we *rely* on that effect, this quotes the
argument. This is done more for consistency, in view of how it
was already mostly being done, than robustness. It is still not
truly robust because, although we never set such values, a `'`
character, if present in the output of interpolation, would be
(like all output of `${{ }}` interpolation) present literally in
the script that the shell receives, and the shell would interpret
it as a closing quotation mark.
- Adjust spacing for consistency with the existing style.- Loading branch information
1 parent
418d71f
commit 286e388