July 2025 Summaries

GitHub Actions is praised for improving CI/CD developer experience, but criticized for its approximately 47 GiB base image, which includes numerous language runtimes, SDKs, package managers, build tools, cloud CLIs, and browsers despite many users installing pinned dependencies themselves. The author argues that such expansive platform-specific images can reduce performance, introduce breaking changes when maintained software is updated, and make pipeline scripts difficult to port to other environments. RWX is presented as an alternative that uses a generic Ubuntu base image with only essential tools and Docker components installed through a transparent Dockerfile, aiming to improve portability, debugging, reuse, and control over dependencies.

Docker’s BuildKit improved on the original Docker builder but is argued to retain inefficiencies and complex configuration requirements, particularly around uploading entire repositories as build contexts, manually ordering COPY and RUN commands for caching, and managing multi-stage builds. The proposal advocates cloning repositories directly inside builders, eliminating Dockerfile COPY statements, making all repository files initially available while limiting each command’s cache key and sandbox to its declared inputs, and enabling cache misses to be followed by later cache hits. It also recommends merging independent multi-stage build outputs, using an entire container registry rather than selected images as a shared cache source, avoiding default layer compression in cloud environments where network transfers can be faster, and supporting multiline RUN scripts. A prototype built on the RWX runtime is said to demonstrate faster builds and a simpler developer experience, with early access available through its creator.

RWX presents its CI/CD platform as using automatic caching combined with sandboxed task execution to reduce cache misconfiguration and false cache hits. Unlike platforms such as GitHub Actions, where engineers typically define cache keys manually with tools like `hashFiles` while unrelated project files remain accessible during execution, RWX filters both determine cache inputs and restrict the files available to a task. The text argues that manually configured caches can overlook external dependencies, potentially causing builds to fail for other engineers or allowing untested defects into production. It describes sandboxing as a method of limiting a program’s access to files and resources, and states that applying it to task execution enables RWX to make cache results more reliable.

RWX is presented as offering a more flexible failure-retry experience than GitHub Actions by allowing failed tasks to be retried immediately while unrelated tasks continue running. Its execution model treats individual steps as separate tasks, so a failed step can be retried without repeating earlier successful steps, whereas GitHub Actions typically requires rerunning the full job. The comparison notes that GitHub Actions may require users to cancel an active workflow before its rerun option becomes available, forcing a choice between stopping other jobs or waiting for them to complete. Example workflows illustrate a GitHub Actions job that fails alongside a successful sleeping job and an RWX configuration that intentionally fails on its first attempt before succeeding on retry through an attempt-number environment variable.

RWX now supports native Arm64 execution, enabling Arm container builds without QEMU emulation and reducing the RWX Arm64 image build time from 14 minutes and 8 seconds on x86_64 to 1 minute and 38 seconds on Arm hardware. Users can configure Arm64 builds by setting `arch: arm64` in the base section of `.rwx/ci.yml`. The initial Arm64 images were bootstrapped through x86_64 emulation, but native support allows the project to remove the multi-architecture Docker Buildx setup and use standard Docker builds on the selected architecture.

RWX has introduced an API endpoint for setting vault secrets programmatically, supporting automated workflows such as credential rotation. While OpenID Connect is recommended where supported because it verifies requests originate from RWX runs and issues short-lived credentials, vault secrets remain necessary for services that require stored credentials. Secrets can be set manually through the UI or CLI, or automated through the CLI for shell-based scripts and the API for code-based integrations, with API requests authenticated using an RWX access token. Stored secrets can be referenced in run configurations through expressions, preferably assigned to environment variables to avoid character-escaping issues, and their values are automatically masked in logs.

RWX has introduced manually initiated CI runs, allowing engineering teams with large, resource-intensive test suites to make CI opt-in and control when pipeline costs are incurred. Previously, teams could avoid CI by adding `[skip ci]` or `[skip rwx]` to commit messages or by configuring workflows to ignore draft pull requests, but these methods rely on developers remembering conventions and can improperly tie CI decisions to review status. By adding `start: manually` to the GitHub pull request trigger in `.rwx/pull-request.yml`, teams can separate the decision to run CI from the decision to mark a pull request ready for review.

RWX now supports selecting the operating system for runs while preserving concise configuration files and protecting backward compatibility. Rather than requiring users to manually add an OS declaration to every run definition or automatically using the latest OS version, which could cause existing runs to fail after updates, the CLI injects an explicit base OS configuration when a run is started. This approach allows engineers to test and launch runs with minimal boilerplate while ensuring each definition is pinned to a specific operating system version, such as Ubuntu 24.04 with a designated tag.

RWX has released a package for automating GitHub pull request creation, demonstrated through a workflow that runs npm updates and opens a PR containing update and outdated-package output. The author emphasizes fast implementation through RWX’s local CLI and automatic caching, which can reuse completed tasks such as a two-minute npm update when later workflow steps need correction. Because the default RWX GitHub App lacks PR permissions, users must create a private GitHub App for their bot, then clone a repository with its Git directory preserved, make changes, and invoke the create-pull-request package. The package can support many automated change workflows, while npm updates are presented as a use case where native package manager commands may handle transitive dependencies and version configuration more consistently than tools such as Dependabot or Mend Renovate.

