# GitHub Actions GitHub's platform for automating software development workflows, including CI/CD, in repositories. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## GitHub Actions: правила запуска стали общедоступными, для pull\_request\_target вводят ограничения DevFeed: [GitHub Actions: правила запуска стали общедоступными, для pull\_request\_target вводят ограничения]() Original publisher: [Read original article]() Author: MaxRokatansky (OTUS) Published: 2026-09-18T07:27:15Z Content type: news Language: ru Sources: [Tagir Valeev]() Topics: [GitHub Actions](), [GitHub](), [API](), [ci]() Tags: [api](), [ci](), [cicd-2622a5c70597](), [github](), [github-actions](), [rest-api](), [tag-070ecaaf0eda](), [tag-431721c35e50](), [tag-7d2878fc3cc1](), [tag-9e079357c819](), [workflow]() ### AI overview GitHub has made workflow execution protections for GitHub Actions generally available. The rules control who can trigger workflows and under which events, support file-specific policies, provide evaluation results in Insights, and can be managed through the REST API. GitHub is also introducing default restrictions for pull_request_target in affected public repositories. ### Source excerpt GitHub вывел в общий доступ защиту запуска рабочих процессов Actions: правила позволяют контролировать, кто и при каких событиях может запускать пайплайны. Отдельное изменение касается pull_request_target, который в публичных репозиториях начнут блокировать по умолчанию. Разобраться в изменениях ## Fresh Package: Laravel Package Skeleton with Testbench, CI, and Boost Integration DevFeed: [Fresh Package: Laravel Package Skeleton with Testbench, CI, and Boost Integration]() Original publisher: [Read original article]() Author: Paul Redmond Published: 2026-09-18T03:20:58Z Content type: tutorial Language: en Sources: [Laravel]() Topics: [Laravel](), [ci](), [GitHub Actions](), [PHPUnit](), [PHP](), [TypeScript](), [Vue.js](), [Tailwind CSS](), [Vite](), [ESLint]() Tags: [ci](), [frontend](), [github-actions](), [laravel](), [laravel-packages](), [php](), [phpunit](), [security](), [vue]() ### AI overview Fresh is a Laravel package skeleton that scaffolds backend-only or full-stack packages with testing, static analysis, CI, a Testbench workbench app, release automation, frontend tooling, repository settings, and optional AI skills. ### Source excerpt Fresh Package scaffolds a Laravel package with PHPUnit, Larastan, a Testbench workbench app, GitHub Actions, and an optional Vue frontend or AI skills. The post Fresh Package: Laravel Package Skeleton with Testbench, CI, and Boost Integration appeared first on Laravel News. Join the Laravel Newsletter to get Laravel articles like this directly in your inbox. ## Publishing a Kubernetes SIG's Images to registry.k8s.io DevFeed: [Publishing a Kubernetes SIG's Images to registry.k8s.io]() Original publisher: [Read original article]() Author: The Kubernetes Authors Published: 2026-09-16T18:00:00Z Content type: tutorial Language: en Sources: [Kubernetes Contributors Blog]() Topics: [Kubernetes](), [container images](), [GitHub Actions](), [CI/CD](), [Google Cloud Platform (GCP)]() Tags: [ci-cd](), [container-image](), [container-image-registry](), [container-images](), [documentation](), [github-actions](), [google-cloud](), [guide](), [kubernetes]() ### AI overview A guide to publishing official Kubernetes SIG container images through registry.k8s.io. It explains why GHCR is unsuitable for public distribution and describes the ordered workflow involving Prow, Google Cloud Build, staging registries, and image promotion. ### Source excerpt If you're publishing container images for a Kubernetes SIG project, you might expect the same publishing workflow used by other container registries to work. That was my assumption too. My workflow successfully published the images, but they weren't publicly available. Instead, official Kubernetes project images are distributed through registry.k8s.io , the Kubernetes project's official container image registry. No single step was hard, but the steps were spread across multiple repositories and had to happen in a particular order, something I mostly learned by tripping over them. This post is the guide I wish I had at the start. It walks through that workflow end to end using Cluster Inventory API from SIG Multicluster as an example. The same process applies to eligible Kubernetes subprojects that publish official container images. My first attempt: GHCR I first tried a common GitHub release pattern: using GitHub Actions to publish images to ghcr.io on a tag push (cluster-inventory-api#40 ). The workflow succeeded, but Kubernetes GitHub organizations keep GHCR packages private, so GHCR cannot be used for public distribution. As described in the registry.k8s.io documentation , official images take a different route: Prow (the Kubernetes project's CI/CD system) picks up a tag push and runs Google Cloud Build on Kubernetes-owned infrastructure to push the image to a staging registry, and the image promoter then copies it to registry.k8s.io. The first-time setup, step by step Besides the image-owning repository, this touches three infrastructure repositories: kubernetes/k8s.io , kubernetes/test-infra , and kubernetes/org . The pieces depend on each other like this: Before you start: decide your project details Before setting up the publishing workflow, decide a few project-specific details. These values will be reused throughout the setup when creating the staging registry, configuring image builds, and setting up image promotion: , which determines the staging ## Learn How to Deploy, Secure, and Automate Full-Stack Web Apps DevFeed: [Learn How to Deploy, Secure, and Automate Full-Stack Web Apps]() Original publisher: [Read original article]() Author: Beau Carnes Published: 2026-09-16T15:28:18Z Content type: tutorial Language: en Sources: [freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More]() Topics: [web applications](), [Deployment](), [CI/CD](), [FastAPI](), [GitHub Actions](), [Vue.js](), [nginx](), [firewalls](), [Python](), [Cloudflare](), [SSL](), [Ubuntu]() Tags: [analysis](), [authentication](), [ci-cd](), [deploy](), [fastapi](), [full-stack](), [github-actions](), [how-to](), [web](), [web-apps](), [youtube]() ### AI overview This article introduces an 11-hour freeCodeCamp course on deploying, securing, and automating a Vue.js and FastAPI web application. It covers Ubuntu server setup, SSH hardening, firewalls, application runtimes, Meilisearch, DNS, SSL, Nginx, Cloudflare, GitHub Actions, security testing, and observability. ### Source excerpt Taking a web application from local development to a live, secure production environment can be daunting if you've never looked under the hood. We just published a comprehensive course on the freeCode ## Test GitHub Actions Locally with Act DevFeed: [Test GitHub Actions Locally with Act]() Original publisher: [Read original article]() Author: Valerie Nielson Published: 2026-09-16T12:00:44Z Content type: tutorial Language: en Sources: [Atomic Object]() Topics: [GitHub Actions](), [CI/CD](), [Docker](), [Testing](), [unit test]() Tags: [ci-cd](), [developer-tools](), [docker](), [github](), [github-actions](), [pull-request](), [testing](), [unit-test](), [workflow]() ### AI overview This tutorial explains how to test GitHub Actions workflows locally with act. It describes how act uses Docker to reproduce the workflow environment, including environment variables and the file system, and demonstrates testing pull-request workflows and unit tests before merging. ### Source excerpt GitHub Actions are a great way to implement CI/CD into your projects, whether personal or professional. GitHub has a lot of great tools to help with CI/CD, but GitHub Actions in particular is very helpful. However, writing actions can be tedious and a little annoying, especially if you don't know what you're doing. On top [...] The post Test GitHub Actions Locally with Act appeared first on Atomic Spin. ## Any Nix package, live in your browser DevFeed: [Any Nix package, live in your browser]() Original publisher: [Read original article]() Author: Simon Willison Published: 2026-09-10T23:44:15Z Content type: article Language: en Sources: [Simon Willison's Weblog]() Topics: [Nix](), [WebAssembly](), [qemu](), [x86](), [GitHub Actions](), [Pull Request]() Tags: [browser](), [code-review](), [code-review-16](), [github-actions](), [github-actions-72](), [linux](), [linux-54](), [qemu](), [webassembly](), [webassembly-131](), [x86]() ### AI overview The article describes trynix.dev, which runs an x86_64 Linux virtual machine in the browser using qemu-wasm and WebAssembly. It can boot Nix packages from the past 13 years, including Python 3.6.2, and supports URL-addressable interactive shells. It also highlights trynix-preview, a GitHub Action that links pull requests to browser-based builds without servers. ### Source excerpt Any Nix package, live in your browser Farid Zakaria calls this his "magnum opus of Nix work", and I can see why. trynix.dev provides a qemu-wasm powered x86_64 Linux virtual machine running entirely in your browser through WebAssembly. That VM can then be booted with any Nix package from the past 13 years. They are URL addressable, so you can navigate to this page: https://trynix.dev/?pkg=python3%403.6.2 Then click "Load" and get an interactive shell against a virtual machine running Python 3.6.2 from 2017. Farid is building all sorts of neat things on top of this. One recent example: Review a pull request by booting it introduces trynix-preview, described like this: GitHub action that comments a link on a pull request which lets you boot the PR's build in the browser using https://trynix.dev. No servers, just browsers. Via Lobste.rs Tags: code-review, linux, webassembly, github-actions ## GitHub availability report: August 2026 DevFeed: [GitHub availability report: August 2026]() Original publisher: [Read original article]() Author: Jakub Oleksy Published: 2026-09-10T02:05:17Z Content type: article Language: en Sources: [GitHub Engineering]() Topics: [GitHub](), [site-reliability-engineering](), [migration](), [MySQL](), [GitHub Actions]() Tags: [availability](), [azure](), [company-news](), [database](), [github](), [github-actions](), [github-availability-report](), [migration](), [monitoring](), [mysql](), [news-insights](), [outage](), [performance](), [production]() ### AI overview GitHub reports five August incidents with degraded service performance and describes capacity, resiliency, database, Azure migration, and GitHub Actions improvements. ### Source excerpt In August, we experienced five incidents that resulted in degraded performance across GitHub services. The post GitHub availability report: August 2026 appeared first on The GitHub Blog. ## Automated Worker Versioning with GitHub Actions DevFeed: [Automated Worker Versioning with GitHub Actions]() Original publisher: [Read original article]() Author: Adam Quan Published: 2026-09-09T00:00:00Z Content type: tutorial Language: en Sources: [Temporal Blog]() Topics: [GitHub Actions](), [CI/CD](), [Deployment](), [Orchestration]() Tags: [automation](), [ci-cd](), [ci-cd-pipeline](), [deployment](), [github-actions](), [how-to](), [temporal-voices]() ### AI overview This tutorial explains how to automate Temporal Worker Versioning in a CI/CD pipeline with GitHub Actions and Worker Controller. It covers deterministic Workflow code changes, deployment versions, traffic ramping, pinned and auto-upgrade Workflows, safer rollouts, and rollbacks. ### Source excerpt Learn how to automate Temporal Worker Versioning in CI/CD with GitHub Actions and Worker Controller for safer rollouts, traffic ramping, and rollbacks. ## Workload identity trust policies govern CI/CD access to production cloud resources DevFeed: [Workload identity trust policies govern CI/CD access to production cloud resources]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-09-02T00:00:00Z Content type: article Language: en Sources: [WorkOS Blog]() Topics: [OpenID connect (OIDC)](), [CI/CD](), [GitHub Actions](), [GitHub](), [Cloud](), [Amazon Web Services]() Tags: [aws](), [ci-cd](), [github](), [identity](), [oidc](), [policy](), [production](), [secrets](), [trust]() ### AI overview This article explains that workload identities used by service principals and CI/CD federation can evade human-focused access reviews. It argues that OIDC trust policies are the key boundary controlling which federated jobs can obtain short-lived cloud access tokens and reach production resources. ### Source excerpt Service principals and CI/CD federation skip the access reviews that catch humans. The OIDC trust policy string is what actually decides who reaches production. ## MUST READ: Git - Going Pro DevFeed: [MUST READ: Git - Going Pro]() Original publisher: [Read original article]() Published: 2026-09-01T05:31:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [Git](), [GitHub](), [GitHub Actions](), [ssh](), [Pull Request](), [Command-line interface]() Tags: [article](), [blog](), [cli](), [git](), [github](), [github-actions](), [reviews](), [ssh](), [worth-reading]() ### AI overview A recommendation for Tony Mattke's "Going Pro" article, which covers Git fundamentals and professional practices including SSH keys, pre-commit hooks, GitHub Actions, linting, branch protection, pull-request reviews, and the gh CLI. ### Source excerpt I sure wish Tony Mattke had started publishing his Git-related blog posts in 2017 when I was still struggling with the basics. In his latest Going Pro article he covers: Using SSH keys with Git and GitHub Pre-commit hooks GitHub Actions and linting GitHub Branch protection PR reviews gh CLI Absolutely worth every second you'll spend reading the article! ## Connecting the Dots: Securing the Overlooked Corners of the Software Development Lifecycle (SDLC) Supply Chain DevFeed: [Connecting the Dots: Securing the Overlooked Corners of the Software Development Lifecycle (SDLC) Supply Chain]() Original publisher: [Read original article]() Author: Yaron Avital Published: 2026-08-21T23:00:21Z Content type: article Language: en Sources: [Unit 42]() Topics: [sdlc](), [Security](), [Application Security](), [CI/CD](), [GitHub Actions](), [npm](), [Bun](), [Python](), [Claude Code](), [vs-code](), [Claude](), [Ethereum]() Tags: [blockchain](), [c2](), [chaindrop](), [ci-cd](), [claude-code](), [general](), [github-actions](), [insights](), [malware](), [npm-packages](), [persistence](), [python](), [sdlc](), [security](), [software-supply-chain-attack](), [supply-chain](), [vs-code]() ### AI overview Unit 42 describes how software supply-chain attackers are targeting developer tools, CI/CD pipelines, accounts, packages, setup scripts and developer environments before software reaches production. It examines the ChainDrop npm worm, which used malicious preinstall hooks, a Bun runtime, an obfuscated payload, Python-based memory theft, stolen tokens and secrets, self-propagation, persistence in VS Code and Claude Code, and Ethereum-managed command-and-control infrastructure. ### Source excerpt Attackers are targeting CI/CD pipelines and developer tools instead of application code, requiring total SDLC visibility and strict security controls The post Connecting the Dots: Securing the Overlooked Corners of the Software Development Lifecycle (SDLC) Supply Chain appeared first on Unit 42. ## Stop burning tokens on code review DevFeed: [Stop burning tokens on code review]() Original publisher: [Read original article]() Author: hi@swizec.com (Swizec Teller) Published: 2026-08-15T00:00:00Z Content type: opinion Language: en Sources: [Swizec Teller]() Topics: [Code review](), [Claude Code](), [Code](), [GitHub Actions](), [Architecture & Design](), [cursor]() Tags: [agents](), [claude-code](), [code](), [code-review](), [cursor](), [engineering](), [github-actions](), [security]() ### AI overview The author argues that custom linters can provide fast, inexpensive guardrails and feedback loops for both human and agent-written code. They describe mixed experiences with Cursor's BugBot and Claude code review skills, especially the high noise and review burden produced when those skills run in GitHub Actions. ### Source excerpt I've been experimenting with different approaches to build a system where humans and agents can ship fast safely. Think I've found something that works - custom linters. ## Generating AI Descriptions of Automated Pull Requests DevFeed: [Generating AI Descriptions of Automated Pull Requests]() Original publisher: [Read original article]() Author: Daniel Doubrovkine (dblock@dblock.org) Published: 2026-08-11T00:00:00Z Content type: tutorial Language: en Sources: [Daniel Doubrovkine]() Topics: [GitHub Copilot CLI](), [GitHub Actions](), [GitHub Copilot](), [Large Language Model](), [Ruby](), [Slack](), [changelog](), [Pull Request](), [Open Source](), [JSON](), [YAML]() Tags: [ai](), [automated](), [changelog](), [ci](), [cli](), [copilot](), [github](), [github-actions](), [github-copilot](), [github-copilot-cli](), [json](), [llm](), [open-source](), [pull-request](), [pull-requests](), [ruby](), [yaml]() ### AI overview A tutorial explains how the maintainer of the slack-ruby-client library uses a scheduled GitHub Actions workflow and GitHub Copilot CLI to generate meaningful commit messages, pull request bodies, and CHANGELOG entries from diffs of regenerated Slack API code. It also covers YAML indentation, prompt files, response logging, and extracting a JSON result from Copilot CLI output. ### Source excerpt The slack-ruby-client library, an open source Ruby gem I maintain, runs a scheduled GitHub Actions workflow that regenerates code from Slack's API definitions and opens a pull request with the diff. The commit message and CHANGELOG entry used to be a generic "Update API (2026-08-11)", which told a reviewer nothing about what actually changed. Here's how we taught the workflow to describe its own diffs, using GitHub Copilot CLI, which open source maintainers can get for free. The Idea The workflow already computes a diff before opening the pull request. Instead of a boilerplate commit message, we pipe that diff through an LLM and ask it to summarize what changed, then use the response as the commit message and PR body. - name: Check for changes id: changes run: | if git diff --quiet; then echo "changed=false" >> "$GITHUB_OUTPUT" else echo "changed=true" >> "$GITHUB_OUTPUT" fi - name: Prepare diff for AI summary if: steps.changes.outputs.changed == 'true' run: | git diff --stat | sed 's/^/ /' > /tmp/diff_stat.txt git diff | head -c 20000 | sed 's/^/ /' > /tmp/diff.txt The sed 's/^/ /' indent isn't decorative. actions/ai-inference substitutes template variables as raw text into a prompt YAML file before parsing it, so a multi-line diff starting at column 0 breaks the indentation of the enclosing content: |- block scalar. Pre-indenting the file to match keeps the YAML valid no matter what the diff looks like. The Prompt File actions/ai-inference supports .prompt.yml files, a small convention for keeping the system/user prompt out of the workflow YAML. messages: - role: system content: |- You write CHANGELOG entries describing an automated API update to slack-ruby-client, a Ruby gem whose Web API endpoint methods, argument validations, specs, and bin commands are code-generated from vendored Slack API method definitions (via a git submodule and rake task). Given a diffstat and a diff of the regenerated files, respond with ONLY a single JSON object (no markdown code fence ## ChainDrop npm Worm: Why SLSA Provenance Wasn't Enough DevFeed: [ChainDrop npm Worm: Why SLSA Provenance Wasn't Enough]() Original publisher: [Read original article]() Author: Harness Team Published: 2026-08-10T00:00:00Z Content type: article Language: en Sources: [Harness Blog]() Topics: [ChainDrop](), [npm](), [supply-chain-security](), [Malware](), [npm packages](), [GitHub Actions](), [GitHub]() Tags: [chaindrop](), [ci](), [ci-cd](), [github](), [github-actions](), [integrity](), [least-privilege](), [malware](), [npm](), [npm-worm](), [openid-connect](), [provenance](), [security](), [slsa](), [software-supply-chain-security](), [worm]() ### AI overview The ChainDrop npm worm compromised hundreds of packages while retaining valid SLSA provenance, demonstrating that build attestations do not guarantee source integrity. The article explains the worm's propagation, credential theft, persistence mechanisms, and recommended defenses, including source governance, dependency controls, least-privilege identities, policy gates, and runtime evidence. ### Source excerpt ChainDrop poisoned hundreds of npm packages while retaining valid provenance. Learn why signed builds need source governance, policy gates, and runtime evidence | Blog ## ChainDrop: Inside a Self-Propagating npm Worm DevFeed: [ChainDrop: Inside a Self-Propagating npm Worm]() Original publisher: [Read original article]() Author: Unit 42 Published: 2026-08-06T22:26:39Z Content type: article Language: en Sources: [Unit 42]() Topics: [ChainDrop](), [npm](), [Malware](), [C2](), [Ethereum](), [GitHub Actions](), [GitHub](), [CI/CD](), [Security]() Tags: [blockchain](), [c2](), [chaindrop](), [ci](), [claude-code](), [developer-tooling](), [ethereum](), [github](), [github-actions](), [high-profile-threats](), [infrastructure](), [malware](), [security](), [ssh](), [supply-chain](), [tokens]() ### AI overview This article analyzes ChainDrop, a self-propagating npm worm that infected more than 400 packages and threatened developer workstations, CI pipelines, cloud environments and downstream users. It describes credential and token theft, GitHub Actions runner memory extraction, package republishing, persistence through developer and AI coding tools, blockchain-based C2 resolution, and C2 reconfiguration through an Ethereum transaction. ### Source excerpt Analysis of ChainDrop, an npm supply chain worm extracting GitHub Actions runner secrets and using Ethereum smart contracts for C2 routing. The post ChainDrop: Inside a Self-Propagating npm Worm appeared first on Unit 42. ## CI Doesn't Need On-Demand: Moving Our Build Pipelines to Spot Instances DevFeed: [CI Doesn't Need On-Demand: Moving Our Build Pipelines to Spot Instances]() Original publisher: [Read original article]() Author: Yuvraj Singh Singhel Published: 2026-08-05T15:07:35Z Content type: article Language: en Sources: [Razorpay Engineering - Medium]() Topics: [CI/CD](), [GitHub Actions](), [Kubernetes](), [Amazon Web Services]() Tags: [aws](), [ci](), [ci-cd](), [github-actions](), [kubernetes](), [pipelines](), [self-healing]() ### AI overview Razorpay describes a self-healing infrastructure layer for GitHub Actions on Kubernetes that runs most CI workloads on AWS Spot Instances. The system detects spot-node termination, retries jobs, and cleans up orphaned pods; the article states that 80% of CI workloads run on spot instances with a 99.2% job success rate. ### Source excerpt Contributors: Guptaanuj CI/CD pipelines have always had a money-vs-stability problem. Run on-demand AWS instances and your build infrastructure is rock solid, expensive, and predictable. Run on spot instances and your costs drop 70-90%, but AWS can pull the rug with 2 minutes of warning. For most teams, this is a false choice. Either pay full price for reliability, or save money and accept that builds will fail in ways nobody can debug. At Razorpay, we stopped accepting that trade-off. We built a self-healing infrastructure layer for GitHub Actions on Kubernetes that runs 80% of our CI workloads on spot instances while maintaining a 99.2% job success rate. When AWS terminates a spot node mid-build, our system detects it, retries the job, cleans up the orphaned pods, and the developer never knows. This is the story of what we built, why polling wasn't an option, and the war stories that taught us how to do retries without burning everything down. The Problem With Spot Instances On CI Spot instances are AWS capacity that nobody else wants right now. The pricing is brutal compared to on-demand: a c5.2xlarge that costs around $0.34/hour on-demand drops to roughly $0.08/hour on spot. For workloads like CI/CD, where jobs are short-lived and parallelizable, the math is obvious. The catch is in the contract. AWS reserves the right to take spot capacity back at any moment, with a 2-minute warning. That works for some workloads. For others, it's catastrophic. GitHub Actions runners on Kubernetes is the hard case. A typical CI job goes like this: GitHub assigns the job to a runner. The runner is a pod on a Kubernetes cluster running on an AWS Spot instance. The job downloads dependencies, runs tests, builds artifacts. The runner reports back to GitHub. Now insert a spot termination at minute 4 of a 7-minute build. What happens? The runner pod dies mid-job. GitHub never gets a completion signal; the job hangs until timeout, then marks as "failed". A new runner pod gets schedule ## How to Use GitHub Actions to Deploy to Kubernetes Without Shared Secrets DevFeed: [How to Use GitHub Actions to Deploy to Kubernetes Without Shared Secrets]() Original publisher: [Read original article]() Author: info@goteleport.com (Noah Stride) Published: 2026-08-05T00:00:00Z Content type: tutorial Language: en Sources: [Teleport]() Topics: [GitHub Actions](), [Kubernetes](), [Security](), [sensitive data](), [Vulnerabilities]() Tags: [ci-cd](), [github](), [github-actions](), [how-to](), [kubernetes](), [secrets](), [security](), [sensitive-data]() ### AI overview This tutorial explains how to use Teleport and GitHub Actions to deploy applications to Kubernetes without shared, long-lived credentials. It covers short-lived identities, Kubernetes RBAC, Teleport roles, and join tokens, and discusses extending the approach to database connections and internal APIs. ### Source excerpt Learn how use GitHub Actions to deploy to Kubernetes using short-lived, verifiable identities. ## GitHub agentic workflows and Renovate DevFeed: [GitHub agentic workflows and Renovate]() Original publisher: [Read original article]() Author: Nicolas Fränkel Published: 2026-08-02T00:00:00Z Content type: tutorial Language: en Sources: [Nicolas Fränkel]() Topics: [GitHub](), [GitHub Actions]() Tags: [agentic-workflow](), [dependencies](), [github](), [github-actions](), [github-agentic-workflows](), [pull-requests](), [renovate](), [rollback](), [technical]() ### AI overview This article explains how Renovate dependency updates can break GitHub agentic workflows by changing an action SHA without updating the matching generated scripts. It also describes a failed recompilation workflow that rolled back an unrelated Node.js update, then identifies the need to keep the generated lock file synchronized with its release. ### Source excerpt I've been a big fan of Renovate for a couple of years already. Renovate scans your repositories, detects outdated package versions, and opens pull requests to automatically bump them. It's similar to Dependabot in that it keeps your dependencies up to date. If I had to compare them in one sentence, I'd say Renovate is less integrated in the GitHub ecosystem, but handles more ecosystems and, more importantly, is extensible. ## Best CircleCI alternatives in 2026 DevFeed: [Best CircleCI alternatives in 2026]() Original publisher: [Read original article]() Author: Pete Miloravac Published: 2026-07-31T12:11:33Z Content type: comparison Language: en Sources: [Semaphore Engineering]() Topics: [CI/CD](), [GitHub Actions](), [GitLab](), [Development]() Tags: [alternatives](), [ci-cd](), [compare](), [comparison](), [economics](), [platform](), [pricing](), [support]() ### AI overview This guide compares Semaphore, GitHub Actions, GitLab CI/CD, and Buildkite as alternatives to CircleCI in 2026. It evaluates build speed, cost predictability, support, deployment control, source-control integration, and hosting options. ### Source excerpt Teams looking for CircleCI alternatives are rarely replacing a single feature. They are reassessing build speed, unit economics, support coverage, deployment control, and how easily their CI/CD system fits the source-control platform they already use. CircleCI remains a capable hosted CI/CD product, but its credit-based model meters active users, compute by resource class and minute, [...] The post Best CircleCI alternatives in 2026 appeared first on Semaphore. ## 1Password Credential Broker is now in public preview DevFeed: [1Password Credential Broker is now in public preview]() Original publisher: [Read original article]() Author: info@1password.com (Jeff Malnick) Published: 2026-07-28T00:00:00Z Content type: release Language: en Sources: [Blog on 1Password Blog]() Topics: [Security](), [GitHub Actions](), [OpenID connect (OIDC)](), [CI/CD](), [Cryptography](), [JSON Web Tokens]() Tags: [audit-trail](), [aws](), [azure](), [ci-cd](), [cloud](), [developers](), [encryption](), [github-actions](), [identity](), [incident](), [news](), [policy](), [secrets](), [security](), [unified-access](), [workflow]() ### AI overview 1Password Credential Broker is moving from closed beta to public preview. It uses workload identity federation and GitHub Actions OIDC tokens to give each workload scoped, temporary credential access with detailed issuance attribution and audit logging. ### Source excerpt Every security team has tried to trace a credential access event back to a specific workload, and received nothing but a "service account." That service account probably had access to an entire vault, and its audit trail doesn't tell you which repo triggered the request, which specific credential was accessed, or whether the workflow still has access. When an auditor asks, or an incident occurs, that's not a good place to be. The credentials feeding those workloads are usually created for convenience: scoped broadly to avoid last-minute permission errors, stored in plaintext .env files, placed directly in CI/CD pipelines, and rarely rotated because doing it manually is slow and error-prone. 1Password Credential Broker was built to close that gap: give every workload or agent its own identity and scope its access. Every issuance event gets logged with attribution clear enough to hold up in an incident review. Today, we're moving Credential Broker from closed beta to public preview, available for all Enterprise Password Manager Business customers to start using right now. How 1Password Credential Broker works The foundation of our Credential Broker is Workload Identity Federation, a standards-based approach that GitHub, Google Cloud, AWS, and Azure have all adopted. When a GitHub Actions workflow runs, GitHub automatically generates a signed token that identifies exactly which repo, branch, and workflow is executing. Think of it like a digital badge: here's what this job is and where it came from. Our Credential Broker validates that badge against a trust policy you configure, then delivers only the specific credentials that job is approved to retrieve. The workload can retrieve only the approved credential during the authorized job, without receiving standing access to the vault. We log every issuance with full attribution: the repo, branch, workflow, environment, and commit that triggered the request. Your audit log no longer reads "a service account accessed this i ## Best GitHub Actions Alternatives in 2026 DevFeed: [Best GitHub Actions Alternatives in 2026]() Original publisher: [Read original article]() Author: Pete Miloravac Published: 2026-07-23T12:51:23Z Content type: article Language: en Sources: [Semaphore Engineering]() Topics: [GitHub Actions](), [CI/CD](), [supply-chain-security](), [Vulnerabilities](), [Security]() Tags: [2026](), [alternatives](), [ci-cd](), [compare](), [github](), [github-actions](), [guide](), [outage](), [security](), [supply-chain-security](), [vulnerabilities]() ### AI overview A 2026 guide compares alternatives to GitHub Actions and discusses why some teams are reconsidering it, citing a major outage, a supply-chain attack affecting thousands of repositories, pricing and runner-management concerns, and log usability issues. ### Source excerpt GitHub Actions became the default CI/CD choice for millions of repositories simply because it's built into GitHub. But "default" and "best" are not the same thing -- and in 2026, the gap between the two has gotten harder to ignore. A ten-hour outage in July, a supply-chain attack that backdoored over 5,500 repositories in May, [...] The post Best GitHub Actions Alternatives in 2026 appeared first on Semaphore. ## Nix flake check + JUnit = Junix DevFeed: [Nix flake check + JUnit = Junix]() Original publisher: [Read original article]() Author: Yajo Published: 2026-07-23T12:35:46Z Content type: release Language: en Sources: [Announcements - NixOS Discourse]() Topics: [Nix](), [ci](), [GitHub](), [GitHub Actions](), [GitLab](), [Jenkins]() Tags: [announcements](), [build](), [ci](), [github](), [github-actions](), [gitlab-ci](), [jenkins]() ### AI overview Junix converts Nix JSON output into standard JUnit XML reports, allowing Nix builds and checks to integrate with JUnit-compatible CI systems such as GitLab CI, Jenkins, and GitHub Actions. It can evaluate system checks, repeat failed evaluations for full tracebacks, build local checks, include logs, and print a human-readable summary. ### Source excerpt Hi all! I'd like to share Junix, a small tool that converts Nix @nix JSON output into standard JUnit XML so you can integrate Nix builds with any JUnit-compatible CI (GitLab CI, Jenkins, GitHub Actions, etc.). Try it: cd your/flake nix run gitlab:moduon/junix check -o result.xml This will: Eval all systems checks in one shot If any eval fails, repeat that check's eval to get full traceback Build local system checks Write the JUnit XML report in result.xml with check build logs and eval failure logs, if any Print a colorful human-readable summary 9 posts - 6 participants Read full topic ## Securing Infrastructure at Scale: Introducing Pinterest's Resource Provisioner Pipeline (RPP) DevFeed: [Securing Infrastructure at Scale: Introducing Pinterest's Resource Provisioner Pipeline (RPP)]() Original publisher: [Read original article]() Author: Pinterest Engineering Published: 2026-07-22T16:01:02Z Content type: article Language: en Sources: [Pinterest Engineering Blog - Medium]() Topics: [Infrastructure as code](), [Terraform](), [CI/CD](), [GitHub Actions](), [Amazon Web Services](), [GitHub](), [AWS IAM](), [Security](), [Provisioning](), [Amazon S3](), [Kubernetes](), [networking]() Tags: [aws](), [ci-cd](), [cloud-infrastructure](), [engineering](), [github-actions](), [iam](), [infrastructure](), [infrastructure-as-code](), [kubernetes](), [networking](), [pinterest](), [pull-request](), [s3](), [security](), [terraform]() ### AI overview Pinterest's Resource Provisioner Pipeline (RPP) is a proprietary Terraform execution engine for securely managing infrastructure changes across a distributed, multi-repository environment. The article describes its centralized GitHub Actions workflow, compliance controls, role chaining, and management of AWS infrastructure including IAM, networking, S3, compute, and Kubernetes resources. ### Source excerpt Ammar Ekbote | Senior Software Engineer Chan Kim | Senior Software Engineer Managing Infrastructure as Code (IaC) across a massive organization comes with a unique set of security and logistical challenges, particularly when operating within a distributed, multi-repository architecture. At Pinterest, we designed the Resource Provisioner Pipeline (RPP), our specialized, proprietary Terraform execution engine to safely manage both critical and non-critical infrastructure changes. In this post, we will look under the hood of the first iteration of the RPP system. We will explore how it established compliance and provides robust security guardrails for our global AWS operations by utilizing dual controls, centralized GitHub Actions execution, and a secure role-chaining mechanism. If your engineering team is looking to add strict guardrails to a GitHub workflow-driven Terraform setup, our architecture might serve as a helpful blueprint. What is RPP? RPP delivers a secure, standardized CI/CD workflow for deploying and managing Pinterest's foundational AWS infrastructure. Today, the system manages hundreds of Terraform workspaces that collectively govern tens of thousands of resources. This includes: Security Policies: Managing critical IAM roles and access policies. Networking Infrastructure: Configuring VPCs, Security Groups, Load Balancers, and DNS. Storage & Compute: Provisioning S3 buckets (including access controls) and Kubernetes clusters. The RPP GitHub WorkflowThe Multi-Repo Challenge Pinterest's Terraform code is currently distributed across multiple repositories, each owned and maintained by a completely different team. While we have an ongoing initiative to consolidate these into a unified mono-repository, RPP acts as a vital bridge that securely supports this legacy multi-repo structure. Centralized Execution Model To maintain absolute control over infrastructure states, RPP enforces a centralized execution model for all code changes: Workflow Invocation: The ## AsyncAPI supply chain compromise: npm packages backdoored via GitHub Actions "pwn request" (July 2026) DevFeed: [AsyncAPI supply chain compromise: npm packages backdoored via GitHub Actions "pwn request" (July 2026)]() Original publisher: [Read original article]() Published: 2026-07-14T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [GitHub Actions](), [npm packages](), [AsyncAPI Specification](), [Malware](), [GitHub](), [Remote Access Trojan](), [passwords](), [ssh](), [Cloud](), [Cryptocurrency]() Tags: [asyncapi-supply-chain-attack](), [chainguard-asyncapi](), [chainguard-libraries](), [ci](), [cloud](), [cryptocurrency](), [github](), [github-actions](), [github-actions-pwn-request](), [malicious-packages](), [malware](), [miasma](), [npm](), [npm-packages](), [passwords](), [personal-access-token](), [provenance](), [pull-requests](), [remote-access-trojan](), [ssh](), [supply-chain](), [tokens]() ### AI overview The article analyzes a July 14, 2026 supply-chain compromise in which an attacker stole a privileged GitHub personal access token through a misconfigured GitHub Actions workflow and used it to publish five backdoored versions across four AsyncAPI npm packages. The malware activates when a library is loaded by a build or CI job and steals browser passwords, SSH keys, npm and GitHub tokens, cloud credentials, and cryptocurrency wallets while maintaining command-and-control access. It also explains why Chainguard customers were protected and recommends treating affected environments as compromised and rotating credentials. ### Source excerpt A supply chain attack compromised AsyncAPI npm packages via GitHub Actions. See how Chainguard blocked the malicious releases by design. [Next page]()