Pinning dependencies of GitHub actions

[gkunz]

This pins the dependencies of GitHub actions to the specific hash of the release commit. Version updates should then be driven through dependabot.

Adresses #159

[anders-larsson]

Looks OK. My only concern is dependabot and the Gemfile in the project.

We're using Puppet Development Kit (PDK)1 for the development/testing suite and it manages Gemfile and other files of the repository. It's never used (gems provided by Gemfile) by the module itself when running in production, it's only for development/testing.

Messing around with gems outside of PDK might prevent PDK functionality (or cause extra pain. Is it possible to manage specific parts of the repository with dependabot?

[gkunz]

Thanks for the explanation. Clearly, I am not familiar with the specifics of the development flow of the module and I merely wanted to show and test the possibilities that dependabot provides. If it does not add value, there is no need to adopt it, but I appreciate evaluating this.

Dependabot can be configured to only consider specific package ecosystems and only within specific locations. Please take a look at a sample configuration file I created in my fork of this repo:
https://github.com/gkunz/puppet-module-vas/blob/master/.github/dependabot.yml

In this case, dependabot checks the Ruby gems as well as the versions of the GitHub Actions. Both are scoped to "/", but that could be changed too if needed. In my local fork, it created a few PRs (limited to 5 PRs):
Logs of scans: https://github.com/gkunz/puppet-module-vas/network/updates
List of created PRs: https://github.com/gkunz/puppet-module-vas/pulls

In principle, dependabot PRs should trigger the tests which give an indication if the version update is compatible. Among the PRs in my fork, the udpate of rubocop didn't pass the validation (didn't check why) while the other updates succeeded:
https://github.com/gkunz/puppet-module-vas/pulls

Those updates are purely version updates (i.e., a new verison is available). In addition, as dependabot does understand the dependencies used in your project , it can provide security updates. If the former is not of value because packages should be managed via PDK, the latter may still provide value by highlighting vulnerable dependencies which may be updated through PDK. Would that make sense to you?

[anders-larsson]

Cool, maybe i should've checked the capabilities before writing my comment. Can you make a separate PR for depandabot configuration to manage GitHub actions configuration? Or should I create it? Thanks!

Should add, I'm still not sure I see the worth of being "spammed" with dependabot PRs regarding changes to Gemfile when we use a different tool to manage it. What's your opinion @Phil-Friderici ?

[gkunz]

I can create a PR later today.

[anders-larsson]

I saw in your fork that dependabot continued using a tag instead of commit SHA to reference (gkunz#2). If we merge this change before the dependabot change, will dependabot also use SHA instead of tags?

[Phil-Friderici]

Should add, I'm still not sure I see the worth of being "spammed" with dependabot PRs regarding changes to Gemfile when we use a different tool to manage it. What's your opinion @Phil-Friderici ?

We have tried dependabot once and the result was that it created PRs like hell for gems that are comming from PDK and are managed by PDK.

The PDK is used for development purposes only and doesn't touch our modules or their functionality in any other way than helping the devs to do good things. Before we used PDK, we had to survive the hell of broken dependencies quite often. I had spent a lot of time to troubleshoot the dependencies. It also required a lot of PR to only update tools used for development, which can get quite time consuming with all the modules we take care for.

Since Puppetlabs introduced PDK my life is less complicated and therefore I did become a fan boy. Yes we had dependency issues with PDK as well (two times), but it only took some days until Puppetlabs fixed the issues. And they do it much better compared to me ;)

So I think dependabot currently shouldn't care for the gems introduced by Puppetlabs. It would add noise without any benefit. Should it take care for the Github actions ? I don't know, I've never tried it. I guess it would be worth a try and we can see how many PRs it will create.

[Phil-Friderici]

I havn't dived into the details of dependabot nor how it can be configured.
As I have mentioned in my comment I think we could give it a try outside the scope of the gems introduced and used by PDK.

[gkunz]

I saw in your fork that dependabot continued using a tag instead of commit SHA to reference (gkunz#2). If we merge this change before the dependabot change, will dependabot also use SHA instead of tags?

Dependabot updates use whichever method is currently used: if versions are referenced by tag, it will update the tag [1], if versions are pinned by sha, it will update the sha [2].

@Phil-Friderici: then let's skip the version updates of gems and keep that in PDK.

See examples from one of my private repos:
[1] https://github.com/gkunz/gastimeter/pull/32/files
[2] https://github.com/gkunz/gastimeter/pull/37/files

[anders-larsson]

Sounds good in that case. Merging.