Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: add overview of automated releases in readme #823

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

kleyow
Copy link
Contributor

@kleyow kleyow commented Feb 28, 2021

No description provided.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://github.com/bellkev/circle-lock-test <-- there is an apparent work-around.

@millerabel
Copy link
Member

millerabel commented Mar 5, 2021 via email

@kleyow
Copy link
Contributor Author

kleyow commented Mar 5, 2021

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
Copy link
Contributor Author

kleyow commented Mar 7, 2021

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

release_flow

@elnyry-sam-k
Copy link
Member

@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
Copy link
Contributor Author

kleyow commented Feb 23, 2022

@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
Copy link
Contributor Author

kleyow commented Feb 23, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants