Keep most recent successful nightly

[thomashampson]

Description of work

Added a stage to the end of the Jenkins build/test/deploy nightly pipeline. If all previous stages pass, the current build will be marked as "Keep this build forever", and previous builds that were automatically kept are "un-kept". If a developer manually keeps another previous build, it will be untouched by this new pipeline stage (as long as they don't set the description to "Automatically preserving the most recent successful nightly").

Purpose of work

It is useful to have a successful nightly to compare with failed nightlies so that we can diagnose the failure. In the past we have had so many consecutive failures that the most recent successful run has fallen off the end of the list. This will prevent that from happening.

Fixes #38147

To test:

Using the Core_Team_test_pipeline, run this branch (38147_keep_most_recent_successful_nightly) but with BUILD_DEVEL and BUILD_PACKAGE both set to none. It only takes about 10 seconds to complete the build. You can run it several times with different test criteria. Ensure that it:

• keeps the latest successful build and adds the build description "Automatically preserving the most recent successful nightly"
• un-keeps previous builds where the description is "Automatically preserving the most recent successful nightly" and resets the description to an empty string
• does not touch any other builds that have been "kept forever" if thier descriptions are empty or have antoher manually entered string value
  Be creative with your testing and try to find edge cases where it doesn't work.

This does not require release notes because it's a pipeline addition that doesn't affect the software

---

Reviewer

Please comment on the points listed below (full description).
Your comments will be used as part of the gatekeeper process, so please comment clearly on what you have checked during your review. If changes are made to the PR during the review process then your final comment will be the most important for gatekeepers. In this comment you should make it clear why any earlier review is still valid, or confirm that all requested changes have been addressed.

Code Review

• Is the code of an acceptable quality?
• Does the code conform to the coding standards?
• Are the unit tests small and test the class in isolation?
• If there is GUI work does it follow the GUI standards?
• If there are changes in the release notes then do they describe the changes appropriately?
• Do the release notes conform to the release notes guide?

Functional Tests

• Do changes function as described? Add comments below that describe the tests performed?
• Do the changes handle unexpected situations, e.g. bad input?
• Has the relevant (user and developer) documentation been added/updated?

Does everything look good? Mark the review as Approve. A member of @mantidproject/gatekeepers will take care of it.

Gatekeeper

If you need to request changes to a PR then please add a comment and set the review status to "Request changes". This will stop the PR from showing up in the list for other gatekeepers.

[jclarkeSTFC]

It looks like it works when I tested it, but I can't do things like add/remove descriptions on Jenkins builds through the web interface, so maybe someone from the DevOps teams should have a go.

[MohamedAlmaki]

LGTM tested multiple scenarios and worked as expected