Skip to content

Add a (good faith) roll validation before publishing packages #448

Open

Description

@natebosch

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.

https://github.com/dart-lang/sdk/blob/main/docs/External-Package-Maintenance.md#publishing-a-package

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.

Activity

  1. natebosch commented on Aug 26, 2026

    @natebosch
    MemberAuthor

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

  2. kevmoo commented on Aug 26, 2026

    @kevmoo
    Member

    I think we start w/ the honor-system model, honestly. I bet that'll be enough.

    I never YOLO it intentionally. I just forget!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions