You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add a (good faith) roll validation before publishing packages #448
Our official procedure for publishing packages developed under the dart-lang/ github org is to wait for them to be rolled to google3 and/or the Dart SDK before they are published to pub.
It's very easy to omit that step today. We should add some gating which at the least asks the PR author to state that they have rolled the package.
My rough idea for the process is:
Add some level of git history to the checkout for the firehose action
Before adding the comment which gives a link to create the tag we look for a ROLLED_TO=<sha> or ROLLED_TO_<pkg>=<sha> in the PR opening comment and look for any diff in lib/ for any packages which are otherwise ready for publish.
We enable roll checks by default, with an explicit opt-out by package name mechanism in the github action config.
The step is manual by the PR author to avoid the complication of getting the credentials to check anything about the actual state of google3. We can probably add an internal agent skill and deterministic CLI tool to read this state for googlers. We could have an actual check against DEPS in the SDK repo, but I think it's not worth the implementation since that can be rolled in to the infrastructure for checking google3.
@kevmoo - do you have a guess as to wether changing away from a shallow git clone is going to have a significant negative impact? We could take a guess at an upper bound on how many commits between the last roll and HEAD instead of cloning full history if we think that a full clone is likely to become a problem.
Alternatively, we could make it a full honor-system "CONFIRMED_PACKAGE_ROLL=true" style check on the action side, and keep all the real behavior in the internal tooling that googlers run to check it.
Activity
natebosch commentedon Aug 26, 2026
@kevmoo - do you have a guess as to wether changing away from a shallow git clone is going to have a significant negative impact? We could take a guess at an upper bound on how many commits between the last roll and HEAD instead of cloning full history if we think that a full clone is likely to become a problem.
Alternatively, we could make it a full honor-system "CONFIRMED_PACKAGE_ROLL=true" style check on the action side, and keep all the real behavior in the internal tooling that googlers run to check it.
kevmoo commentedon Aug 26, 2026
I think we start w/ the honor-system model, honestly. I bet that'll be enough.
I never YOLO it intentionally. I just forget!