e03d8c887c
This is a prelude to a change which will report a distinct buildset result to the database if the upstream code review system is unable to merge a change. Currently it is reported as MERGER_FAILURE which makes it difficult to distinguish from merge conflicts. Essentially, the two states we're interested in are when Zuul's merger is unable to prepare a git checkout of the change (99% of the time, this is a merge conflict). This will be known as MERGE_CONFLICT now. The second state is when Zuul asks Gerrit/Github/etc to submit/merge a change and the remote system is unable (or refuses) to do so. In a future change, that will be reported as MERGE_FAILURE. To avoid confusion and use names which better reflect the situation, this change performs the rename to MERGE_CONFLICT. Because there are pipeline configuration options tied to the MERGER_FAILURE status (which start with 'merge-failure') they are also renamed to 'merge-conflict'. The old names are supported for backwards compatibility. A SQL migration takes care of updating values in the database. The upgrade procedure is noted as being special because of the db value updates. If an operator doesn't follow the recommended procedure, however, the consequences are minimal (builds which won't be easily queried in the web ui; that can be manually corrected if desired). A model API change is not needed since the only place where we receive this value from ZK can be updated to accept both values. Change-Id: I3050409ed68805c748efe7a176b9755fa281536f |
||
|---|---|---|
| .. | ||
| fixtures | ||
| remote | ||
| unit | ||
| zuul_client | ||
| __init__.py | ||
| base.py | ||
| encrypt_secret.py | ||
| fake_graphql.py | ||
| fakegithub.py | ||
| fakegitlab.py | ||
| make_playbooks.py | ||
| print_layout.py | ||