Skip to content
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

Meaning of "The action sets the following" #64

Closed
mmagician opened this issue Nov 10, 2022 · 2 comments
Closed

Meaning of "The action sets the following" #64

mmagician opened this issue Nov 10, 2022 · 2 comments
Labels
not a bug This is not a bug or feature

Comments

@mmagician
Copy link
Contributor

What does this actually mean, where is it set?

I guess especially version would be useful - ideally once a PR is merged, another action is triggered to actually publish the crates with the version that was just merged.

Do you perhaps have a workflow example where you're also automating this action of publishing to crates.io, and if so could you share please?

@passcod
Copy link
Member

passcod commented Nov 10, 2022

I do not have any workflow publishing to crates.io, due to current security concerns (which will be resolved when scoped tokens are implemented).


The motivation and precursor for this action are workflows that tag a release when the PR is merged, which then trigger optimised and published builds. But there's no direct way at the moment to use the outputs of this action from the merge. This is planned, to facilitate writing such actions (the afore-mentioned tagging ones do some horrible string parsing on commit messages from a push event), but I haven't done the design yet of how to pass that data along in a reliable manner.

My current idea draft is to embed a little json payload in a comment in the body of the PR, like:

<!-- {"release-pr-v1":{"version":{"desired":"patch","actual":"1.2.3"},"crate":{...}}} -->

which the second action would then be able to find from the pull_request close event, rather than working backward from the commit message. This would also eliminate the need to require a particular manner of merging this release PR.


In providing these outputs, this action is merely being a good citizen and providing derived values out the other end, rather than the user needing to parse/figure those out again. Examples of use could be to:

  • create a notification in a slack channel,
  • file an "intent to release",
  • add labels to open PRs to prevent them from merging during the "release window"

@passcod passcod closed this as completed Nov 10, 2022
@passcod passcod added the not a bug This is not a bug or feature label Nov 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
not a bug This is not a bug or feature
Projects
None yet
Development

No branches or pull requests

2 participants