New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow GitHub workflow_dispatch
events to publish
#7462
base: master
Are you sure you want to change the base?
Conversation
Are you sure these checks will still work? if (agent.payload.refType != 'tag') {
throw AuthorizationException.githubActionIssue(
'publishing is only allowed from "tag" refType, this token has "${agent.payload.refType}" refType');
}
final expectedRefStart = 'refs/tags/';
if (!agent.payload.ref.startsWith(expectedRefStart)) {
throw AuthorizationException.githubActionIssue(
'publishing is only allowed from "refs/tags/*" ref, this token has "${agent.payload.ref}" ref');
}
final expectedTagValue = tagPattern.replaceFirst('{{version}}', newVersion);
if (agent.payload.ref != 'refs/tags/$expectedTagValue') { Will it require that the workflow_dispatch is triggered on a tag? |
It will indeed, I'll add another test for that, ensuring that it gives an error message if it's not triggered on a tag. |
@jonasfj I added a test in 1be34bf I'm not sure if it is possible to trigger the second |
@spydon seems, there are some conflicts 😸 I'm excited about this feature ;D |
It's just the changelog, it has to be updated every time something else is merged (gives me throwbacks from before we used Melos in all our projects 😅). |
The design document needs to be reviewed and accepted first, can be seen here: #7177 (comment) And hopefully after that there only needs to be a pair of check boxes added and theeen we can get this in. 😄 |
@spydon: We've come to a conclusion and we'd like to allow this event, but only as a UI option after an admin allowed it on the admin UI. Would you be interested to implement it as such? It would need to be stored on the @jonasfj: I think we could use a simple |
@isoos I think we should do two booleans. bool isFromWorkflowDispatchEventEnabled;
bool isFromPushEventEnabled; Or maybe
Where the first defaults to being enabled, and the second can be enabled. I think the ability to disallow publishing from |
@isoos this is why I thought it might be necessary with some data migration, in order to just create the properties on all entities. That's something we could easily do with a backfill job, right? |
Yeah, makes sense. |
Sounds great! 😃 |
This PR allows new versions of packages to be published from GitHub
workflow_dispatch
events.The same restriction on the
refType
is in place, it still needs to be run targeting a tag.Closes: #7177
Reason for change:
This is currently a blocker for actions like the melos-action to be used to its full potential, where the user can create releases directly from the GitHub UI in the following manner:
CHANGELOG.md
andpubspec.yaml
files and uploads it as a PRworkflow_dispatch
, since tags created from a GitHub action aren't allowed to trigger other actionsThis is a lot less error prone than doing manual releases from the command line, especially in bigger monorepos.
Contribution guidelines:
dart format
.Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.