GitHub Actions Feels Bad (Amos Wenger)
Substantive talk of GitHub Actions 2 starts at 8:33.
After being acquired by Microsoft, GitHub forked Azure Pipelines to make GitHub Actions into a full featured CI solution.
GitHub Actions Identity Crisis
GitHub Actions allows developers to use packaged library code (which they confusingly call “Actions”) in their workflows. This creates for GitHub Actions all of the problems that package managers, like npm or pip, need to solve, except that GitHub Actions does not solve these problems. For example, Actions are generally released by publishing a git tag on the release with the version number, but this is not secure because tags are mutable, and so a bad actor could one day update a tag to point to a compromised version of the same library. The only way to pin an Action to a particular version is to depend on a specific commit SHA. But what about transitive dependencies? In real package managers, we can usually ask the library to find the needed version of all direct and transitive dependencies, and then serialize the solution to a lock file. We then pin to the versions in the lock file. Here Amos says “GitHub Actions doesn’t want to be a package manager, so it does not install Actions dependencies. Instead, you have to paste together megabytes of JavaScript code from your node_modules directory using a tool like ncc and push the resulting crime against humanity to your Git repository.”. I don’t quite follow that. Does that mean Actions are not allowed to have dependencies? He seems to be saying you have to vendor a bunch of code, but I’m not sure what code or why.
The @actions/cache action has a dependency on tar. It can not install its own copy of tar, and so it instead detects which platform it is running on and constructs arguments that are tailored to that systems needs and capabilities. Amos seems to think this is outrageous, but it strikes me as reasonably pragmatic. Making a build system entirely hermetic is very hard. Even with tools like Bazel, which makes it theoretically possible to have an entirely hermetic build, most teams and up depending on some tools that are simply assumed to have been installed on the build machine (like tar). One alternative is to build every tool that you use in your build, as Bazel has historically done with protobuf, but this frustrates people because it is slow and it complicates the build. Another alternative is to package a binary of the tool in question for each platform on which you support building. This second technique seems to now be preferred in the Bazel world, but it also has some challenges.
Bazel has a similar problem when it comes to tools. Y
GitHub Docker Actions
GitHub’s solution to the above problems is to introduce Docker container actions, which, in Amos’s words, let you “ship containers instead of node.js codebases”.