docs: add overview of automated releases in readme

[kleyow]

[millerabel]

If I reason about this as a release candidate that is pulled and built (after a push to the main branch), it’s not yet tagged. So we must have built the untagged images, yes? The images should be scanned and post build steps completed before the release tag is pushed.

I think we’re doing all that.

If you get this far, the final step is to be sure we tag the release and that the tagged release can be pulled and built.

If building the tagged release fails to verify, someone has to remedy the failure manually, push a patch, then re-verify (by pulling the patched release candidate and rebuilding, scanning, and testing the images).

The final release tag would then read something like “17.3.1” rather than “17.3.0”. This image is released as “17.3” for external communications, but it is released with a patch, and so the patch level for the 17.3 release is already at “.1” Others will surely follow. :-)

So the question, if I pull 17.3, do I get the latest patch level of each file (17.3.1 in this hypothetical)?

And do we replace previous patch level verified images with only last known good? (If not, why not?)

So if someone uses the last known good docker images, there is a patch-level matching tagged release, even as work proceeds on the main branch.

I realize I may not fully understand the issue or the disconnect, please point out my errors!

-- Miller

On Mar 5, 2021, at 5:08 AM, Miguel de Barros [email protected] wrote:

 @mdebarros commented on this pull request.

In README.md:

+and image builds. This process essentially mimics a manual tag and release.

+On a merge to master, CircleCI is configured to use the mojaloopci github account +to push the latest generated CHANGELOG and package version number. + +Once those changes are pushed, CircleCI will pull the updated master, tag and +push a release triggering another subsequent build that also publishes a docker image. + +### Potential problems + +* There is a case where the merge to master workflow will resolve successfully, triggering

• a release. Then that tagged release workflow subsequently failing due to the image scan,
• audit check, vulnerability check or other "live" checks.
• This will leave master without an associated published build. Fixes that require
• a new merge will essentially cause a skip in version number or require a clean up Would it not be possible to check if there is an associated release?

I.e. only increment the version if there was a successful publish.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[kleyow]

So the question, if I pull 17.3, do I get the latest patch level of each file (17.3.1 in this hypothetical)?

Yes.

“17.3” for external communications

I wasn't sure how external parties handle their version pulling, but if they target versions like that they shouldn't have to worry as long as the latest patch has been built properly

And do we replace previous patch level verified images with only last known good? (If not, why not?)

Not entirely sure what is being said here. If say 17.3.1 failed to publish an artifact and 17.3.2 published properly. 17.3.1 would have no associated artifact and would need manual intervention if we want to make sure we always have a 1:1 relationship.

So if someone uses the last known good docker images, there is a patch-level matching tagged release, even as work proceeds on the main branch.

If I'm understanding your statement correctly then yes.

Hmm. Maybe some build infographics would help us...

[kleyow]

Forgive me at this awful attempt to visualize what I'm thinking are edgecases.

[elnyry-sam-k]

@kleyow - would it be possible to bring this up to date, so that we can merge it? If not its getting stale and we may have to close it

[kleyow]

@elnyry-sam-k I think the comment changes still apply to automated releases but I didn't really address other's comments. At the end of the day the the CI really just automates how we currently do releases but maybe not in the same order...in retrospect I should try and change it.

Only possible way to update this to address comments, is to improve and give the CI another pass to eliminate edge cases. The comment changes still stand but the edge cases haven't really happened in the year we've had it churning some of our builds.

Manually

• Push change with version bump included.
• CI PR checks pass.
• Merge into master.
• Master CI checks pass.
• Tag version.
• Push version to Github.
• Version CI pass. Published to docker hub.
• Release made in github releases.

Automated

• Push change no version bump.
• CI PR checks pass.
• Merge into master.
• Master CI checks pass and CI pushes new commit bumping package version/changes based on commit.
• New commit skipped since it's just a non functional bump.
• CI tags and pushes tag.
• Standardized release and notes made in github releases before Version CI passes (this should be re-ordered) til below the version CI passing.
• Version CI pass. Published to docker hub.

edit: wording

[kleyow]

Feel free to merge it/close it/make a story for improvements or story to remove the automated ci.