Consider automating release

lread commented 3 months ago

Currently

The sarif report includes the clj-watson version:

{
  "$schema" : "https://schemastore.azurewebsites.net/schemas/json/sarif-2.1.0-rtm.5.json",
  "version" : "2.1.0",
  "runs" : [ {
    "tool" : {
      "driver" : {
        "name" : "clj-watson",
        "informationUri" : "https://github.com/clj-holmes/clj-watson",
        "version" : "3.0.2",
...

Version 3.0.2 is stale.

So...

We should bump it to current.

But why the ceremony of an issue?

To maybe consider automating bumping of versions in files on release.

Or at least add it to a manual step in a release checklist.

seancorfield commented 3 months ago

If it isn't automated somehow, it'll just get forgotten (as it clearly has been for a long time), but given that all changes have to go through pull requests, I'm not sure what that automation should look like, given this is a source tool where the SHA is only known after tagging a given release, which requires another pull request to update a bunch of things in the README and CHANGELOG to include the new version and SHA...

lread commented 3 months ago

Yeah, it is a bit of a pain in the tush.

Would this work?:

Sanity checks for ok to release
Run lints, tests, etc.
Bump version (we could create a version.edn or equivalent)
Reflect new version in README, CHANGELOG unreleased heading, and sarif template (or maybe sarif template reads from version.edn).
Commit changes & tag with version
Update README, CHANGELOG with sha @ tag (we can never version tag the README and CHANGELOG with the updated sha, this is the annoying catch-22-fly-in-the-ointment-of-source-based-projects-bit!)
Commit again
Push commits and version tag
Create GitHub release @ version tag. I notice you maybe do some TLC manual work here, but if you are willing to simply link to the changelog, we could pretty easily automate? (Could do this step CI-side or client-side)

lread commented 3 months ago

Oh, I assumed you had master push privileges! If you don't have those, maybe you could request them?

seancorfield commented 2 months ago

If the main branch is protected, I don't think even the repo owner can push directly to the main branch?

lread commented 2 months ago

Thanks, I'm slowly learning how this repo is configured. So, the main branch is protected. No direct pushes to the main branch allowed.

I've not configured this for any of my repos, but I can see the attraction of not allowing force pushes to the main branch.

Is this configuration your preference or the repo owner's preference?

If the configuration needs to stay this way, I'd have to explore, but I think tags can still be pushed by those with write access to the repo? The version tag could trigger a CI workflow with privileges to do the work above (re-organized a bit).

So maybe:

Dev Side:

Sanity checks for ok to release
Run lints, tests, etc.
Create and push version tag

CI Side detects version tag and triggers:

Sets version (we could create a version.edn or equivalent)
Reflect new version in README, CHANGELOG unreleased heading, and sarif template (or maybe sarif template reads from version.edn).
Commit changes & tag with version
Update README, CHANGELOG with sha @ tag (we can never version tag the README and CHANGELOG with the updated sha, this is the annoying catch-22-fly-in-the-ointment-of-source-based-projects-bit!)
Commit again
Push commits and version tag
Create GitHub release @ version tag. I notice you maybe do some TLC manual work here, but if you are willing to simply link to the changelog, we could pretty easily automate? (Could do this step CI-side or client-side)

Another way to do this all CI-side is via a :workflow-dispatch trigger. This would be triggered through the GitHub GUI (rather than a version tag) and do all work CI side.

seancorfield commented 2 months ago

Definitely not my choice 😄 Initially, PRs also required (at least one) reviewer which made change nearly impossible given that all the previous maintainers (and therefore reviewers) seem to have moved on. I have floated the idea of transferring it to clj-commons but it's somewhat tied to clj-holmes (which seems unmaintained at this point, unfortunately).

Any commits the CI action did would have to be on a branch and turn into a PR in order to merge it.

Since it's a source-based project, installations don't really need to be merged. I believe we could create a develop branch and do general work on that (unprotected) branch, including automated tagging etc and then the release process could be done from the develop branch, and then the end result merged to the main branch at each release.

Any PRs made against the main branch could still be merged to it, and main just merged back to develop to continue work on the release -- or start doing PRs against develop (my preference, but contributors might miss that).

I do like hand-craft release notes -- I hadn't thought of making releases on GH based on previous automated tagged versions but that might be a good approach.

lread commented 2 months ago

Hmmm... since the original maintainers have moved on, would they be open to giving you admin privs to this repo and open to you reconfiguring it to suit your tastes? Watcha think @mthbernardes?

This would avoid contortions like a develop branch.

The only direct tie I see to clj-holmes/clj-holmes is running clj-holmes as a security linter on CI, but there might be more. Is there more?

clj-holmes / clj-watson