[Build] Unify mark build jobs and migrate them to pipeline

[HannesWell]

Unify the previously two jobs to mark a build as stable and unstable into one pipeline job, that has a choice parameter for the type of marker to apply.

This allows to reduce the number of jobs from two to one and also allows to extend to types of markers to apply. For example to have a RETAINED_INDEFINITELY (respectively its reverse NOT_RETAINED), which will prevent the automated clean-up jobs from potentially deleting a specific I- or Y-build drop (for any reasons) or even an old release, as I have already drafted in

• [Build] Unify clean-ups jobs as Jenkins pipelines and inline scripts #3322

For the occasional task to mark a build as unstable (or stable again, which seldomly happens) the following replacements apply

• Mark Unstable -> Mark build with markAs choice of UNSTABLE
• Mark Stable -> Mark build with markAs choice of STABLE

I have renamed unstable to NOT_STABLE to match the choices I plan to add, as described above. But if you prefer UNSTABLE, I can also use that. The choices continue to be STABLE and UNSTABLE.
@iloveeclipse, @akurtakov, @merks or @HeikoKlare FYI as I assume you are the ones that mark builds as unstable if necessary.

[HeikoKlare]

Sounds good to me. Just a nitpick: maybe we can rather call it something like "Mark stability" instead of "Mark build" to have a less generic name?

[HannesWell]

Sounds good to me. Just a nitpick: maybe we can rather call it something like "Mark stability" instead of "Mark build" to have a less generic name?

Thanks. Because I want to extend the job's capabilities with subsequent PRs (as described above), I think the job name and thus URL should be generic. But making the display name more specific (and extending it accordingly in subsequent changes), sounds good to me. I'm about to change the display name to Mark build stability.

[HeikoKlare]

Because I want to extend the job's capabilities with subsequent PRs (as described above)

Ah, I missed that sentence. Thank you for the explanation. I just saw the other mark-build-... job in Jenkins, but that's obviously only a test job of yours 🙂 Then it would also be okay for me to just stick to the initial name you proposed.

[HannesWell]

Because I want to extend the job's capabilities with subsequent PRs (as described above)

Ah, I missed that sentence. Thank you for the explanation. I just saw the other mark-build-... job in Jenkins, but that's obviously only a test job of yours 🙂 Then it would also be okay for me to just stick to the initial name you proposed.

Yes. Testing in advance avoids noise in git and trouble for me and all of those that want to use it 😅

Then it would also be okay for me to just stick to the initial name you proposed.

Yes. Thinking about it again, even the display name shouldn't be too verbose (yet still clear). But we can add more explanations in the description.

Thanks for your input.