Ideas for automation of release process
jayaddison opened this issue · comments
- Ensure changelog is populated prior to release
- Ensure release commit is tagged and that an associated release is packaged (solved via #111)
- Ensure upstream
grocy
version tag is used consistently (i.e. inMakefile
,docker-compose
,package.json
, ...) -
Rebuild(outdated due to file removal in #170)package-lock.json
automatically? - Push images automatically? (solved via #111)
- Reconsider how release notes are handled; these are currently copy-paste from the changelog, which is a manual process where mistakes could occur
-
Tag the(currently a WONTDO)latest
image on Docker Hub?
It may be possible to perform some of these checks by using git
pre-commit / pre-push scripts.
Additional idea: automatically run vulnerability scans (during pull requests and/or release packaging).
Resolved by v3.3.1-3.
A few mistakes were made during release changelog updates, release tagging, and upload to Docker Hub during releases v3.0.1-12
and v3.1.0-0
. Automating more of the process should help.
Resolved by #170.
Rebuild package-lock.json automatically?
I don't have much experience with javascript tools, but in other languages that use similar constructs, I found it most helpful to have the developer update package-lock.json and commit it as usual, but then have a CI component that performs some basic checks that ensure that the package-lock.json is compatible with the package.json. I'm not sure how to do this with npm
, but I will try to have a look at it, when I have time for it.
Validating the lockfile using a continuous integration step sounds like a good plan to me 👍
A mistake was made during the release of container v3.3.1-0 -- despite the tag name, it has grocy v3.3.0 inside.
In particular this item could help:
Ensure upstream grocy version tag is used consistently (i.e. in Makefile, docker-compose, package.json, ...)
(this is also identified in the incident report, #168)
Resolved by #170.