mono_repo.dart
mono_repo.dart copied to clipboard
google
Pin hashes for dependencies
While using github workflows, we need to specify a commit for the action (see go/github-actions#actions). In the test repo of dart-lang, this dependency commit pinning needs to be completed. However since the mono repo tool is used to handle those dependencies, the tool should be updated to do the pinning. Context for this change comes from this pull request: https://github.com/dart-lang/test/pull/1699
I guess we could add an option for this.
Hrm.
We could just have a setting in mono_repo.yaml to let folks hard-code versions. PRs welcome!
If we believe that pinning these dependencies is the correct thing to do, I would argue we should just always do that, and not add additional complexity with an option. This tool is really just for us anyways, and we benefit from consistency here.
Requiring mono_repo to roll for every desired "dot" release is (as the kids say) "a big lift". We should ponder a model here where we can move versions of things forward without having to touch mono_repo
Maybe mono_repo generate could have a "latest" option or similar?
Requiring mono_repo to roll for every desired "dot" release is (as the kids say) "a big lift". We should ponder a model here where we can move versions of things forward without having to touch mono_repo
It isn't obvious to me we care about being on the latest version, the actions we use are pretty basic, and work fine today for us. We could probably stay on old versions and update on a set schedule or even just on request. That does come with security implications of its own (not getting security updates), but it is probably ok and we can update if we become aware of a security issue.
Even if we do want to stay on the latest, the difference is between having to update N packages or 1 package. I would rather update the one package (mono_repo) and then just re-run mono_repo generate in those packages, then have to manually update the hash and re-generate in all of those.
+1 for having fewer options and just picking what we want the behavior to be always.
I like the idea of finding the latest versions each time the tool runs. I don't think it's a huge problem if it means we pick up a dependency on a working network since regenerating github workflows is only useful when you will upload a PR anyway.
The only issue is that there could be breaking changes that affect what we generate.
So auto-magically always getting latest could be a problem. A flag for mono_repo generate --latest or similar could work
What would we use when we don't pass the --latest flag? A hardcoded set of defaults like we use today?
When would we choose to run without --latest? Would doing so downgrade us to earlier versions than we had been using?
I think the issue here is that two entities want to control the action versions in the workflow files? In this case it's us (based on feedback from the scorecards / scorecards-analysis.yml system) and mono_repo? We have a similar issue with dependabot and mono_repo - they both want to manage the versions in the workflow files.
One solution here would be for mono_repo to recognize when something else may be managing the action versions. So, if it detects either a dependabot.yaml file, or a scorecards-analysis.yml file, mono_repo could read the current action versions from dart.yml before regenerating that file. If neither file exists, or if dart.yml hadn't yet been generated, mono_repo could just use its current default versions.
This would let mono_repo play well with both the scorecard system and with dependabot.
(from a separate thread, athomas and I came to the conclusion that dependabot would do the right thing here wrt upgrading SHAs; we'd write a dart.yml file w/ an @1.3 version; the scorecare would want us to replace that w/ a SHA; and, when a later 1.4 version came out, dependabot would recognize that we're using a SHA, and write in the appropriate SHA for @1.4)
Would it make sense to start out by only changing the hardcoded versions to hashes and nothing else? From my understanding, it seems like when an action is currently updated it is manually updated anyway, so I'm wondering if there would be any additional work created by using hashes if you'd like to update an action's version in the future. If that would be an okay option I can take a crack at opening a PR to pin hashes.
Context: I am on the flutter security team with Jesse who originally posted the issue
That is what I would suggest yes as its the easiest solution and not really worse than what we have today. We can always change how this is done later.
That's fine with me.
On Wed, Jun 8, 2022 at 12:39 PM Jacob MacDonald @.***> wrote:
That is what I would suggest yes as its the easiest solution and not really worse than what we have today. We can always change how this is done later.
— Reply to this email directly, view it on GitHub https://github.com/google/mono_repo.dart/issues/381#issuecomment-1150324628, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAEFCVCPHNJVS7S6PBFH7LVODZGZANCNFSM5VR7L7MA . You are receiving this because you commented.Message ID: <google/mono_repo .@.***>
Sorry for a late follow up to this, but I opened a PR to change the version numbers to hashes to tackle this issue! Out of curiosity, how often are versions published to pub.dev?