chore: add Github action to create release PR

[phantumcode]

• PR conforms to Pull Request guidelines.

Issue #, if available:

Description of changes:

How did you test these changes?
Adding Github action to automate the initial release PR with update versions for Liveness and Authenticator.
Depends on changes from this PR: aws-amplify/amplify-ci-support#179

Release action will update the following files:

• Update the module/CHANGELOG.md
  • module changelog will ignore and exclude commits for other components based on the commit message scopes
• Update the VERSION_NAME in module/gradle.properties
• Update version used in sample app. NOTE: the amplify version in the sample apps is not updated and will need to manually verify/update for now as part of the release PR review.
• Update module version in top-level README and module READMEs
• Update the pull request template to ensure that commit message scopes are validated

Documentation update required?

• No
• Yes (Please include a PR link for the documentation update)

General Checklist

• Added Unit Tests
• Added Integration Tests
• Security oriented best practices and standards are followed (e.g. using input sanitization, principle of least privilege, etc)

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

[mattcreaser]

UI components are released independently - it seems like this will release both at once with one version? Unless I'm missing something.

[phantumcode]

Yes, it will release both components at the same time. I'll update it so the components are released independently.

[phantumcode]

@mattcreaser I've updated the action so that each component can be released separately as a GH workflow dispatch input.

[tylerjroach]

How is the changelog created. Ex: if we are releasing liveness is it going to inclue authenticator commits in changelog. This could be problematic when we then go to release authenticator and those changes are not included in changelog.

This effort is the reason we hadn't automated it yet. If this part has been resolved (including changes only for plugin between now and previous release + any core dependency updates during that time), this would be extremely helpful.

[phantumcode]

@tylerjroach Good callout, I've updated the configuration and changelog generation so that it accounts for commit message scopes. The changelog generation for Liveness will exclude all commits that is scoped for Authenticator and vice-versa. All commits without a scope or isn't marked as ignored/exclude will be included by default.

[tylerjroach]

@phantumcode You may have already covered this, but as an example. Lets say we update the material 3 library.

chore(all): Update Material3 library

Will both the next release of liveness and authenticator include this change? Or will only the first of these released include it? Sorry for asking so many questions, its difficult to fully understand what is being generated without seeing examples.

[phantumcode]

@tylerjroach By default, both releases will include commits that are not part of the ignore/exclude list. So in your example, both releases will include the chore(all). We can potentially improve that by having an explicit rule to ensure that all commits with scope of all or core always get included as well if that makes things clearer.

[phantumcode]

We could formalize this by requiring all commits to have scope of either liveness, authenticator, or all