Enable more automated workflows by allowing publishing from the `workflow_dispatch` trigger

[spydon]

Note: Pub.dev only allows automated publishing from GitHub Actions when the workflow is triggered by pushing a git tag to GitHub. Pub.dev rejects publishing from GitHub Actions triggered without a tag. This ensures that new versions cannot be published by events that should never trigger publishing.

I understand the reasoning here, but this also makes it impossible to do fully automated publishing since a tag that is created by another workflow isn't allowed to trigger other workflows. So with this restriction from pub.dev in place the publishing will always need manual intervention from the command-line/IDE, since a user has to push a tag manually to trigger the workflow.

What we would like is to trigger the workflow that publishes the new versions from another workflow by using the workflow_dispatch trigger (currently only push is allowed).

The simplest flow for our use-case would be this:

1. The users goes to their action tab and presses "Run release action"
2. The melos-action versions and creates changelogs for all packages, and then published a PR with the changes (it also checks if it gets any publish --dry-run warnings in this step)
3. The PR is then reviewed
4. When the PR is merged it triggers the melos publish job which will tag and publish all of newly versioned the packages.

For context this will for example be used by the melos-action that should semi-automate (PRs are still used) the whole publishing flow in monorepos, or any repositories using melos.

Design doc: https://flutter.dev/go/pub-automated-publishing

[spydon]

One solution could be for pub to also allow workflow_dispatch events, they can also be connected to tags.
I thought that might already work, but sadly it didn't:

The calling GitHub Action is not allowed to publish, because: publishing is only allowed from 'push' events, this token originates from a 'workflow_dispatch' event.

[spydon]

What do you think @isoos @sigurdm?

[isoos]

@spydon: I am not that familiar with the workflow internals. Is there a document that describes what the users are doing and what the system is doing in such case?

[spydon]

@isoos So workflow_dispatch is the event that is used when a workflow is triggered manually:
https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch

It can also be connected to a tag, so the rest of the server-side checks on your side should still be the same as they are for push.

[isoos]

I'm more interested in what kind of problem it solves. I remember @jonasfj doing interesting things with workflows+tagging+approvals, and I don't know how this related.

[spydon]

Ah sorry, maybe I didn't clarify that properly in the initial post.
So with only allowing publishing on push one can never fully automate publishing, or even trigger a workflow manually that handles publishing from GitHub, one always have to manually push tags from the local machine.

What I'm building in the melos-action is so that people can set up the following flow for their monorepos:

1. Automatically version their packages and create changelogs.
2. This creates a PR with the outcome for the maintainers to review.
3. When this release PR is merged, another job creates git tags for all the new versions.
4. After the tags are created it should then publish to pub, but since GitHub doesn't allow workflows to be triggered by the action of other workflows (to avoid infinite loops) this part is not possible, even with an explicit trigger through workflow_dispatch, since pub.dev blocks that server-side.

So it really is just an unfortunate combination of the rule from GitHub and the one from pub.dev that blocks this flow, but by allowing workflow_dispatch events and not only push events to trigger publishing it would be solved.

[isoos]

When this release PR is merged, another job creates git tags for all the new versions.

I've seen people use git tagging and git push --tag to trigger automatic publishing. Not sure: what is missing in it for this to work with your workflow?

[spydon]

I've seen people use git tagging and git push --tag to trigger automatic publishing. Not sure: what is missing in it for this to work with your workflow?

If you do that from a GitHub workflow it can't trigger another action, so you can only do that locally.
https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#triggering-a-workflow-from-a-workflow

[spydon]

@isoos to clarify in case it wasn't clear, when you run git push --tags from a workflow, it will create the tags, but GitHub refuses to trigger another workflow that is usually triggered by newly created tags when those tags (or any other trigger, except workflow_dispatch) is related to another workflow run.

[spydon]

@isoos I found a TODO from you about possibly allowing for more event types 😄
https://github.com/dart-lang/pub-dev/blob/master/app/lib/package/backend.dart#L1250-L1251

I can implement the PR so that you can see what it would look like with workflow_dispatch too, it should be a really minimal change.

[isoos]

@spydon: As the TODO says we shall consider it :). I'd wait the input from @jonasfj but he is out right now, it may take a while before we can give you any solid decision on this one.

[spydon]

@spydon: As the TODO says we shall consider it :). I'd wait the input from @jonasfj but he is out right now, it may take a while before we can give you any solid decision on this one.

Makes sense, I'll not put up a PR then, or would it help your decision to have a PR to look at? :)

[jonasfj]

As far as I'm aware there is no work-around for this (without having to use PAT tokens)?

You can use a GCP service account instead. Ideally, not be exporting the service-account keys, but by running on Google Cloud Build or by using Workload Identity Federation to allow your Github JWTs to be used to obtain permission to impersonate the GCP service account.

This is obviously, quite complicated -- just saying it's possible 🙈

---

On topic we do have concerns, there are reasons we did it the way we did. Some of these concerns include:

• (1) Publishing a new version should be a deliberate action.
  • We do NOT want users publishing a new version of their package for each commit.
    (It's not hard to imagine that someone would think this is a cool thing to do).
  • pub.dev will limit packages to ~1000 package versions or so, if/when someone hits that
    we'll have to make exceptions on a case-by-case basis -- which we'll probably have to do.
  • Having many versions will make the API used by pub get slow, we want a simple and fast API.
  • Frequently publishing new versions might cause upgrade fatigue or unnecessary churn for package consumers -- I'm sure there are lots of other good reasons not to have a huge amount of versions.
  • Forcing automated publishing to happen through a tag, makes the initiation somewhat manual. This might be a good thing, and might keep people from publishing on every commit.
• (2) Reduce complexity reduces the risk of misconfigured Github Actions.
  • The fact that publishing requires permission to publish a tag makes it hard to misconfigure your Github Actions such that a pull-request can publish to pub.dev.
  • The fact that Github Actions can be triggered in so many ways, also means that if we allow arbitrary triggers we increase the risk that someone configures it poorly.
• (3) Forcing git revisions to be tagged is really awesome!

I think (3) is really nice. I don't know if (1) could be solved by other means -- maybe, but it's definitely a concern that if we make publishing too easy, someone will publish on every commit.

I think (2) is a really be concern though.

---

I'd be very curious is hear what kind of workflow you envision?

What are the kind of tasks people would use melos for? What are the steps in each scenario?