Make release action PR instead of push directly

[hozkaya2000]

Summary

• Changes to Github InitiateReleaseAction to create a PR instead of push directly to the repository.
• Also adds schedule for the action to run on.
• Also adds CODEOWNERS file to prevent non-aws-agent team members from triggering the github action.
• Use the actions/checkout@v4.

Implementation details

There is no longer a push in the github action to the aws/amazon-ecs-ami repository main branch. It now creates a branch for the release and pushes everything there. Then, if this is successful, it opens a pull request for the release. Instead of pushing to codecommit the latest main branch, it instead pushes the created branch. The reviewer then reviews both the internal and GH open PR at the same time.

Testing

The following InitiateRelease was updated in my personal fork: https://github.com/hozkaya2000/amazon-ecs-ami/blob/main/.github/workflows/initiaterelease.yml (Note that it is the exact same workflow with only credentials and resources changed)

Successful run when there's no release needed: https://github.com/hozkaya2000/amazon-ecs-ami/actions/runs/8026018193/

Successful run when there's a release needed: https://github.com/hozkaya2000/amazon-ecs-ami/actions/runs/8026056794

New tests cover the changes: n/a

Description for the changelog

Enhanced AMI Release Action Updates

Licensing

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

[danehlim]

The reviewer then reviews both the internal and GH open PR at the same time.

If there are any issues with the changes, the releaser will need to raise a new revision on the open pull request to address the issues, but the changes with issues were never merged into main branch in amazon-ecs-ami repository since the pull request was not yet merged. However, for CodeCommit, the changes with issues were already pushed. Won't that mean our internal CodeCommit will be out of sync with the amazon-ecs-ami repository?

[singholt]

The reviewer then reviews both the internal and GH open PR at the same time.

If there are any issues with the changes, the releaser will need to raise a new revision on the open pull request to address the issues.

No, they would need to close the PR, fix the GH action and re-run the fixed GH action. The runbook will have these steps documented.

[danehlim]

The reviewer then reviews both the internal and GH open PR at the same time.

If there are any issues with the changes, the releaser will need to raise a new revision on the open pull request to address the issues.

No, they would need to close the PR, fix the GH action and re-run the fixed GH action. The runbook will have these steps documented.

What about the changes with issues already pushed to CodeCommit? Does re-running the GH action re-sync CodeCommit with the amazon-ecs-ami repository (i.e., automatically gets rid of the problematic change already pushed to CodeCommit from CodeCommit's git history)? Or will re-syncing CodeCommit be manual steps that the releaser will complete by following runbook steps?

[hozkaya2000]

The reviewer then reviews both the internal and GH open PR at the same time.

If there are any issues with the changes, the releaser will need to raise a new revision on the open pull request to address the issues.

No, they would need to close the PR, fix the GH action and re-run the fixed GH action. The runbook will have these steps documented.

What about the changes with issues already pushed to CodeCommit? Does re-running the GH action re-sync CodeCommit with the amazon-ecs-ami repository (i.e., automatically gets rid of the problematic change already pushed to CodeCommit from CodeCommit's git history)? Or will re-syncing CodeCommit be manual steps that the releaser will complete by following runbook steps?

Actually rerunning PushToCodeCommit will clean everything up because the delete branch command cleans all previous changes in the codecommit history, as long as the normal repo is fixed, codecommit will be fine