-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
I believe the Windows release workflow is broken #1820
Labels
question
An issue that is lacking clarity on one or more points.
Comments
Aye thanks. I'll keep this in mind next time I do a release. |
BurntSushi
added
the
question
An issue that is lacking clarity on one or more points.
label
Mar 14, 2021
BurntSushi
added a commit
that referenced
this issue
Jun 1, 2021
This combines the tips from #1820 and the patch submitted in #1675. The latter wasn't taken as-is because I didn't agree with some of the changes, and in particular, it removed the ability to easily test the release on a branch with a dummy tag name. I've tried to add that back here with the 'rg_version' output. Overall though, using outputs is indeed much simpler. Closes #1675, Closes #1820
BurntSushi
added a commit
that referenced
this issue
Jun 1, 2021
This combines the tips from #1820 and the patch submitted in #1675. The latter wasn't taken as-is because I didn't agree with some of the changes, and in particular, it removed the ability to easily test the release on a branch with a dummy tag name. I've tried to add that back here with the 'rg_version' output. Overall though, using outputs is indeed much simpler. Closes #1675, Closes #1820
BurntSushi
added a commit
that referenced
this issue
Jun 1, 2021
This combines the tips from #1820 and the patch submitted in #1675. The latter wasn't taken as-is because I didn't agree with some of the changes, and in particular, it removed the ability to easily test the release on a branch with a dummy tag name. I've tried to add that back here with the 'rg_version' output. Overall though, using outputs is indeed much simpler. Closes #1675, Closes #1820
BurntSushi
added a commit
that referenced
this issue
Jun 1, 2021
This combines the tips from #1820 and the patch submitted in #1675. The latter wasn't taken as-is because I didn't agree with some of the changes, and in particular, it removed the ability to easily test the release on a branch with a dummy tag name. I've tried to add that back here with the 'rg_version' output. Overall though, using outputs is indeed much simpler. Closes #1675, Closes #1820
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe your bug.
I'm reasonably convinced the release workflow is broken for the
windows-2019
platform, probably since commit 13d77ab which switched to the new environment files. There has been no release since then to prove or disprove my theory.When updating the environment, the syntax appears to be sensitive to the executing shell, and the default shell on
windows-2019
ispwsh
. Therefore, either the filename should be$env:GITHUB_ENV
or theshell
should be overridden.The retrieval syntax appears to be platform agnostic.
When this release workflow activates Cross the script uses the default shell with the Unix syntax so the
CROSS
andTARGET_
variables do not get updated onwindows-2019
.What are the steps to reproduce the behavior?
The job definition
produces the output
Observe that
T_SET_ENV_WITH_DEFAULT
never appears in the environment.The text was updated successfully, but these errors were encountered: