Flux: More specific automator policies

[paulbellamy]

As container solutions, I'd like more specific control over what the automator is doing, so that I can push images willy-nilly without having them all be deployed.

In more detail, they are pushing images to quay for feature-branches, which then the automator just deploys. They move a tag to indicate the latest master. Because of this, just deploying the "newest" available image is not good enough. It might be good if the automator had a "track tag" mode.

[philwinder]

For more information, the setup that I like to use is:

| Tag | Meaning |
| --- | --- |
| 0.3.4 | A tag, released by github |
| latest | The same as the latest released tag |
| snapshot | The latest commit on master |
| 518ad9e0f9e45... | A particular commit |

So as developers, we can test specific commits to make sure they do what we want them to do.

And ideally, we would then perform a release, which would create a new tagged version and move the latest tag to that. Then the staging environments would see that change and use the new image according to whatever rule is in place.

Rules could be:

• Just latest
• Just snapshot
• Any new tag
• NPM style tags. E.g. ~0.3.1 for any new patch, ^0.3.1 for any new minor or * for any major
• Other style tags. E.g. 0.3.*, 0.*, * could mean the same thing as above.

[squaremo]

Yeah, we really do the dumbest thing that works, which is to look for the most recent image. There are many completely reasonable practices that will trip that up :(

Following a tag might not be too difficult: the trick is that for Kubernetes to notice it's a new image, it needs to have a different name. But we could figure out which unique image name is aliased by the tag, and use that.

The version selectors would be pretty cool. I'm not sure how many people go from version number to version number, rather than commit to commit, mind you.

[paulbellamy]

Based on @philwinder's comments above, I'd say we could do a "tag matcher".
e.g. fluxctl automate -s my-service --tag=~0.3.1 default being --tag=*. Then to track snapshot you could do fluxctl automate -s my-service --tag=snapshot, and it would only deploy new images with the matching tag.

Afaict that should cover roughly all use cases. Though, possibly a wild-card tag matcher would allow non-semver matching, e.g. master-* like we use.

Edit: "tag filter" might be a more accurate name than "tag matcher".

[philwinder]

Example use case: I want to automatically update to the most recent version of the mongo:3 container. But I sure as hell don't want to run the tag mongo:3-windowsservercore!! ;-)

[paulbellamy]

Note, this would have prevented us from breaking dev flux by pushing a random image to quay repo.

[SamMorrowDrums]

Yes, I'm seriously for this. I think the ability to deploy semver tags would be the ideal vehicle for production CI

For development / other workflows a simple wildcard would be ideal master-* would be ideal.

[samb1729]

TODO:

• [x] Core functionality (in #589)
• [x] CLI for updating/removing tag globs (in #647)
• [x] Web UI for end users @foot

[samb1729]

Flux: enable automated releases for versions other than "latest"