Ideas for automation of release process

[jayaddison]

• [ ] Ensure changelog is populated prior to release
• [x] Ensure release commit is tagged and that an associated release is packaged (solved via #111)
• [x] Ensure upstream grocy version tag is used consistently (i.e. in Makefile, docker-compose, package.json, ...)
  • [x] Migrate GitHub actions workflow to retrieve application version from git tag (#169)
  • [x] Removed package.json and package-lock.json files (and the associated container release version references in them) (#170)
  • [ ] Makefile version reference improvements
  • [ ] docker-compose.yml version reference improvements
• [x] ~~Rebuild package-lock.json automatically?~~ (outdated due to file removal in #170)
• [x] 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
• [x] ~~Tag the latest image on Docker Hub?~~ (currently a WONTDO)

It may be possible to perform some of these checks by using git pre-commit / pre-push scripts.

[jayaddison]

Additional idea: automatically run vulnerability scans (during pull requests and/or release packaging).

Resolved by v3.3.1-3.

[jayaddison]

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.

[Kritzefitz]

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.

[jayaddison]

Validating the lockfile using a continuous integration step sounds like a good plan to me :+1:

[jayaddison]

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.