Pin hashes for dependencies about mono_repo.dart HOT 14 CLOSED

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.

from mono_repo.dart.

from mono_repo.dart.

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!

from mono_repo.dart.

Thoughts @jakemac53 @natebosch ?

from mono_repo.dart.

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.

from mono_repo.dart.

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?

from mono_repo.dart.

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.

from mono_repo.dart.

+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.

from mono_repo.dart.

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

from mono_repo.dart.

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?

from mono_repo.dart.

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)

from mono_repo.dart.

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

from mono_repo.dart.

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?

from mono_repo.dart.

This has been done!

from mono_repo.dart.