Reduce the number of files in which the GROCY_IMAGE_TAG value has to be updated during version upgrades #170
Conversation
…plication version
These are currently used purely for Snyk-based container vulnerability scanning; this should be moved into a GitHub Actions workflow for visibility
| @@ -23,7 +23,7 @@ jobs: | |||
| uses: redhat-actions/buildah-build@v2.9 | |||
| with: | |||
| image: backend | |||
| tags: ${{ github.event.release.tag_name }} | |||
There was a problem hiding this comment.
As a result of these changes, grocy/frontend and grocy/backend images will be published using both the grocy application version tag (vX.Y.Z) and also the grocy-docker container version tag (vX.Y.Z-n_iteration).
For example, the next expected version of them will be:
backendwith tagsv3.3.1,v3.3.1-2frontendwith tagsv3.3.1,v3.3.1-2
This allows the "current" Grocy v3.3.1 image to be pulled without knowing the grocy-docker iteration number.
It also allows customers to stick to a specific container iteration if they prefer.
And as a result, these allow the iteration number to be removed from the docker-compose file (and README) - building using that will pull the latest-available version per-Grocy-release.
| "main": ".", | ||
| "scripts": { | ||
| "build": "docker-compose build", | ||
| "test": "npm run build && npm run test:backend && npm run test:frontend", |
There was a problem hiding this comment.
This package.json file (and associated package-lock.json) is used purely to provide support for Snyk containerfile vulnerability scans.
Although there are some tradeoffs, it seems better overall to perform that as part of GitHub Actions workflows, and so these files are removed in preparation for that.
(see also a related note at #109 (comment))
These files contained the grocy-docker container iteration release number, for no particularly good reason, and so it also simplifies the release process and makes it less error-prone by removing these files.
Relates to #109, #168.