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

Build failsafes for latest/stable retagging #3513

Closed
ericholscher opened this issue Jan 13, 2018 · 4 comments
Closed

Build failsafes for latest/stable retagging #3513

ericholscher opened this issue Jan 13, 2018 · 4 comments
Labels
Needed: replication Bug replication is required Status: stale Issue will be considered inactive soon

Comments

@ericholscher
Copy link
Member

ericholscher commented Jan 13, 2018

There are a number of classes of bugs that we have where we get stuck in build loops over and over again for builds. A few of them:

  • A person retags a tag, and two of our builders each have the tag at a different commit. Each time we rebuild, they re-update the tag
  • A person pushes and then updates/removes a tag, and our builders have a different version of stable that they keep re-updating and re-building in a loop
  • A person has a branch named latest and we had a bug where we overwrote latest twice (once for theirs, once for ours) on each build, causing a rebuild

I believe most of these bugs have been fixed, but we should have some kind of detection or failsafe against this.

Possible solution

Have a history of previous latest/stable versions in cache that goes back 5-10 versions, with a 1 day expire date. We could then check to make sure they aren't looping (the current thing we are about to set doesn't appear in the list already?). This shouldn't take too much memory if we keep a low expires date, but should at least stop a looping effect.

We should probably do something similar to user notifications and other places where a loop might be possible and really bad. Perhaps a cache of times an email address has been notified, or a version built, and cap it in some ongoing fashion?

Refs #3180

@agjohnson
Copy link
Contributor

Sounds like we need to start with replicating some of the failure cases first, so we know what we're testing/changing.

@stsewd
Copy link
Member

stsewd commented Jan 8, 2019

A person retags a tag, and two of our builders each have the tag at a different commit. Each time we rebuild, they re-update the tag

A person pushes and then updates/removes a tag, and our builders have a different version of stable that they keep re-updating and re-building in a loop

I think these two were solved with #4901 (we re-sync the versions before triggering a build), and #4876 also could help here.

A person has a branch named latest and we had a bug where we overwrote latest twice (once for theirs, once for ours) on each build, causing a rebuild

I believe that we already fix that in #4733 and/or #3913

@stale
Copy link

stale bot commented Feb 22, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the Status: stale Issue will be considered inactive soon label Feb 22, 2019
@stsewd
Copy link
Member

stsewd commented Feb 22, 2019

As my comment in #3513 (comment) I'm closing this issue.

Also, we are looking further for have aliases for latest and stable :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needed: replication Bug replication is required Status: stale Issue will be considered inactive soon
Projects
None yet
Development

No branches or pull requests

3 participants