Commit build failure can't be overridden with "==OVERRIDE=="

[raiju]

Build failure on one of a commit can block merging even when the build on the full PR succeeds. Trying to override through "==OVERRIDE==" didn't work either (stashbot wasn't in strict mode).

[raiju]

Also, retriggering a build on the commit doesn't help. After succeeding it still shows the PR has a failed build. When clicking on that link, the first failed build is still opened.

[terabyte]

@raiju - this might be due to stash getting into an invalid state due to a race condition.

There is supposed to only ever be a single row of PR metadata for each PR, but if there is more than one, it is possible to observe this behavior.

1. Do you have this repository configured to "Rebuild merge verifies when target branch updates"?
2. Are there any errors in the logs that look related?
3. select * from "AO_BG11572_PRMETADATA001" where FROM_SHA = X and TO_SHA = Y and see how many rows you get, where X and Y are the source and target sha1s. If you have multiple mirrors of that repo, add in the REPO_ID and/or PR_ID fields.

[raiju]

To answer your first question, yes, that option is enabled, but I don't have ready access to the logs to confirm the race condition theory.

I don't think that's the problem though. This seems to happen only when verifies are run on both commits and PRs. I would be surprised if it were a race condition, as I've observed this for cases where the PR was created long after the commit was pushed & built. Also, operations that change the actual commits in a PR (e.g. rebasing & force pushing) fix the problem (unless one of the commit builds fail, of course). The impression I get is that the operation used to check whether merge is allowed is something like:

buildSuccess(commit) && (buildSuccess(PR) || overrideEnabled) && approval > threshold

The override should, in my opinion, apply to both build steps. Anyway, this is a low-priority problem, as this can be by-passed by doing the git work manually.