Repository navigation
Allow automated publishing from GitHub Actions with branch refType #8507
Description
- I've been using semantic-release to automate the publishing process of my Flutter packages alongside with the semantic-release-pub plugin, which I'm also the maintainer of it
- I was trying to add support for the plugin to utilise GitHub OIDC to authenticate to
pub.devbut then realised it doesn't allow a workflow triggered with the branchrefType - The
semantic-releaseworkflow is usually triggered by a push, and it manages the tag creation as part of its release process. So I was wondering if the automated publishing process can allow the branchrefTypewhen using the GitHub OIDC token? - See this workflow log for reference where pub.dev rejects the publishing because of the workflow trigger type
Activity
isoos commentedon Jan 30, 2025
/cc @jonasfj
jonasfj commentedon Feb 6, 2025
Context:
When we designed it we were a bit worried about allowing publishing from all sorts of
refTypes, basically we had a few concerns:In practices we don't have strict limits on how many versions a package can have. I think we have a limit at 1000k versions, but if you ask nicely we'll usually make an exception for your package.
We don't have any hard rules on how frequently you should publish, but publishing once or twice a week is perfectly fine (also fine if you publish more frequently some weeks). But publishing multiple versions of the same package per day won't scale well (yet it's sometimes necessary in exceptional circumstances, so we don't want to enforce low rate-limits).
But not making it too easy to publish from
pushwe hoped to avoid issues like (B). Where people have suddenly published 1000 revisions as versions they don't care about, and are limiting our soft scaling limits.It's also annoying for package consumers to be told to upgrade all the time. Hence, we do somewhat desire that publishing is a deliberate action, not a side effect of pushing a new revision to the
mainbranch.On topic we have enabled publishing from
workflow_dispatchevents, which might help work around some of the limitations. I'm not sure if you can trigger aworkflow_dispatchfrom apush, but one can certainly make buttons on github that makes triggering aworkflow_dispatcheasy.It also remains possible to automate publishing using GCP service accounts, though this is less convenient in Github Actions.
I don't think we're fundamentally opposed to loosening restrictions on what events can publish to pub.dev. But I think we should be careful not to encourage publishing every revision.
It's a little unclear if that's what semantic-release is all about, or if it's simply an option.
I can see that argument that restricting publishing from
pushevents, isn't the ideal what to do this. But I'm not sure what a better option would be.zeshuaro commentedon Feb 8, 2025
Thanks for the super detailed response. The workflow logs I initially shared were actually triggered by
workflow_dispatchbut it has a branchrefType.Anyway, this manual trigger was just me testing the GitHub OIDC and acts as a backup. Usually the workflow is triggered by a weekly schedule for the release, which I assume would have a branch
refTypeas well.My current workflow already works fine with my GCP service account, but I was just trying out GitHub OIDC to see if I can avoid having this service account floating around. If it's not possible to loosen the branch type restriction, then I'll just keep using the service account for now.
jonasfj commentedon Feb 10, 2025
I haven't explored if it's possible to do
workflow_dispatchon a branch, that might be a thing.I think we should close this for now, if lots of people run into the problem maybe it's worth reconsidering.
In theory I'd like to allow automated publishing from branches too, but (B) makes it somewhat risky. Especially, because we don't have a good way to stop people from having published a LOT of versions before it becomes a problem.
If if we had unlimited resources and time in the world, what I'd love to do is have some form of staged publishing. Where the automated publication from github action doesn't actually publish a version, but just "stages" it. When staged people should then be able to review package scores, update the staged package, maybe even use it with
pub getso long as opt-in, and finally it should be possible to promote a staged package version to be a published package version.I don't know when/if we'll have time to build such a flow, but I like the idea that a package version can be staged and then promoted to a published package, without any changes to actual package contents. Especially, for cases where the package interacts with other packages and they have complicated constraints and such.
In any case, that's not now -- but one can dream :D
- lets try if we can trigger the publish workflow to auto-publish.
jdde commentedon Jul 26, 2025
Hi guys,
I also encountered this problem. We use gitflow and the main problem is that tags are automatically created by merge/release creation processes purely build in github actions.
Since a created tag in workflow A is not allowed to trigger workflow B to avoid endless loops in github actions, it was not possible to automatically trigger an action with refType 'tag'.
Even when you create a github release via api in the workflow, that wont trigger a publish release listening on tags (those tags are created in githubs logic together with the release). Creating the tag and pushing it in the action also wont trigger workflows, as mentioned before.
What worked for us is @jonasfj comment, that workflow_dispatch is now also allowed, when you trigger your publish workflow after tag creation via github's api it will be executed as reftype workflow dispatch and the action is allowed to push the package via oidc auth to pub.dev🎉
Hopefully that helps somebody :) And maybe this gives some more background information why a tag only trigger is problematic in some setups.
p.s. the only other solution would've been to use a personal access token in the action, then its possible to trigger other workflows from workflows automatically 🤮
A comment about the dispatch possibility in the documentation would've solved it for me way faster..
Best regards, Jörn
fix(release): pub.dev publish via workflow_dispatch with tag ref
chore(release): 1.10.5 [skip ci]