Build FAILED with VersionLocked exception but it recovers

[humitos]

If the build raises Version locked, retrying in 5 minutes. it's marked as FAILED.

Then, 5 minutes later, it's re-triggered and it changes it state to Triggered, Clonning, Installing, etc.

I suppose that we do want to re-trigger the build for the same version because it could happen that we receive two webhook one next to the other with different commits on it. So, the first build for that version does not represent the latest data.

So, I think this is a matter of UI more than a technical aspect. I think we shouldn't tell the user that the build has failed and then change the status because this is kind of confusing. Maybe we need another status to inform this, I don't know.

[offbyone]

I'm not sure you would consider this part of the design, but receiving a "build failed" email in this retryable state is somewhat odd too; there's no action I can take on that email. If I'm watching doc builds closely for some reason, I'll be on the site doing so, and if I'm not worried about it -- if I'm happy to let it slide for a while -- then I don't really need the big FAILED in my inbox.

[humitos]

We do not want to send notifications on retry.

If you are receiving any kind of email when the version is locked, it's because I introduce a bug some time ago and I already fixed it but it's not deployed yet: #4839

My idea when I opened this issue is to "not mark the status as FAILED" because when it's FAILED I suppose, as a user, that it has ended and failed. I don't expect this particular build to re-trigger and change the status as SUCCESS.

[agjohnson]

This was never closed on a release with a fix, but I think we now have a regression on this as well. I have reports from readthedocs.com of these notifications going out -- and the same, the build finally continues once unlocked and the project will successfully build.

[stale]

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.

[stsewd]

@humitos I think we shouldn't be hitting this anymore now that we are with single process builds, right?

[humitos]

That's right in production. We will still have this issue on local environment.

[humitos]

We will still have this issue on local environment.

Only if we use +1 builders.

However, I think we can close this issue since is kind of irrelevant at this point.