In general this is a good idea, but from a quick look at dist-git it looks like you may have trouble finding a way to do this automatically.

The cockpit and haproxy containers both expose labels for version and release, but in one case version is capitalized and in another case it is not. In one case, they use a env var for the string, and in the other case they do not.

Does OSBS suggest best practices for how to maintain this information in the dockerfile? If so, let's follow that advice as a convention and then perhaps say that any dockerfiles which do not conform to that convention are not qualified for automatic rebuild.

(If no such best practices exist, we may need to suggest some to the community/buildsystem owners.)

@ralph I found https://github.com/projectatomic/ContainerApplicationGenericLabels/blob/master/vendor/redhat/labels.md (I'm not sure the latest status of this), however as you see in the dist-git repos, different maintainers write RELEASE in different ways. I also thought if there is already a tool to handle Dockerfile, for example, change and get metadata from LABELs like some rpmdev-* utilities.

@ttomecek Hello, is there best practices or standard specifications for how to maintain LABELs in the dockerfile? Any tool or library can be used to maintain LABELs in Dockerfile? Any idea or suggestion to this issue?

At this moment, rebuild history (or maybe called changelog), either modules or docker images, could be stored in freshmaker database #22 so that it can be reviewed in the future.

You should sync with OSBS team here: @twaugh @lucarval. I remember from back then we had tooling to perform rebuilds, I believe that Tim and Luiz will be able to provide up to date info.

Some pointers in the meantime:
https://github.com/DBuildService/dockerfile-parse
https://github.com/projectatomic/atomic-reactor/blob/master/atomic_reactor/plugins/pre_bump_release.py

atomic-reactor already has a way to avoid requiring git commits for rebuilds when Koji integration is in use: just omit the 'release' label altogether.

The bump_release plugin (see link above) will ask Koji for the next release for the given component and version, and will locally adjust the Dockerfile to set the 'release' label accordingly.

Note that this mechanism requires that 'release' is an integer representation.

@maxamillion do you know if we have the bump_release plugin in Fedora's OSBS instance?

Note that this mechanism requires that 'release' is an integer representation.

It appears that release does not need to be integer anymore:
https://pagure.io/koji/c/39e7befc6bd428f8df4e3811dbf93c0710ae2a0c?branch=master

Filed a ticket to follow up on the bump-release plugin here: https://pagure.io/atomic-wg/issue/274

Now that we're using OSBS "Isolated Builds", I am 90% sure that this ticket isn't relevant any more.