-
Notifications
You must be signed in to change notification settings - Fork 27
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
Update CI config #99
base: main
Are you sure you want to change the base?
Update CI config #99
Conversation
0c68983
to
6d768eb
Compare
Thanks! This mostly LGTM but I would like to keep a test for 1.0 on Mac. |
Added Julia 1.0 test on macOS (via Rosetta emulation) |
Branch protection rules would have to be updated for this of course |
c8a19ef
to
3d99e8d
Compare
- latest TagBot.yml - use `julia-actions/cache` instead of `actions/cache` - test macOS on native ARM / aarch64 where applicable - avoid concurrent PR CI runs - drop obsolete `file` argument to `codecov/codecov-action`
inputs: | ||
lookback: | ||
default: "3" |
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.
inputs: | |
lookback: | |
default: "3" |
Lookback is already 3 by default, no? And IIUC this input will be unused because it isn't passed to the TagBot action.
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.
No, these three lines are about adding to the GutHub UI for manual workflow dispatch an input field that allows overriding the lookback value. That's helpful if TagBot ever again fails and you don't notice within 3 days
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 does TagBot actually have access to the value the user types in? It's not passed explicitly in the step that invokes TagBot.
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.
Yes it has. This is how these workflow dispatch inputs work (and I used it like that several times yesterday and today, 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.
Would you be willing to share a link to the docs that describe this implicit argument passing behavior so I can understand it, 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.
I would imagine this would be necessary: JuliaRegistries/TagBot#389
# The following is commented out due to https://github.com/JuliaRegistries/TagBot/issues/388 | ||
# permissions: | ||
# actions: read | ||
# checks: read | ||
# contents: write | ||
# deployments: read | ||
# issues: read | ||
# discussions: read | ||
# packages: read | ||
# pages: read | ||
# pull-requests: read | ||
# repository-projects: read | ||
# security-events: read | ||
# statuses: read |
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.
IMO adding these commented out lines doesn't help much with clarity.
# The following is commented out due to https://github.com/JuliaRegistries/TagBot/issues/388 | |
# permissions: | |
# actions: read | |
# checks: read | |
# contents: write | |
# deployments: read | |
# issues: read | |
# discussions: read | |
# packages: read | |
# pages: read | |
# pull-requests: read | |
# repository-projects: read | |
# security-events: read | |
# statuses: read |
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.
Perhaps not clarity but the next time someone wants to add these lines because the TagBot documentation says one should, they have a chance of knowing there may be a reason not to.
That's said, we can of course hope that TagBot will be fixed soon (one way or another) then this is moot.
i am fine with either way, choose whichever you prefer
julia-actions/cache
instead ofactions/cache
file
argument tocodecov/codecov-action
I have also fixed
DOCUMENTER_KEY
(the deploy key was missing). So for the next release, TagBot and documentation updates should work (again)