Heya @slipset this is probably a better place to have our discussion about clj-commons projects and CI. First, a big thank you for all you do for clj-commons and its projects. ❤️ Onto the discussion… Background: I’m a new maintainer on clj-yaml and want to make some improvements to its release workflow. Two problems for me: 1. currently clj-yaml CI is on CircleCI, and one of my changes will be much easier to implement, maintain and secure on GitHub Actions 2. the clj-yaml release flow currently signs jars and I don’t want to deal with that complexity (unless there is a very real benefit to doing so) There is a recommendation https://github.com/clj-commons/meta/blob/master/README.md#maintenance-criteria. I humbly propose that we drop this recommendation, or amend it to include GitHub Actions (we are already on GitHub Actions for rewrite-clj, etaoin and clj-http-lite is too, but there wasn’t an existing clj-commons CI precedent for those projects). Here’s what I wrote on the #clj-yaml channel: > So what if clj-commons team documents what it prefers for its projects, and let the primary maintainers choose how to implement those? Maybe things like: > • keep a changelog > • tag releases > • release invocable by maintainer from command line > • document release flow and how to release > • etc. > I could help with this. We could expand the https://github.com/clj-commons/meta/blob/master/README.md#maintenance-criteria section to include example projects. I’m good with spending time getting my projects CI flows working, but also, life is very short, and I’d rather be doing other things.

Getting late in my TZ, but I'll drop some notes so I can get the thoughts out of my head: 1) It is important to me that the build/release processes be as similar as possible between the different clé-commons projects. This is because it makes it easier for fewer people to maintain many project. Yes, Seeing like a State. 2) I really like to set off a release process by pushing a release tag. This is because GitHub then produces source bundles that downstream projects use. 3) It would be really nice if all projects had a release.sh script which would kick off a release process. A template or barebones such script could/should be in clj-commons/infra 4) there should be, IMO, a clear separation between the programs that initiate a release and the programs that do the release 5) Any step of the way which changes code in Git(Hub) should be run by GitHub actions, since we don't want other CI tools pushing code back to the repository. 6) All releases must be built on a CI platform. We should not release code from personal machines. 7) A shiny button on GitHub which kicks off a release is a good thing. 8) I prefer Circle over GA for the release process because I do :)

The reason I say release.sh and not http://release.bb is that I don't always have bb installed. Yes, I know. Shame on me.

And as always, strong opinions, weakly held, if one is still allowed to use that expression

A convention I use in all my projects is to have a bb publish task which kicks off the release. It works for Windows people too ;)

Awesome, thanks! We have the convention of CODEOWNERS, so we could also have the convention of doc/admin-guide.adoc (or doc/admin-guide.md for you weirdos) to explain what the release/publish flow does and how to invoke it. The release/publish script would ideally also log what actions it took and what will happen up on CI. See https://github.com/clj-commons/clj-yaml/issues/47#issuecomment-1255660171. Rewrite-clj and etaoin currently only do 7 (if by shiny button you meant the GitHub Actions web ui) but I’m going to eventually switch them to only do 2 invoked by 3 (but likely by bb publish for cross platform support) to conform to the clj-commons norm.

A bit tongue-in-cheek, but I’m still trying to digest this: > The reason I say release.sh and not http://release.bb is that I don’t always have bb installed. Yes, I know. Shame on me. I don’t even want to imagine not using bb for scripting.

Imagine my life! I don't have bb installed 🙂