search

actions-rs / meta

🦀 GitHub Actions for Rust - recipes, discussions, questions and ideas
https://github.com/actions-rs
Creative Commons Zero v1.0 Universal
353 stars 15 forks source link

semverver #13

Open svartalf opened 4 years ago

svartalf commented 4 years ago

@yaahc proposed an idea to add Action with semverver tool.

So far there are two possible options to use it:

  1. Same to other *-check Actions, execute it on: [push, pull_request] and add check annotations with the compliance notes.
  2. Execute it on a release: published event (idea goes to @yahhc) and fail the check for it if there were any compliance issues.

Unresolved questions:

  1. Should it fail the execution in case if any notes were found? Looks like there a multiple categories exist (Patch, NonBreaking, TechnicallyBreaking, and Breaking); how should the check act at all?
  2. Relying on release: published event would mean that it is expected from users to tag-and-push first and do the cargo publish only after the action succeeds/fails? Is it okay?
  3. With what version should it be compared to? We should probably make an API call to the crates.io and fetch latest version from there

Any ideas and suggestions will be much appreciated!

yaahc commented 4 years ago

For 3, I'd definitely expect it to compare to the latest non alpha release. Need to do some research to answer 1 and 2

thomaseizinger commented 3 years ago

Re (3): Based on https://github.com/rust-lang/rust-semverver#usage, semverver by default compares against the latest version published on crates.io

Re (1) & (2): I've toyed around with some ideas on how to use GitHub actions for releases and my finding has been that as the user, I usually want to be in control of what the next version is (instead of a tool automatically determining the next one for example).

Hence, for me, the most helpful action would be an additional check that notifies me of a possible mistake in determining the next version. I would likely include such an action in an on: push workflow with a branches pattern of release/*.

Should it fail the execution in case if any notes were found? Looks like there a multiple categories exist (Patch, NonBreaking, TechnicallyBreaking, and Breaking); how should the check act at all?

I think it should fail on on TechnicallyBreaking and Breaking. Whether or not the user requires a check to succeed to merge a PR is another story. They may want to ignore it and move on. However, if it doesn't fail at all, requiring a passing check is not possible. Annotations for anything that has been found sound useful to me.