Add manual triggering to github action

[abigailalexander]

I've added a github action to run a scheduled image release every Wednesday at 8am. This should rebuild the docker image and push the rebuilt image with the most recent tag to the registry. This should provide a solution to pushing new tags whenever there are bug fixes in the base image we want to pull in.

Since it's a scheduled release, the latest tag can't be fetched from the github ref. I've attempted to fetch it from git tag. I haven't tested this workflow (as it will only run on the main branch at the scheduled time), but the image build/release are copied directly from code.yml. All that has changed is the assignment of tags to the image.

[AlexanderWells-diamond]

Could you please remind me what the purpose is of needing to constantly rebuild the images in this way? It seems like a lot of work for little gain.

I have some concerns with this PR:

First, I can see this rapidly becoming a storage space issue. The container isn't trivially small - the latest one in the registry is about 271MB - and so we'd be using ~1GB a month doing this. I don't know what, if any, limits exist in GH's container repo, so I'd like to confirm if this is going to cause a problem.

Second, looking at the history of packages here it doesn't look like we need this? Looking back at the released images, the last one was two months ago, then three months before that, then another three months before that. Is an automated process necessary when it only seems to be needed once every 3 months? Can we just document a manual workflow?

Third, this is a fairly large amount of duplication in CI configuration. I don't think it's a good idea to do this, for similar reasons we don't like to duplicate large amounts of code. I think it would be neater to add the schedule section to the code workflow, and then use if conditions to determine what should be run when. See help pages here; you can probably test if the github.event_name is schedule - see here

[abigailalexander]

The main reason for doing this is because as part of the public Machine Status page, coniql gets scanned for vulnerabilities by Stackrox and I have a monthly review with the cloud team over these vulnerabilities. Most of which come from the base docker image and are fixed by rebuilding the image without any changes. In order for the Machine Status page to be allowed to stay up I have to regularly fix any flagged image vulnerabilities.

Up until now I've been manually pushing a tag (without any changes to the actual coniql code) in order to trigger a rebuild and re-release of the coniql image, but that isn't good because I'm making new versions of the package without changing anything.

With regards to storage, this method should push the newly built image to the same tag and overwrite the previous, rather than pushing 4 entirely new tagged images a month. This hopefully means the storage won't be affected. You're correct that it doesn't need to be done this often however - since the CVE reviews are done monthly I could change the schedule to once a month? The two/three month schedule I've previously made rebuilds of coniql on has been to minimise the number of times I make a janky manual release

Overall, do you think making a manual triggering workflow is better than a scheduled one? I'll have a look at the links you provided and refactor to minimise the code duplication

[AlexanderWells-diamond]

To summarise the discussion we had:

• Pushing a new image to a registry does not delete anything. All pushed images are stored indefinitely until manually deleted. The only thing that changes is that the tag(s) are reassigned to the newly pushed image (as tags can only be associated with a single image)
• As we don't really want to be releasing images unless there's an actual need to, we think a manually triggered workflow will be better than a scheduled one

[rjwills28]

After reading the discussions I also agree that adding a manual workflow is probably the best option to achieve the end goal of building a new image when needed without needing to make a new tag.