you conveniently ignored the "CD" part of CI/CD

As mentioned by sibling comments, these two parts are very different. GHA and alternatives are primarily for CI; many people choose to use it solely for CI. For these reasons I did ignore CD.

Hmm, I have long assumed that a perfectly executed CI/CD setup would be based on a generic task runner... But maybe not?

Only the CI part needs to build; it needs little else and it's the only part of a coherent setup that needs to build.

We're iterating towards GHA for CI, AWS CodeBuild for the CD. At least on AWS projects. Mainly because managing IAM permissions to permit the github runner to do everything the deployment wants is an astonishingly large waste of time. But you need a secret to trigger one from the other.

You actually don’t need (long-lived / hard-coded) secrets in this scenario if you use OIDC:

https://docs.github.com/en/actions/how-tos/secure-your-work/...

Technically yes. It depends on whether you consider the account ID to be a secret or not (AWS say "sensitive but not secret" which doesn't help much). But also it can make sense to treat all environment variables as secrets by default just so you don't accidentally end up putting something somewhere that turns out to have been Wrong.

GP is saying that GHA would need zero information about AWS if CodeBuild used a Github token and listened for GHA runs.

That may be true, but it's not what the link describes.

Fair!

And even better can scope assuming an AWS IAM role to a specific branch name & workflow filename so only code/workflows that have been through review have access to CD secrets/prod infra.

IE no prod access by editing the workflow definition and pushing it to a branch.