RWX has introduced a web-based file tree navigator that lets users inspect files produced by a task, helping them configure output filters, although file contents are not yet displayed. Because RWX tasks use content-based caching based on manifests representing the full filesystem in a proprietary binary format, the company reused its performance-focused Go manifest-parsing code for the browser interface. By compiling the Go code to WebAssembly, RWX can send task manifests to the client, parse them locally, and provide fast file tree navigation while avoiding the need to reimplement the parsing logic in JavaScript.

RWX added support for downloading logs from an entire group of tasks, including embedded runs, parallel tasks, and package calls. Because groups may contain hundreds of tasks and several megabytes of logs per task, a conventional approach would prepare the archive asynchronously in the background and notify users when it was ready. Instead, to preserve the platform’s emphasis on performance, RWX streams log files directly into an archive while transferring it to the user, allowing downloads to begin immediately without waiting for the complete archive to be generated.

Because Node.js patch and minor releases can introduce compatibility issues such as changed function signatures or character-encoding behavior, the authors aligned their language server and VS Code extension testing with the exact Node version used by VS Code. They identified VS Code’s `.nvmrc` file as the primary source for that version and chose to support the Node release used by the latest VS Code release rather than test older versions. To keep the project synchronized as VS Code updates, they created a scheduled RWX cron workflow that retrieves VS Code’s latest release tag, fetches its `.nvmrc`, clones the language server repository, detects the repository’s configured Node version using `rwx/tool-versions`, and fails when the two versions differ. Cron failures are sent to Slack, providing a prompt to update the project’s Node version when VS Code changes its runtime.

Automated dependency updates through tools such as Dependabot, Renovate, or RWX can help teams adopt security and bug fixes quickly while revealing upgrade problems early. An upgrade from Node.js 22.6.0 to 22.7.0 caused character-encoding anomalies in logs because that minor release contained known buffer-related issues, illustrating that runtime minor and even patch versions can introduce regressions. To reduce inconsistency across development, testing, and production environments, teams should pin exact runtime versions rather than broad ranges such as “22.x” and test using the same version intended for production. A `.tool-versions` file, supported by version managers including asdf and mise, can define a fixed Node.js version and be incorporated into RWX workflows through the `rwx/tool-versions` package.

RWX has released a Visual Studio Code extension designed to bring CI/CD pipeline feedback directly into the editor through features such as autocompletion and inline documentation. The extension builds on RWX’s local development workflow, which allows engineers to initiate workflows from a local CLI, use breakpoints with a remote debugger, and rely on intelligent caching to avoid re-running unchanged upstream pipeline steps when testing downstream changes. Its underlying language server was created from RWX’s existing custom YAML parser, which already supported stack frames and detailed error messages. The company states that Claude AI implemented most of the extension, viewing the project as a suitable application of AI for building a familiar tool from an established specification.

A Node.js maintainer’s loss of a signing key disrupted the standard OpenPGP method for retrieving a public key needed to verify Node.js releases, causing some external build processes, including Cypress Docker image builds, to fail. The incident was not caused directly by the lost private key but by publication of a replacement key that disassociated the old key from the maintainer’s identity on OpenPGP, leaving GPG unable to retrieve a usable user ID for the former key. Signing keys protect software distribution by allowing users to verify that downloaded binaries were produced by authorized maintainers, an especially important safeguard for the widely deployed Node.js runtime. RWX users were unaffected because its Node.js installation package verifies signatures and caches completed installations, so builds using an unchanged Node.js version continued to use cached artifacts rather than relying on the unavailable external key source.

RWX has introduced cache-race prevention to improve its automatic CI/CD caching, particularly for teams running large monorepos where identical tasks may execute concurrently. Previously, two tasks sharing a cache key could both miss the cache, run the same commands, and independently write duplicate results, consuming unnecessary compute. Under the new behavior, when a second task detects that another in-progress task has the same cache key, it waits for the first task to finish and then uses its cached result. RWX says this change reduces redundant work, increases cache hits, and improves build reliability, while displaying a UI message to explain when a task is waiting for an equivalent task to complete.

RWX is consolidating its CI/CD platform branding by retiring the Mint name and presenting its functionality directly under RWX, following the product’s strongest impact on engineering teams over the past year. ABQ and Captain will remain supported and actively developed, with plans to improve Captain’s experience within RWX while retaining compatibility with other CI/CD platforms. To minimize disruption, RWX provides backward compatibility and a migration guide for Mint-to-RWX changes, including renaming “leaves” as “packages” and moving language runtime packages from the mint namespace to language-specific owners, such as changing mint/install-node to nodejs/install. The rwx CLI can automatically apply these package renames through the rwx packages update command.