chore(ci): use ec2 for build-and-test-differential

[xmfcx]

Description

How it works

There are 5 consequent jobs:

• prevent-no-label-execution
• start-runner
• build-and-test-differential
• clang-tidy-differential
• stop-runner

The way it works is,

1. prevent-no-label-execution

This job checks if PR has prevent-no-label-execution tag. If yes, it can continue. If not, workflow stops.

2. start-runner

1. This job spawns a machine in EC2.
   • The machine has github-actions-runner in it.
2. This job then registers this runner to the autowarefoundation/autoware.universe/runners using my personal Github token (which is a secret).
   • This runner is assigned a special label.
     • Example runner labels: self-hosted, Linux, X64, o837y (last one being unique)
3. This action takes about 1m40s to complete. This delay comes mostly from EC2 instantiating the machine.

• I've set the machine to be a c6a.xlarge instance which is a good match for running generic build and test jobs. The machine has 4 vCPU, 8 GiB Memory, 50GB SSD storage. (Powered by 3rd generation AMD EPYC processors)
  • We can reduce it to a less powerful machine based on testing the performance and the cost.

3. build-and-test-differential

• This is 1st the 2 actual jobs we are attempting to run.
• It runs specifically on the runners with the unique label that was assigned in the previous job.
  • Example label: o837y

4. clang-tidy-differential

• This is 2nd the 2 actual jobs we are attempting to run.
• This is dependent on the success of the previous job (build-and-test-differential)
• It runs specifically on the runners with the unique label that was assigned in the previous job.
  • Example label: o837y

5. stop-runner

• Regardless of the success or failure of the previous jobs, this job terminates the instance that was created in the first run.
• The runner is also removed from autowarefoundation/autoware.universe/runners using the unique label that had been assigned.

Summary

• With this PR merged, there will be as many runners as we have these jobs.
  • People won't have to wait for a over-burdened runner to pick up their job.

Tests performed

Job is successful: https://github.com/autowarefoundation/autoware.universe/actions/runs/5716141354/job/15487030009?pr=4413

Effects on system behavior

Not applicable.

Pre-review checklist for the PR author

The PR author must check the checkboxes below when creating the PR.

• I've confirmed the contribution guidelines.
• The PR follows the pull request guidelines.

In-review checklist for the PR reviewers

The PR reviewers must check the checkboxes below before approval.

• The PR follows the pull request guidelines.

Post-review checklist for the PR author

The PR author must check the checkboxes below before merging.

• There are no open discussions or they are tracked via tickets.

After all checkboxes are checked, anyone who has write access can merge the PR.

[xmfcx]

I've added a detailed description to the first post.

[xmfcx]

After this is merged, I will probably remove this workflow from the sync-files job until we decide to increase its scope.
https://github.com/autowarefoundation/autoware.universe/blob/main/.github/sync-files.yaml#L46-L58

Related PR: #4372 (comment)

[shmpwk]

Fixed spell check failure in tier4/autoware-spell-check-dict#593.

[shmpwk]

LGTM!!!

[xmfcx]

https://github.com/autowarefoundation/autoware.universe/actions/runs/5716984310/job/15489764848?pr=4458

:( It cannot see the secret, now investigating it.

[xmfcx]

https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks#about-workflow-runs-from-public-forks

Workflows from forks do not have access to sensitive data such as secrets.

https://docs.github.com/en/actions/security-guides/encrypted-secrets#using-encrypted-secrets-in-a-workflow

With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository.

---

I think this whole plan won't work. I will revert this change and add the machine for perpetual running.

---

More info on why it was a bad idea: GitHub Actions requiring secrets on a fork-origin PR

[shmpwk]

@xmfcx How about using GitHub hosted larger runner? Maybe is it out of your budget?

• total (maximum) budged：$960/month
  • time：20min * 100 times /day -> 60000 min/month
  • larger runners fee：Linux, CPU 4, $0.016/min
  • 60000 * 0.016= 960

[mitsudome-r]

@shmpwk In order to use larger GitHub hosted runners, we have to register the organization as either GitHub Team plan or GitHub Enterprise plan as explained here. However, if we upgrade AutowareFoundation's plan, then we have to pay at least $3.67 per user/month. We currently have 173 members added to the organization so that would be extra cost of about $7,600 per year.

[xmfcx]

@shmpwk in addition to Github Team pricing, c6a.xlarge instance costs $0.153 per hour.

For a month,
$0.153 per hour * 24 hours/day * 30 days/month = $0.153 * 24 * 30 = $110.16
it costs this much.
If the budget was $960 per month, I would prefer having 8 of these self hosted machines.