release: automate regular SAR

[v1v]

What does this PR do?

• Enable the release automation to run the deployments to the regular SAR by using .internal/aws/scripts/dist.sh
• It uses the trusted OIDC to AWS.
• It uses aws-actions/setup-sam to install SAM cli in the worker.

Why is it important?

Remove the manual step to deploy in `elastic-observability-prod

Follow-ups

To support GovCloud - However, AFAIK we don't admin that AWS account and we are using OIDC/Keyless for simplicity.

Questions

• Configure the parameters for internal/aws/scripts/dist.sh
• Test - I plan to use the elastic-observability AWS account to validate if this works in my forked repository.

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in CHANGELOG.md

Author's Checklist

• [ ]

How to test this PR locally

Related issues

Part of #279

Use cases

Screenshots

Logs

[v1v]

avoid surprises and use the tag that has been created earlier

[v1v]

Run this job only if there is a new tag and in a separate job so we can see if things work as expected.

[constanca-m]

I agree with this.

We also only upload dependencies to the bucket when this workflow succeeds:

elastic-serverless-forwarder/.github/workflows/upload-dependencies.yml

Lines 11 to 15 in 70a2ca8

	on:
	workflow_run:
	workflows: [release]
	types:
	- completed

[v1v]

IIUC, there is a corner case in

elastic-serverless-forwarder/.github/workflows/upload-dependencies.yml

Line 32 in 70a2ca8

- uses: actions/checkout@v4

and it could use a wrong version if 2 or more commits happened in a row in share/version.py while upload-dependencies.yml has not been executed yet.

We can do a follow-up and see if that's a genuine reason

[constanca-m]

I agree with you. There is also another problem: if a commit happens and the tag is not updated (so no version upgrade). I don't see why a commit would not cause a version upgrade, but we do not check that.

[v1v]

Good catch!

[v1v]

It runs the same command in #279 (comment)

[zmoog]

@v1v, we tried to release 1.17.1, but the release workflow failed. Can you help me understand what's going wrong? 🙇

[v1v]

Notice: Latest version is 1.17.0.
Notice: Current version is 1.17.1.
/home/runner/work/_temp/cc8c3fc9-[91](https://github.com/elastic/elastic-serverless-forwarder/actions/runs/10997750457/job/30535666467#step:4:92)c5-4f06-b7c2-fa7795ebfb06.sh: line 32: unexpected EOF while looking for matching `"'

I think

elastic-serverless-forwarder/.github/workflows/release.yml

Line 70 in 29c08f4

echo "enabled=${CREATE_TAG}"" >> "$GITHUB_OUTPUT"

. there is an extra "

#805 should help

[zmoog]

Yeah! You've been faster than me! Closing https://github.com/elastic/elastic-serverless-forwarder/pull/806/files