-
Notifications
You must be signed in to change notification settings - Fork 391
Set shell: bash
by default on all workflows
#3091
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR implements a consistent shell configuration across all GitHub Actions workflows by setting shell: bash
as the default. This addresses potential issues where workflows might use different shells on different platforms (POSIX vs Windows) and ensures proper error handling for multi-line steps by preventing workflows from hiding failures when intermediate commands fail.
Key changes:
- Add
defaults: { run: { shell: bash } }
to all workflow files (both manually written and auto-generated) - Remove individual
shell: bash
declarations from workflow steps since they're now redundant - Update the workflow generation script to include the default shell setting in generated workflows
Reviewed Changes
Copilot reviewed 114 out of 114 changed files in this pull request and generated 1 comment.
File | Description |
---|---|
pr-checks/sync.py | Updated workflow generation script to include bash shell default in all generated workflows |
pr-checks/checks/*.yml | Removed redundant shell: bash declarations from individual workflow steps in template files |
.github/workflows/*.yml | Added default shell configuration and removed redundant shell declarations from manually written workflows |
.github/workflows/__*.yml | Added default shell configuration and removed redundant shell declarations from auto-generated workflows |
Comments suppressed due to low confidence (8)
pr-checks/checks/unset-environment.yml:1
- This step is missing a
name
field, which makes it harder to identify in workflow logs. Consider adding a descriptive name like "Check database locations" or similar.
name: "Test unsetting environment variables"
pr-checks/checks/go-tracing-legacy-workflow.yml:1
- This step is missing a
name
field, which makes it harder to identify in workflow logs. Consider adding a descriptive name like "Verify Go database creation" or similar.
name: "Go: tracing with legacy workflow"
pr-checks/checks/go-tracing-custom-build-steps.yml:1
- This step is missing a
name
field, which makes it harder to identify in workflow logs. Consider adding a descriptive name like "Verify build environment and database" or similar.
name: "Go: tracing with custom build steps"
pr-checks/checks/go-tracing-autobuilder.yml:1
- This step is missing a
name
field, which makes it harder to identify in workflow logs. Consider adding a descriptive name like "Verify Go autobuilder execution" or similar.
name: "Go: tracing with autobuilder step"
pr-checks/checks/go-indirect-tracing-workaround.yml:1
- This step is missing a
name
field, which makes it harder to identify in workflow logs. Consider adding a descriptive name like "Verify indirect tracing workaround" or similar.
name: "Go: workaround for indirect tracing"
pr-checks/checks/cpp-deptrace-enabled.yml:1
- This step is missing a
name
field, which makes it harder to identify in workflow logs. Consider adding a descriptive name like "Verify dependency installation" or similar.
name: "C/C++: autoinstalling dependencies (Linux)"
pr-checks/checks/cpp-deptrace-enabled-on-macos.yml:1
- This step is missing a
name
field, which makes it harder to identify in workflow logs. Consider adding a descriptive name like "Verify dependency installation is disabled" or similar.
name: "C/C++: autoinstalling dependencies is skipped (macOS)"
pr-checks/checks/cpp-deptrace-disabled.yml:1
- This step is missing a
name
field, which makes it harder to identify in workflow logs. Consider adding a descriptive name like "Verify dependency installation is disabled" or similar.
name: "C/C++: disabling autoinstalling dependencies (Linux)"
6e07bb5
to
0c065fa
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for noticing the problem, investigating the issue, and proposing this fix!
This broadly looks good. I only have a few minor, non-blocking suggestions and thoughts.
cd "$(dirname "$0")" | ||
python3 -m venv env | ||
source env/bin/activate | ||
source env/*/activate |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Python 🤯 🤦🏻♂️
|
||
steps: | ||
- name: Prepare git (Windows) | ||
if: runner.os == 'Windows' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor: Checking matrix.os == 'windows-latest'
might be a bit easier to work with here, since the string appears in the matrix and is therefore less of a magic value. I.e. without checking what possible values runner.os
has, I wouldn't be sure that 'Windows'
is correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
on the other hand, checking runner.os
will work even if we change the runners (for example pinning the runner version) or if we copy such a snippet in another workflow. All in all, I prefer the stability and independence of context of runner.os
, it's just less prone to errors. One thing to note, all string comparisons on actions are case insensitive, so runner.os == 'windows'
works as well. runner.os
and runner.arch
are good things to keep in mind when writing workflows.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My comment was less about whether string comparison is case-sensitive or what runner
properties exist, but more that runner.os
could theoretically have other plausible values like 'win'
or 'win11'
etc. -- we know as routine Actions users that this may not be the case, but it is not as obvious generally as the matrix.os
comparison.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think runner.os
is fairly stable - it's always one of Linux/Windows/macOS
according to https://docs.github.com/en/actions/reference/workflows-and-actions/contexts#runner-context (and we've relied on that in the past). Agree it's not super obvious from your workflow though.
steps: | ||
- name: Prepare git (Windows) | ||
if: runner.os == 'Windows' | ||
run: git config --global core.autocrlf false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm mildly surprised that there isn't an option for actions/checkout@v5
to set this / that true
is the default on Windows.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
working-directory: autobuild-dir | ||
env: | ||
CODEQL_EXTRACTOR_CPP_AUTOINSTALL_DEPENDENCIES: false | ||
- shell: bash |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here, and in a couple of other places, the PR removes the -
for the start of the new step as well as just the shell
directive, so the workflow becomes invalid. I think we want to start a new step with the run
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, we just get pending checks rather than failures for these invalid workflows. Perhaps a tool like actionlint
could surface these errors more visibly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it might complain that the steps have both uses
and run
which isn't valid. At the same time, I feel like this could be a CodeQL actions
query too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
aaah, hadn't noticed in my automatic search and remove, good catch!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@henrymercer noticed that some of the workflows didn't start because you accidentally removed -
s where shell
was the first key in a step definition. I have marked all the places where I have spotted that problem, but it would be good if you could check as well to make sure I haven't missed any.
working-directory: autobuild-dir | ||
env: | ||
CODEQL_EXTRACTOR_CPP_AUTOINSTALL_DEPENDENCIES: false | ||
- shell: bash |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You removed the -
here by accident. May be worth adding a name
to make this more obvious.
working-directory: autobuild-dir | ||
env: | ||
CODEQL_EXTRACTOR_CPP_AUTOINSTALL_DEPENDENCIES: true | ||
- shell: bash |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here.
working-directory: autobuild-dir | ||
env: | ||
CODEQL_EXTRACTOR_CPP_AUTOINSTALL_DEPENDENCIES: true | ||
- shell: bash |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And here.
shell: bash | ||
run: go build main.go | ||
- uses: ./../action/analyze | ||
- shell: bash |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And here.
tools: ${{ steps.prepare-test.outputs.tools-url }} | ||
- uses: ./../action/autobuild | ||
- uses: ./../action/analyze | ||
- shell: bash |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And here.
shell: bash | ||
run: go build main.go | ||
- uses: ./../action/analyze | ||
- shell: bash |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And here.
languages: go | ||
tools: ${{ steps.prepare-test.outputs.tools-url }} | ||
- uses: ./../action/analyze | ||
- shell: bash |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And here.
id: analysis | ||
with: | ||
upload-database: false | ||
- shell: bash |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And here.
|
||
steps: | ||
- name: Prepare git (Windows) | ||
if: runner.os == 'Windows' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My comment was less about whether string comparison is case-sensitive or what runner
properties exist, but more that runner.os
could theoretically have other plausible values like 'win'
or 'win11'
etc. -- we know as routine Actions users that this may not be the case, but it is not as obvious generally as the matrix.os
comparison.
Co-authored-by: Henry Mercer <[email protected]>
The default behaviour of steps in absence of a
shell
settings is error prone:This change just sets
defaults: {run: {shell: bash}}
on all workflows (generated and written by hand), and removesshell: bash
from individual steps as no more needed. With this convention in place, we don't risk falling in that trap again.To add up motivation to why we want to do this: this has uncovered some checks that we weren't really running on Windows, and that wereactually failing there because of CRLF vs LF issues. Luckily this was only concerning dev functionality rather than production one. In any case this PR fixes those issues as well.
Risk assessment
For internal use only. Please select the risk level of this change:
Merge / deployment checklist