When the result of a job, stage or pipeline is unstable, do not map it to success when sending webhooks. The webhooks intake now accepts unstable as a status. This lets us remove the two different mappings (jenkins result -> ci visibility status) we had depending on whether we send webhooks or traces.
It also removes some unused variables and imports, sorry if it adds a bit of noise to the PR.
Review checklist (to be filled by reviewers)
[ ] Feature or bug fix MUST have appropriate tests (unit, integration, etc...)
[ ] PR title must be written as a CHANGELOG entry (see why)
[ ] Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
[ ] PR must have one changelog/ label attached. If applicable it should have the backward-incompatible label attached.
[ ] PR should not have do-not-merge/ label attached.
[ ] If Applicable, issue must have kind/ and severity/ labels attached at least.
What does this PR do?
When the result of a job, stage or pipeline is
unstable, do not map it tosuccesswhen sending webhooks. The webhooks intake now acceptsunstableas a status. This lets us remove the two different mappings (jenkins result -> ci visibility status) we had depending on whether we send webhooks or traces.It also removes some unused variables and imports, sorry if it adds a bit of noise to the PR.
Review checklist (to be filled by reviewers)
changelog/label attached. If applicable it should have thebackward-incompatiblelabel attached.do-not-merge/label attached.kind/andseverity/labels attached at least.