Hey! We try to pin all of our dependencies so that they don't unexpectedly update in production. We use updatecli to do this, which can look at GitHub releases or container image tags, and compare by semvers. Updatecli then opens a pull request with proposed upgrades, then we can review and merge to apply them (similar to the flux image updater automation). I know the SpiceDB Operator can pin to specific versions, but we would still have to figure out the latest stable version manually (or check the operator's output, but updatecli runs in GitHub Actions so has no access to our internal infra). I also suppose that we could read the JSON file in the operator repo, but that does not seem to be a standard approach. Does anyone have tips/advice here?

Not sure if this would work for you, but you could enable auto-updates for your SpiceDBClusters, then updatecli would make PR to update the operator which you would know can update the running version of spicedb I'm not very familiar with updatecli, is it something we could contribute to and teach it about spicedb versions?

updatecli defines sources (e.g. GitHub release API or docker image list) and based on that can retrieve versions and filter based on them. It usually works off semvers, but we can also pin to digests. So if the format you're using for versioning is some kind of standard, then I think you could convince them to accept a PR for your feed type. There's three stages in the updatecli pipeline: 1. sources (get list of candidate versions and select one of the versions, usually by identifying the most recent semver) 2. transformations (manipulate the selected source, e.g. if you need to trim a "v" prefix or add it, or something like that) 3. targets (files to update, e.g. update a YAML file in a specific field) Some simpler alternatives might be to: * publish separate tags for each channel, e.g. 1.23.1-stable and 1.23.1-rapid (we can filter tags to evaluate using a regex), or * publish tags for each channel, e.g. v1.24.0 is also "latest" but you could also publish it as "rapid" and v1.23.1 as "stable" (then someone can docker pull ...:stable and get the latest stable version, and we can use that to pin the digest of the latest stable release), or * images, e.g. publish the same image as ghcr.io/authzed/spicedb-stable:1.23.1 and ghcr.io/authzed/spicedb-rapid:1.23.1 (the nour update automation can pick the latest version tag from spicedb-stable) The nice thing about updatecli is that it can be very flexible, since it can write to any field in any file The problem is that updatecli is running in GitHub Actions and GitHub Actions has no access to our cluster. Basically our workflow is: 1. GitHub Actions job runs updatecli periodically to detect latest versions 2. If there's a change, updatecli will open a pull request to update the manifests we've stored in GitHub with a new version 3. We review the PR, merge it 4. Flux updates our cluster based on the current manifest state in GitHub repo

Thanks for the overview! I don’t think tags will work because we will occasionally pull a release from the graph (but not the tag, just the incoming edges)

Ah, we do version the operator! That's good to know. I wasn't sure if the operator was pulling from the repo at runtime (we don't have a super restrictive network config right now heh)

Nope the graph is built into the image

Nice!

it's just a file in the fs, so for our managed services we do roll those out separately. but the upstream operator builds it in, so pinning the operator (and using autoupdates) will "pin" the SpiceDB version to the latest for a given operator version.