rustonaut/rust-action-template

Repository to paly with github actions until I have a template I'm statisfied with.

rust-action-template

Repository to paly with github actions until I have a template I'm statisfied with.

rust-action-template's Issues

On open new issue

1. auto assign to me
2. auto set labels (+ labels unverified-labels) (I decided against that)

potentially rename master branch

Secure actions

• check if authors can manipulate already published actions (and as such effectively circumvent any reviews)

  • especially check publish -> unpublish -> republish

• if necessary create forks of all used actions

Auto publish through tags

On merge to master:

1. check if there is a release tag (r#"^v\d+\.\d+\.\d+"# or so)

   • validate the releases viability (tag version matches Cargo.toml, etc.)

2. auto publish to crates.io

Badges on published vs. master.

The badges we want to have in the README we publish to crates.io and the ones we have on github probably should not be the same.

One should be on the given stable publishe version.

The other should be based on the master branch.

Probably best done by having two generated READMES (we might anyway generate the readme ourself).

Consider adding default Code Coverage setup.

• check out if code coverage tools for rust work better by now
• if so consider adding a default code coverage setup

Examples in README (and maybe module doc).

The idea is that we make a README template and then "drop" in the example(s) we store in examples/.

The idea is we write and maintain examples in the example dir where the user can run them and don't have to bother with keeping them in sync.

Maybe we also will use some form of trick if possible to do so for the module level doc which often has a big overlap (including examples) with the README.

Easy pushing new versions.

Originally I wanted to make this an manual action but it's probably better suited as an script using the github web API?

The idea is to have a script/action which if you trigger it and provide a new version
will bump the version number in Cargo.toml and autogenerate the Tag and auto updates the CHANGELOG.md.

One reason why I don't want to make this a action is because I want to have auto publish ONLY on signed commits, and signing should be done by my "hardware" key (e.g. a Yubikey).

Setup git commit/tag signing.

Protect nightly branch after the rest is setup.

Doing it now is slightly annoying.

Auto update CONTRIBUTORS, CHANGELOG on merging a PR.

On possible approach:

• grab PR author, title and URL, and add it to .PRS.json.
• generate new CONTRIBUTORS.md from .PRS.json
• add author/title to the unpublished section in CHANGELOG.md

Some things should be noted:

1. no entries in CONTRIBUTORS for my commits ;-)
2. .PRS.json exists for three reasons:
   • We don't want to need to iterate over all past merged PR's every merge.
   • We don't want changes to the PR title after merge to take affect.
   • We want to be able to prune older messages (maybe in the future) and also to
     potentially do things like fix spelling errors.
3. The modification to CHANGELOG.md is just a prefill and likely might be modified.

Do checks on PR's

1. check cargo fmt (require fmt for merge)
2. do clippy deny(warnings) run
3. check if it compiles (different feature combies)
4. run tests (different feature combies)
5. ??cargo audit or similar??
6. ??cargo code cov > requirement??
7. validate tags