<div dir="ltr"><div>Hi,<br></div><div><br></div><div>we have some independent APBs, like for 3scale, Keycloak or AeroGear Digger, and those live in their own GH repository. We recently have converted their matching Dockerhub repositories to be build automatically once changes on the source code occur:</div><div><br></div><div>* master changes (e.g. PRs got merged) -> triggers a new build of the "latest" docker image</div><div>* Tags: pushing a new tag in github triggers a build of a "tagged" docker image. Current convention: GH tag == Docker tag (e.g. a version like "0.0.5" is same in both worlds)</div><div><br></div><div>How should we run releases for these APB repos ? </div><div><br></div><div>Usually after changes did land on master, and there is a *demand* for a release, the last commit is used, and a tag is created and pushed to github. This also - as stated above - does release a matching Docker image to the wild. So far so good</div><div><br></div><div>For automation, we could use a little script like:</div><div><br></div><div>```bash</div><div>version="0.0.7-rc"                                                                              </div><div>latest_commit="$(git rev-parse HEAD)" | git tag -a ${version} ${latest_commit=} -m "signing tag" && git push origin ${version}</div><div>```</div><div><br></div><div>I personally would like to use -s, instead of -a, to actually sign the tag. This is a good practice that we are doing in AeroGear land (and other jboss projects). For more see [1].</div><div><br></div><div>Any thoughts?</div><div>-Matthias</div><div><br></div><div>PS: working on something similar for the MCP itself, which is a bit more tricky ;-)</div><div><br></div><div><br></div><div>[1] <a href="https://github.com/aerogear/collateral/wiki/Release-Process-(Java)">https://github.com/aerogear/collateral/wiki/Release-Process-(Java)</a></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Project lead AeroGear.org</div></div>
</div>