nunit.analyzers
nunit.analyzers copied to clipboard
nunit
Add Dependabot for GitHub actions
Recommended as a follow-up to #476 to ensure the actions we're using are kept up to date.
Example at https://github.com/nunit/docs/blob/master/.github/dependabot.yml
@SeanKilleen Will this make any difference? Currently, we just get the actions directly from main, so I guess they are always the newest?
Probably better to peg the GitHub actions to a known major version and then consciously update via Dependabot. Easier to reason about.
@SeanKilleen For my work we had to update actions/checkout and actions/setup-dotnet (from 2 to 3) because of dependabot. It is a hassle to do that for lots of repositories. What downside do you see to use @main so we always have the latest released version? The only one I could think of is incompatibility when the next major version uses different parameters.
@mikkelbu @manfred-brands pulling from main means sometimes actions will break, breaking the whole process, and you won't necessarily know why. I wouldn't grab actions from main for the same reason I wouldn't pull in the main branch of library code that I'm using -- I want to make it easier to reason about the changes, understand release notes, look at upgrade guides as necessary, see new features I might not have considered before.
It's a preference, but it's helped me avoid issues several times so it's part of my standard practice now wherever I operate.
@manfred-brands re: "hassle to do that for lots of repositories" - if you're re-using the same steps across multiple repositories, I think the preferred way would be to use a shared action across all those repositories and put dependabot on that one shared action. https://docs.github.com/en/actions/creating-actions/sharing-actions-and-workflows-with-your-organization
@SeanKilleen I do understand that pulling from main could break something, but we have that now if pre-installed software on a runner (e.g. Azure pipeline) is updated, we even had that when installing 6.0.x and MS broke things in a feature update (6.0.300).
I don't see how a shared action solves the multiple update problem as still all repositories would need updating to the next version of that action, unless you use 'main' for that shared action version.
@manfred-brands you can choose to do whatever you'd like 👍 it's just a recommendation based on my past experience with GitHub Actions and the pain that the approach has saved me personally. Just because breakages happen sometimes elsewhere doesn't mean I don't do my best to eliminate them within my sphere of control. If you don't have the intention to do it, feel free to close this.