Improve eamxx workflow files

[bartgol]

This PR does a few improvements to the eamxx workflow files:

• Make the workflow trigger when a review is added: this allows approved members to review the PR and trigger the actions to re-run
• Relegate some common steps to a composite action in the repo:
  • show-action-trigger: prints the workflow trigger info
  • check-skip-label: for pull_request and pull_request_review events, check if the PR labels contain any relevant skip label
• turn on nigthly testing for eamxx-scripts

Notice that the check on the labels for PR runs is now done at run time, while before it was a conditional at the job level. As a consequence, we no longer skip the job based on label (in the sense that the job did not run, so did not use runner resources). The reason for this is that while for pull_request events we can check the labels from the gh context (so we can do it at the job level), for pull_request_event the context does NOT contain the PR labels list, so we need to ping github for some info, and cannot do that inside the if conditional at the job level. The only downsides are

• we need to wait for the job to be picked up by a runner even if we want to skip it
• if the PR contains unauthorized users commits, the job will fail to start inside SNL runners, so the check will fail (despite the fact that we wanted to skip it)

Imho, the downsides are relatively mild, also considering that the check is done BEFORE cloning the repo, so it's quite early in the workflow. The last part of the sentence was wrong: we need to checkout the repo first, otherwise we cannot access our own action (which is defined in our repo).

[bartgol]

Fun fact: the dummy PR #3082 revealed, after some debugging, an important detail, which makes this PR actually necessary!

Apparently, the if condition at the job level (which is what we do right now, before this PR) must be evaluated when the worfklow is parsed, so it's a static condition. The PR labels are considered by gh as a dynamic information, coming from the event payload. Hence, we cannot check them at the job level. Incidentally, the check

github.event_name == 'workflow_dispatch' && github.event.inputs.jobs_list == 'gcc-openmp' 

is ok, despite having the "inputs.jobs_list" part, which seems a whole lot like an event payload. The point is that this particular payload is available to gh when the workflow is parsed, so we can check in an if condition at the job level.

You live you learn...

[bartgol]

The new checks that triggered with the review are rejected b/c Naser is not part of snl-testing. But the tests are the same of the ones triggered by pull_request event, so I'm going to ignore them and merge.

[mahf708]

The new checks that triggered with the review are rejected b/c Naser is not part of snl-testing. But the tests are the same of the ones triggered by pull_request event, so I'm going to ignore them and merge.

we can try to improve all of this later, but it is not urgent

[rljacob]

It should have run if you approved it, right? Has that been tested?

[mahf708]

I yeah, it ran and it failed when I approved it: https://github.com/E3SM-Project/scream/actions/runs/11618416678/job/32355783369. Recall I am not authorized.

[rljacob]

I mean if Luca, Jim or Tom approved it.

[mahf708]

Yeah, we can verify that on other PRs. The actions can be triggered manually too.

see here https://github.com/E3SM-Project/scream/actions/runs/11618827760 how it lists the details:

Triggered via pull request review 3 minutes ago
@[mahf708](https://github.com/mahf708)mahf708
submitted
⁠
[ 4cca117](https://github.com/E3SM-Project/scream/commit/4cca1171ac3bcd80aa4f6808930d7c445c344b80)
Status
Failure
Total duration
[1m 14s](https://github.com/E3SM-Project/scream/actions/runs/11618827760/usage)
Artifacts
–