Pin to a SHA of `dependabot/fetch-metadata` as opposed to `v1`

[yeikel]

Prerequisites

• [X] I have written a descriptive issue title
• [X] I have searched existing issues to ensure the issue has not already been raised

Issue

While working on #411 , I noticed that we're pinning the version of dependabot/fetch-metadata to v1

While that's convenient and reduces the manual work to keep it up to date, it also introduces non-reproducible builds. An accidental breaking change in upstream fetch-metadata can break the build of all our users. It is also harder to debug if there is any problem

Would you be open to pinning it to a specific SHA?

Generally, it is safer to pin to a SHA (as opposed to a tag) because tags are mutable.

[simoneb]

I'm not particularly fond of this option for various reasons:

• it creates more noise because dependabot will try to bump this more frequently
• we rely on the publisher to stick to semver and therefore avoid introducing breaking changes in minor or patch releases
• this is not production code therefore an unintended breaking change in an upstream dependency won't cause any major disruption

[yeikel]

it creates more noise because dependabot will try to bump this more frequently

Fair, but fetch-metadata is not updated that often for this to become a problem. They do at most 1 release per month and we're already merging weekly dependabot pull requests for other not-so-critical dependencies (like prettier)

we rely on the publisher to stick to semver and therefore avoid introducing breaking changes in minor or patch releases

This is safe in theory but it still breaks reproducible builds

this is not production code therefore an unintended breaking change in an upstream dependency won't cause any major disruption

This code is not production code, but it usually used to manage dependabot pull requests of production code. Ie: if this action merges a pull request that it shouldn't , it will impact production code.

I understand and respect the concerns about the maintenance overhead you described on the first point. Would you be open to have this as an action parameter?

[yeikel]

I just realized that the same applies to actions/github-script as we're pinning it to tag as well

[simoneb]

I just realized that the same applies to actions/github-script as we're pinning it to tag as well

Yes, I can speak for the organization that I'm most active within, NearForm. We use the major semver tag for all actions.

Hence, I'm not in favor of doing this change here, but since I am not the owner of this repo, I'm glad to hear other people's thoughts too.

[yeikel]

This is relevant : https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions

Pin actions to a tag only if you trust the creator : I guess it is safe to trust that Github team will do what's right

It is not guaranteed though.

[simoneb]

I'm happy with what we have in place at the moment