[cjllanwarne]

Change Description

Resurrects the "tier 1" actions in #15276. Replacing all of CI with GHA is not trivial because of limits on free compute and concurrent job runs, but providing quick feedback to people without CI access via duplicative github checks is still extremely valuable.

We should watch:

• That we remain way below the free usage limits in github
• That the jobs run quickly

Security Assessment

• This change cannot impact the Hail Batch instance as deployed by Broad Institute in GCP

Github actions only

[ehigham]

What do you think about removin the corresponding checks in build.yaml?Is it worth running them twice?

[cjllanwarne]

@ehigham re "What do you think about removing the corresponding checks in build.yaml?Is it worth running them twice?". I tried this in my prior PR, but it turns out it's not trivial, eg:

• Do we want to remove all trace of them from build.yaml or just the CI test runs? Some are upstream of other test steps, or deploy steps.
• Some of these are extracted portions of longer steps (eg the batch unit tests are a portion of the larger batch build step, check-hail-fast is a faster subset of the build.yaml check-hail).
• Is it safe (I don't think they auto-rerun when the main branch changes). Maybe not a big deal?
• Are they used elsewhere? Is there a path that goes through build.yaml but not through github?

I guess I'd be happy to "just do it and reconsider if it becomes a problem" but OTOH, these are all short steps (even shorter in build.yaml where the pip install is shared), so "doing everything twice" is not as much overhead as it appears - at least for these "trivial setup" test cases.

So - to me the big win here is "getting information to contributors quickly" rather than "moving work out of CI", so I'd be inclined to leave it.

[ehigham]

Fwiw I'm not particularly fussed about the runtime overhead. I am more bothered about the checks being called in different yaml files and maintaining that. The wording on my comment was pretty vague.

I think it should be safe to purge from build.yaml as we test by rebasing and the deploy by rebase and squash. It's hard to think of a scenario where that would cause problems for the check-* checks. The tests you can probably keep. I'm also ok with deferring this to a later change to have a discussion with the rest of the team.

[ehigham]

as discussed in team meeting, keep logic in both build.yaml and this