docs: add overview of automated releases in readme #823
Conversation
kleyow
requested review from
elnyry-sam-k,
lewisdaly,
mdebarros,
oderayi,
shashi165,
vgenev and
vijayg10
as code owners
| 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 |
There was a problem hiding this comment.
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.
| is a boon. | ||
|
|
||
| * It is unknown if a race condition might occur with multiple merges with master in | ||
| quick succession, but this is a suspected edge case. |
There was a problem hiding this comment.
This could only be an issue if a later build finishes prior to an earlier build, or can you think of any other situation where this would be possible?
I do not believe CircleCI has the ability to ensure the above consistency, in fact here is a feature request for that very purpose: https://discuss.circleci.com/t/prevent-concurrent-builds-of-a-branch/1142
But as you can see from that request, CircleCI does cancel redundant builds if configured as such. We currently have this enabled. This should help ensure that this does not occur.
There was a problem hiding this comment.
https://github.com/bellkev/circle-lock-test <-- there is an apparent work-around.
|
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.
|
Yes.
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
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.
If I'm understanding your statement correctly then yes. Hmm. Maybe some build infographics would help us... |
|
Forgive me at this awful attempt to visualize what I'm thinking are edgecases.
|
|
@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 |
|
@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. Manually
Automated
edit: wording |
|
Feel free to merge it/close it/make a story for improvements or story to remove the automated ci. |
No description provided.