Original reporter: lenka@sepu.cz

The issue:

For now, the image build workflow is following:
push to a branch (forge-staging, forge-production, src-staging, src-production) => empty commit to oci-image-definition repo, which now does not serve for much because => the version must be manually increased on oci-image-definition repo => the image build it triggered (isolated only to the pipeline defined in the [on-cel-expression](https://codeberg.org/fedora/oci-image-definitions/src/branch/main/.tekton/forgejo-oci-images-prod-stable-push.yaml#L10))

The desired automated workflow would be:
push to one of the branches we build the image from => this triggers an action that:

1. Gets the current forgejo upstream tag
I'd suggest taking the forgejo version from a tag that forgejo upstream is using: `git describe --tags --abbrev=0`, which as an example now equals to `v13.0.4` or `git describe --tags` which in current state of things gives `v13.0.4-17-ge1a1ab4ddf` (latest upstream version - number of our commits on top - git hash of the last upstream tagged commit).

2. Modifies to our versioning
Currently the versioning we use is for example 13.0.4-1 (forgejo upstream version - our version of it. Goes up to 13.0.4-2 and more until there is new minor release, from which we start the count from 1 again: 13.0.5-1)
I see three options:

2.1. We could keep it as it is, but automate it. That means make a script that gets the latest forgejo upstream version and bumps the second number +1. If the minor version increased, start from 1. This is possible, but I find it a bit cumbersome.
2.2. We could change it to 13.0.4-5cc0f00ae3 (latest forgejo upstream - our last git commit sha). We would know immediately from which exact commit each of the builds is.
2.3. We could use the v13.0.4-17-ge1a1ab4ddf format, the direct result of `git describe --tags`. The simplest option, no additional script needed, and we know exactly the latest forgejo version, latest forgejo upstream commit + the number of our commits on top. My personal favorite solution.

3. Modifies the VERSION file in the oci-image-definition repo with that version and pushes it to oci-image-definition

4. This starts a build of the respective image(s)