I just want to be able to write all my workflow code as typescript (including the config - no YAML, for the love of god, no more YAML!) and run it locally with a debugger attached.<p>It's cost me hundreds to thousands of dollars to implement nontrivial workflows because of how the YAML is parsed (for example, empty strings when using a secret that has been renamed or removed) and the lack of introspection or debuggability when something goes wrong.<p>It's gotten to the point where new any new workflows I write are thin wrappers around a single script and I don't import any actions besides actions/checkout (even that has been bug prone, historically).<p>All that said, it's not like other platforms are better. But they certainly are cheaper and don't have dumb breakages when you need cross platform builds (has upload-artifact been fixed for executables on MacOS yet?)
One of the things I like about Actions is how much it's focused on automation rather than CI. The pain points I've had with Circle/GitLab/Travis have often boiled down to the fact that they are often very specifically about _testing software_, not _automating processes_, and not even _deploying software_.<p>On that last one, there's a potential bug in the deployment pipeline here – deploys could run simultaneously or some bad luck on runner speed could even see an older version of the code go out after a newer version. Combined with the automated database migrations this could be quite a big problem!<p>Actions thankfully solved this recently with the `concurrency` key that lets you form a serial queue by a given key such as the branch name.
I love GH actions, but they're still a bit too sharp-edged for my taste.<p>Like...the last time I checked, workflows had no runtime macro for limiting execution to the default branch except explicitly by a specific name, and the closest you could get to generically checking "whatever the default branch is called right now" was either a template workflow that would set some static text for the name at creation that breaks if the default branch name is subsequently changed or a song and dance querying the API and setting an environment variable inside one of the workflow steps and then gating all subsequent steps on the result. This was a long time after they introduced editable default branch names and seems like such an obvious oversight.<p>Then there are weird quirks like the subshell file system permissions block that requires using sudo if you want to move files around within your repo clone from inside an invoked shell script.
At my company, the biggest pain points we've run into with GitHub Actions are all centered around the many lacking aspects of permission handling.<p>- You can't pull in private dependencies published from other repos (for example, packages published on repo A used as a dependency on repo B) without using a private access token.<p>- You can't use git pulls from other repos (for example, repo B using `orgname/repoA#123456` as a dependency in package.json) without using a private access token, and it's a pain in the ass to make it work across workflow steps.<p>- You can't allow Dependabot to run as a trusted user, which makes it impossible to actually use any of the workarounds for the above issues with it.<p>- You can't create PRs to publish changes across repos (such as automatically keeping some set of files in sync) without using a private access token.<p>There are other complications, but those are the biggest ones.
Can anyone point me to an example of a Github action resulting in standing up a fully working backend with a resolvable DNS entry for manual pull request testing?
As long as automation solutions (such as all ci-tooling) uses yaml to define logic instead of a proper programming language (or at least configuration language like dhall), I will try to stay away from them as much as possible.
I'm always hesitant to lock into solutions like these because they may not always be offered on the same terms.<p>For example, recently when they had to reduce access to GitHub Actions because miners were abusing it.<p>Where as my local configuration management (Ansible, Puppet etc.) script can always run anywhere and I can even run on my own build VM if I need too.
I noticed their hadolint action and couldn't help but think it falls a bit short in terms of flexibility and output. I wrote an action to improve these type of use cases that can be found here: <a href="https://github.com/jbergstroem/hadolint-gh-action" rel="nofollow">https://github.com/jbergstroem/hadolint-gh-action</a>
LOL a software company is more, so much more, than CI. I thought I was going to read something novel about using GitHub actions for tracking sales leads or customer success or something.