gha(amplify-preview): use custom action to generate Amplify previews for Teleport Docs

[taraspos]

Summary

This PR adds new custom workflow which will prepare Amplify preview URLs using custom action amplify-preview instead of native Amplify's integration with Github because of following problems:

• Hard limit of 50 previews per app¹
• Lack of functionality to filter PRs based on modified path (we need previews only for PRs when docs/ were modified)
  • Filter automatic Github PR previews based on labels, name, files modified aws-amplify/amplify-hosting#3960

Existing aws-amplify-us-west-2 bot will be disabled separately via AWS APIs.

Testing

#48512 (comment)

Footnotes

1. https://docs.aws.amazon.com/general/latest/gr/amplify.html ↩

[aws-amplify-us-west-2]

This pull request is automatically being deployed by Amplify Hosting (learn more).

Access this pull request here: https://pr-48512.d3pp5qlev8mo18.amplifyapp.com

[hugoShaka]

By any chance, now that you're using a custom workflow, would it be possible to tweak the job summary to output informations about how/where we can see the amplify deployment result to troubleshoot?

Currently the check indicates

This check concluded as failure.

<link to some AWS resource without any AWS account ID so I have no idea in which account I should log in to see this, or if I even have enough rights>

And I've been unable to find the deployment logs and understand why my PR is red.

[taraspos]

By any chance would it be possible to tweak the job summary to output informations about how/where we can see the amplify deployment result to troubleshoot?

Currently the check indicates

This check concluded as failure.
<link to some AWS resource without any AWS account ID so I have no idea in which account I should log in to see this, or if I even have enough rights>

And I've been unable to find the deployment logs and understand why my PR is red.

This makes sense, however the action itself is very generic and I didn't want to include to include any Teleport specific information in there publicly. What we could do is to:

1. Create notion page with debugging information
2. Add step to print link to the notion page in case of failures

[hugoShaka]

This makes sense, however the action itself is very generic and I didn't want to include to include any Teleport specific information in there publicly. What we could do is to:

1. Create notion page with debugging information
2. Add step to print link to the notion page in case of failures

I think # 2 would be perfect :)

Documenting on Notion is nice but most developpers won't know where to find the page when they see the error. Having a job printing the basic troubleshooting steps (e.g. open AWS account X, go there, check job X) in case of failure and maybe surfacing it in the PR with an error message would save us a lot of time.

e.g.

jobs:
  amplify-preview:
    name: Prepare Amplify preview URL
    runs-on: ubuntu-22.04-2core-arm64
    environment: docs-amplify
    steps:    
    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502 # v4
      with:
        aws-region: us-west-2
        role-to-assume: ${{ vars.IAM_ROLE }}

    - name: Create Amplify preview environment
      uses: gravitational/shared-workflows/tools/amplify-preview@tools/amplify-preview/v0.0.1
      with:
        app_ids: ${{ vars.AMPLIFY_APP_IDS }}
        create_branches: "true"
        github_token: ${{ secrets.GITHUB_TOKEN }}
       wait: "true"
   - name: Print debugging info
     if: failure()
     run: 'echo "::error file=docs/README.md,title=AWS Amplify deployment failed::To troubleshoot, log into the AWS account X, in the Y region, then open the failed amplify job link."'

[taraspos]

@hugoShaka, done see: https://github.com/gravitational/teleport/actions/runs/12435005179/job/34719898001?pr=48512

[public-teleport-github-review-bot]

@taraspos See the table below for backport results.

Branch	Result
branch/v14	Create PR
branch/v15	Create PR
branch/v16	Create PR
branch/v17	Create PR