-
Notifications
You must be signed in to change notification settings - Fork 222
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
Github: Enable dependabot for workflow dependencies #2778
Github: Enable dependabot for workflow dependencies #2778
Conversation
Thanks. There doesn't seem to be much with it? |
The strange thing is that the CI failed on your PRs... Edit: you probably stopped it. |
Don't you think this PR should be documented as Internal in the changelog? |
Well, I've only enabled it for github-actions for now as I don't see any other matches. It seem to be really targeted at certain build environments (npm, go, ...) which perform dependency management. For github-actions, it does what it should. The config is really basic and I think that's fine.
Yes. I've run lots of CI tests today and had to stop all those autobuild PRs at some point in order to get free slots for further tests. :)
Not sure. I think we don't have a guideline regarding that yet. This PR does not change the released artifacts in any way, so I thought I'd skip the CHANGELOG. |
I'd still like to have a changelog entry (maybe for all of these PRs squashed): Internal: Enabled automated dependency updates via dependabot and custom script |
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 mean, I can’t say much here but thanks!
schedule: | ||
interval: weekly | ||
commit-message: | ||
prefix: "CI" |
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.
After the first PR was opened, I think we should be consistent for all the automated stuff. Either Build: Dependencies: CI: as prefix for all automated PRs.
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 thinking was that dependabot touches CI-only stuff (i.e. workflow dependencies) while the other job touches things which are related to our actual build logic. Therefore, I had chosen different prefixes.
If we want to have a single prefix for all, I'd go with Build:. aqt, Qt, etc. do run in CI, but not solely there, so that would sound wrong.
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 the real problem is that we haven't agreed on a standard (i.e. when to use CI:, Build:, Autobuild, ...) Probably agreeing gives benefit but also more maintenance/thinking on our side. I'd like to have not too many different prefixes.
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.
Agreed. I don't really care if something is "CI" or "Build" or "Autobuild". If the build breaks, the build breaks. I'm certain (almost) no client or server user cares, either! 😄 So the CHANGELOG entries really can be grouped, so that most people can just skip the lot when they hit them.
If I had to pick, I'd go for "Build" because it covers most ground.
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.
Change to Build added here: #2803.
I'll manually edit the titles (which are used when no CHANGELOG line is found) of the previous PRs.
Short description of changes
This PR enables Github's dependabot for Github Action Workflows.
Example PRs:
CHANGELOG: Internal: Enabled automated dependency updates via dependabot and custom automation
Context: Fixes an issue?
Related: #2346
Does this change need documentation? What needs to be documented and how?
No, the PRs are self-documented.
Status of this Pull Request
Ready for review.
What is missing until this pull request can be merged?
Checklist