Add github action that will build and push to quay.io after the other build tests a complete.

[SpheMakh]

1. This should only build and push if a Dockerfile has changed. We could this by building and pushing directly in the action environment, or by triggering a build on quay.io.

2. For releases, a create a Dockerfile that simply inherits from the previous release i.e, a duplicate image with a different tag matching the release version.

[o-smirnov]

2. For releases, a create a Dockerfile that simply inherits from the previous release i.e, a duplicate image with a different tag matching the release version.

You mean 0.1.3 would inherit from 0.1.3rc5 (if that was the last release candidate)?

Sounds sensible. One thing to mind though -- package versions like master have the semantics of "build image from latest master at time of release", which this scheme could contradict. I suppose we could have a policy of manually re-running build-cargo to ensure that images are rebuilt.

[SpheMakh]

You mean 0.1.3 would inherit from 0.1.3rc5 (if that was the last release candidate)?
yup

We write the action, so we can do what works for us

Sounds sensible. One thing to mind though -- package versions like master have the semantics of "build image from latest master at time of release", which this scheme could contradict. I suppose we could have a policy of manually re-running build-cargo to ensure that images are rebuilt.

My thinking was, if a Dockerfile has not changed, then there's no need to rebuild the image, so, if we need an image with a tag matching the new release, then we should just build and push:

FROM <image>:<last working tag>

with a tag matching the new release.

[o-smirnov]

I agree with that. We just need to be mindful of the case where the Dockerfile hasn't changed, but it's pip installing from master underneath. In this case the release workflow should ensure that the image is rebuilt with the latest payload.

[SpheMakh]

Essentially, we have to generate this file for each image in the cargo manifest

https://github.com/redhat-actions/push-to-registry/blob/5ed88d269cf581ea9ef6dd6806d01562096bee9c/.github/workflows/quay-push.yaml

[o-smirnov]

Well, I see two routes here:

• add a feature to build-cargo to auto-generate this file for each image

• directly invoke build-cargo itself from the github action

[SpheMakh]

Th second option is the path of least resistance, we just need to be able to track which images have changed since the last release to avoid re-building unnecessarily. This information must be somewhere in the /.git folder.

[o-smirnov]

I think the hashing system already ensures that image layers that haven't changed aren't pushed?