Looking at it backwards - where is this heading? The official toolkit is falling behind, the action repos READMEs all state:

We continue to focus our resources on strategic areas that help our customers be successful while making developers' lives easier. While GitHub Actions remains a key part of this vision, we are allocating resources towards other areas of Actions and are not taking contributions to this repository at this time.

But what other areas?

Is this a subliminal message to let co-pilot put something together without worrying much about any of the architecture? From the design standpoint, GHA looks like on life support, but that's nowhere it should be from the product lifecycle aspect of things.

My OP on r/github:

TL;DR I suppose some of the below might (if you will) be assigned to a "learning curve issue", but all in all and given Microsoft's budget: Are GHA basically a "launch and forget" product? Is the official toolkit supposed to become "outsourced" to the Marketplace?

Is this meant to be production quality tooling? Because it feels a bit like an experiment that got abandoned.

I went to build a relatively simple pipeline with a couple of reusable workflows, bunch of composite actions and make use of GHCR where the images that are used to run the jobs reside - they are built from workflows too. There's been quite a few gotchas to me so far.

Workflows and composite actions discrepancies

• workflows can define top-level env, actions cannot
• workflows can (in fact, must) pass in secrets
• actions do not support secrets (and one better remembers to ::addmask:: on anything passed in)
• workflows must define types on inputs strictly (and it ends up being string all of the time)
• workflows must not define types on secrets
• actions must not define types on inputs

Reusable workflows do not get anything checked out with them, not even if called from separate repo, but composite actions do get everything checked out alongside in that case - in fact all the other actions from their repo get checked out.

There's no reasonable way to share inputs between workflow_call: and repository_dispatch:, i.e. one needs to make extra job to reconcile inputs in these two cases even it could be all structured the same in client_payload.

Composite actions have not been designed to be nested when sharing the same repo, i.e. calling one from within another requires one to fully specify the user/repo/action@ref even if it is meant to use the very same one, thus making it necessary to keep updating @ref for every push - or avoid using the construct altogether and resort to e.g. shared scripts.

Aside: Debugging

Talking of scripts, one cannot see outputs unless tee -a $GITHUB_OUTPUT >&2, which makes one want to use multi-line HEREDOC - not exactly robust approach. And that only works for steps, obviously.

Then having shell run by default with set -e with no indication on which line it exited is a bit of a nightmare. Either good for running single-liners, always setting own trap <echo> ERR or resorting to copious error output that kills readability of CI scripting, always.

I suppose the single-liners were expected because every Run folds into its first line which is best to be some # summary comment since description is not supported on steps. Alas, calling actions has to be with no comments.

The initial temptation to have anything multi-line inside scripts that are then single-liners however results in the realisation that - see above - workflows do not get them checked out.

About jobs

It is impossible to share matrix between jobs, as if the env is evaluated in the same pass - it cannot be used as a constant, so the workaround is to set repository variable and then strategy: matrix: field: ${{ fromJson(vars.CONST) }} in each job - or keep doing copy/paste.

Running jobs in containers does not allow for the very basics to be specified to be meaningful, i.o.w. one cannot really - within the YAML syntax - run the equivalent of e.g. podman run --rm --network=none <...> and select mounts only. In fact, one gets extra stuff (node et al) always mounted. Goodbye hermetic-anything.

Official Actions falling behind

Even though GHCR is a GH product, the accompanying GH actions are rusting, e.g. the actions/delete-package-versions has not been updated since January 2024 and is thus throwing EOL Node warnings.

Even the daily driver actions are somewhat falling behind, e.g. actions/download-artifact keeps throwing: [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. and it seems to be recurrent issue over a long period. I understand deprecation is not a failure, but - this used to be sign of unmaintained software.

And then others where the need naturally come from GHA runs, e.g. creating releases got completely abandoned and one has to resort to the Marketplace or run their own gh CLI.

CLI that is "too much work to keep parity"

At the same time, actions/upload-artifact do not even have a CLI equivalent because "it would be too much work replicating".