Update LTS Pipeline

[chkim-usgs]

Description

Re-introduces the bugfix cherry-picking with the addition of the ISIS Codebuild pipeline.

Workflow:

1. When a bugfix is merged into dev, a GitHub workflow (gitlab-lts.yml) will be triggered.
2. The LTS workflow will check for the bug label on the PR or append labels if related issues exist under the Related Issue header in the PR body.
3. If the PR is a bugfix, the workflow triggers a Codebuild build.
   1. LTS_VERSION and BASE_LTS are environment variables. LTS_VERSION is the upcoming LTS version (i.e., 8.0.5_LTS) and should be bumped after every LTS release. BASE_LTS is the major version of the LTS that is being supported for the remainder of the LTS period (i.e., 8.0).
   2. The build job checks if the LTS_VERSION branch already exists (since bugfixes are cherry-picked into the same LTS version until it is released) and overwrites the branch with the latest main isis-codebuild-ci changes. This is an easier way to support writing a new GITHUB_SHA to the buildspec-lts.yml each time.
   3. The Codebuild process will cherry-pick, build, and test the bugfix against the LTS branch. If either the merge or tests fail, this will have to be manually addressed by a developer.

Related Issue

How Has This Been Validated?

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Documentation change (update to the documentation; no code change)
• Breaking change (fix or feature that would cause existing functionality to change)
• Infrastructure change (changes to things like CI or the build system that do not impact users)

Checklist:

• I have read and agree to abide by the Code of Conduct
• I have read the CONTRIBUTING document.
• My change requires a change to the documentation and I have updated the documentation accordingly.
• I have added tests to cover my changes.
• I have added myself to the .zenodo.json document.
• I have added my user impacting change to the CHANGELOG.md document.

Licensing

This project is mostly composed of free and unencumbered software released into the public domain, and we are unlikely to accept contributions that are not also released into the public domain. Somewhere near the top of each file should have these words:

This work is free and unencumbered software released into the public domain. In jurisdictions that recognize copyright laws, the author or authors of this software dedicate any and all copyright interest in the software to the public domain.

• I dedicate any and all copyright interest in this software to the public domain. I make this dedication for the benefit of the public at large and to the detriment of my heirs and successors. I intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights to this software under copyright law.

[github-actions]

The build and test suite have started for your pull request.

To view your build log, please reference the build with source version: "PR_5714".

Additionally, check the latest "dev" source version to identify existing test failures. Please note that you are not responsible for the test failures that exist on both your PR and the dev branch.

[github-actions]

The build and test suite have started for your pull request.

To view your build log, please reference the build with source version: "PR_5714".

Additionally, check the latest "dev" source version to identify existing test failures. Please note that you are not responsible for the test failures that exist on both your PR and the dev branch.