build: add linux release automation and release automation validation

[pendo324]

Issue #, if available:

Description of changes

• Adds Linux release automation (unused for now)
• Adds release automation validation

Testing done

• local testing
• testing on this PR itself (and the prior PR build: add linux release automation and release automation validation #1140, which I closed in favor of this one since this is from an origin branch)

Changes to CI:

• ci.yaml will continue to run on PRs.
• ci.yaml will not run anymore on pushes to main.
• ci-release.yaml will take the place of ci.yaml on pushes to main.
• ci-release.yaml call ci.yaml internally.
• ci-release.yaml will also run on PRs when changes are made to installer builders/workflows.

Contribution agreement

• I've reviewed the guidance in CONTRIBUTING.md

License Acceptance

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[Shubhranshu153]

@pendo324 shall we close this or you do plan to get back to this in the future?

[Swapnanil-Gupta]

@pendo324 PTAL when you get a chance.

[pendo324]

@pendo324 PTAL when you get a chance.

LGTM just waiting for the tests to pass

[pendo324]

Ideally, we would only run the tests which are actually relevant for the changes which are being made. So for a change by the automated release-please PR (a change to the changelog file), we'd only run the release CI (and exit early or skip the rest of the CI). Same for the other CI types

[Swapnanil-Gupta]

Ideally, we would only run the tests which are actually relevant for the changes which are being made. So for a change by the automated release-please PR (a change to the changelog file), we'd only run the release CI (and exit early or skip the rest of the CI). Same for the other CI types

@pendo324 @Shubhranshu153 PTAL at my last commit, especially the detect-changes workflow. Open to feedback on this.

[Swapnanil-Gupta]

Also, with the detect-changes workflow, I think we can get rid of the path filters in ci.yaml and ci-release.yaml. That way we won't have to maintain the paths in two/three different places.

[pendo324]

Also, with the detect-changes workflow, I think we can get rid of the path filters in ci.yaml and ci-release.yaml. That way we won't have to maintain the paths in two/three different places.

Does this behave nicely with our repo merge rules?

[Swapnanil-Gupta]

Also, with the detect-changes workflow, I think we can get rid of the path filters in ci.yaml and ci-release.yaml. That way we won't have to maintain the paths in two/three different places.

Does this behave nicely with our repo merge rules?

I can configure CI Release workflow to run on every PR and merges into main irrespective of the changed files. The detect-changes workflow will then detect the changes in code/docs/e2e/build related items and trigger the relevant jobs.