Closed TheMeier closed 3 weeks ago
In general I like the idea. A few thoughts:
In general I like the idea. A few thoughts:
- Can you document this in the README.md or so? Because we need to ensure that we add the comments for new exporters as well
Will do
- How do we want to treat the the PRs renovate creates? In the past this was often a backwards-incompatible change, but one could also argue it's an enhancement if the upgrade from the old to new version works without issues
Hm I would argue that version updates are only enhancements in the majority of cases. But I guess there is no way around the reviewer to actually classify each PR desperately
- Do you know if we can use dependabot for actions/checkout@v4.1.6 / renovatebot/github-action@v40.1.11? Or don't we want that? We don't run dependabot at the moment in our modules because we manage the CI configs via modulesync.
I only had a brief look into dependabot. I think this is possible. Something like this might do the trick:
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "weekly"
day: "sunday"
time: "16:00"
groups:
renovate:
patterns: [ "actions/checkout" ,"renovatebot/github-action]
I have added a dependabot config that only updates renovatebot/github-action
and ignores the others. Sadly you have to list the ignores explicitly, meaning if more actions will be added some day the ignore list needs to be updated.
There is no way to limit dependabot to specific files also sub-directories for workflows are not supported, so using https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#directory is also not an option.
This is the log from my tests: https://github.com/TheMeier/puppet-prometheus/network/updates/836753113
We could also allow actions/checkout version "4.x" but that will catch other workflows once the checkout action gets updated there by modulesync some day
Hm it seems in order for renovate to work correctly a custom personal access token i needed after all:
https://github.com/renovatebot/github-action?tab=readme-ov-file#token
In particular, using the GITHUB_TOKEN to create a new Pull Request from more types of Github Workflows results in Pull Requests that do not trigger your Pull Request and Push CI events.
But I am not sure if that really is necessary for this use-case
Well this did not work out very well. The token permissions are not sufficient, also the created PRs do not run the tests, as documented in https://github.com/renovatebot/github-action?tab=readme-ov-file#token, even though workflow_dispatch
is set.
In my tests with a fork both of these aspects did work. Unless we have a way to configure a personal access token (possibly from some tool-user) I don't see any way this works.
Another issue with this REFERENCE.md needs to be recreated in this workflow.
This ads a renovate github action which will create pull requests for updated versions of components. Currently 16 (of 41) versions are set in
data/defaults.yaml
, more to follow soon