werf is a production-grade CLI tool for full-cycle CI/CD of containerized applications to Kubernetes. It provides a unified pipeline for building container images (via Docker or Buildah backends), managing Git-based reproducible configurations (giterminism), deploying Helm charts with advanced tracking and lifecycle management, and performing cleanup of container registry and host resources. The architecture is monolithic but modular, with clear interface abstractions for container backends, registry clients, stage storage, and parallel execution. The codebase demonstrates high craftsmanship in areas like composable path matching, deterministic slug generation, and distributed locking, though it carries some duplication between legacy and modern deploy engines and a few forked dependencies. The repository is actively maintained with frequent releases and extensive test coverage across unit, integration, and e2e suites.
NuGetForUnity is a NuGet client built specifically for the Unity Editor, enabling package management directly within Unity projects. It provides an interactive editor window for browsing, installing, updating, and uninstalling NuGet packages, as well as a headless CLI tool for CI/CD pipelines. The system integrates with Unity's asset pipeline to configure imported DLLs (analyzers, native runtimes, player-only assemblies) and supports both NuGet V2 (OData) and V3 (JSON) API protocols. It also offers a plugin API for third-party extensibility through custom buttons, file handlers, and uninstall hooks. The architecture is modular, with clear separation between configuration, models, package sources, UI, and plugin support, all within the Unity Editor's asmdef framework.
This repository is the official build infrastructure for .NET Docker images. It generates, tests, and publishes Docker images for .NET SDK, runtime, ASP.NET Core, and related tools (monitor, Aspire Dashboard) across multiple operating systems (Alpine, Ubuntu, Debian, Azure Linux, Windows) and architectures (amd64, arm64v8, arm32v7). The core of the system is a template engine (Cottle) that produces Dockerfiles from parameterized templates, combined with a comprehensive test suite that validates generated artifacts against approved baselines and verifies image behavior at runtime. The repository also includes a sophisticated dependency update tool (C# CLI) that automatically updates .NET versions, PowerShell, Syft, Chisel, and other dependencies by fetching release information from GitHub, Azure DevOps, and internal build services, then creating pull requests against the repository. The CI/CD pipeline (Azure Pipelines) orchestrates building, testing, signing, and publishing images to Microsoft Container Registry and other registries. Sample applications demonstrate common .NET deployment patterns in Docker and Kubernetes. Architecture: The system is organized into several layers: (1) Dockerfile templates in `eng/dockerfile-templates/` that generate the actual Dockerfiles in `src/`; (2) a dependency update tool in `eng/update-dependencies/` that automates version bumps; (3) a test suite in `tests/` that validates generated artifacts and image behavior; (4) pipeline definitions in `eng/pipelines/` and `eng/docker-tools/` that orchestrate CI/CD; and (5) sample applications in `samples/` for testing and documentation. Key entry points include the update-dependencies CLI (`Program.cs`), the test runner (`run-tests.ps1`), and the pipeline YAML files. External dependencies include Azure DevOps (pipelines, blob storage), GitHub (releases), and various package registries. Data flows: Version metadata flows from `manifest.json` and `manifest.versions.json` into the template engine to generate Dockerfiles with correct version numbers and checksums. The update-dependencies tool fetches new versions from external sources (GitHub releases, Azure DevOps pipelines, BAR service) and updates the manifest files, then creates pull requests. The test suite reads the manifest to build a test matrix, builds Docker images from the generated Dockerfiles, and runs validation tests (package lists, environment variables, HTTP endpoints).
This repository implements a GitHub Action that automates deployment of static content to GitHub Pages. It takes a folder from the workspace, optionally builds it, and pushes the contents to a specified branch (default `gh-pages`) using git worktrees and rsync. The action supports authentication via GitHub token, personal access token, or SSH deploy keys, and offers extensive configuration options including clean deployments, single-commit history, target subfolders, dry runs, tags, and Git LFS. The architecture is modular: `src/main.ts` is the entry point, `src/lib.ts` orchestrates the workflow, `src/git.ts` handles repository initialization and deployment, `src/worktree.ts` manages git worktree creation with retry logic, `src/ssh.ts` configures SSH clients, and `src/execute.ts` provides a reusable command execution wrapper. The action relies on external tools `git`, `rsync`, and `ssh-agent`, and uses the `@actions/*` toolkit for GitHub Actions integration. The codebase is well-structured TypeScript with comprehensive unit and integration tests, and follows modern JavaScript practices with ESLint, Prettier, and Jest.
Jenkins is the leading open-source automation server, providing a web-based platform for continuous integration and continuous delivery (CI/CD). In production, it orchestrates build, test, and deployment pipelines triggered by SCM changes, scheduled intervals, or manual requests. The architecture is a monolithic Java web application with a plugin-based extension system, using Stapler for URL routing, Jelly/HTML views, and a modern JavaScript frontend bundled with webpack. Key entry points include the central `Jenkins` singleton, a rich set of CLI commands (e.g., `BuildCommand`, `CreateJobCommand`), and a REST-like API. Data flows involve job scheduling via the `Queue`, execution on agents (controller/agent architecture), SCM checkout, build steps, artifact archiving, and result reporting. External dependencies include a servlet container (Jetty), Spring Security (migrating from Acegi), XStream for XML persistence, and numerous libraries for remoting, templating, and UI components. The codebase is highly extensible through `@Extension` points, descriptors, and a well-defined plugin lifecycle.
Spinnaker is a continuous delivery platform with a microservices architecture for deploying and managing applications across multiple cloud providers. The system consists of distinct services including clouddriver (cloud abstraction), orca (pipeline orchestration), deck (React/UI), gate (API gateway), fiat (authorization), front50 (storage), echo (event processing), igor (CI integrations), kayenta (canary analysis), and rosco (image baking). It features polyglot implementation (Java/Kotlin/TypeScript/Groovy), Spring Boot backend services, React frontend, RESTful APIs, event-driven architecture, and extensive cloud provider integrations. The platform enables pipeline definition, execution, artifact management, and deployment strategies across AWS, Kubernetes, GCP, Azure, and other environments.
Unlighthouse is a CLI tool and web dashboard that scans entire websites using Google Lighthouse, aggregating results across all pages and presenting them in a real-time, filterable dashboard. The architecture is a monorepo with separate packages for core scanning logic, CLI, CI integration, a Vue 3 client, and a small h3 server for serving reports and WebSocket updates. Key entry points include the `unlighthouse` CLI (via `cac`), the `unlighthouse-ci` CI command, and the `createUnlighthouse` function from `@unlighthouse/core`. Primary data flows: URL discovery (sitemap, robots.txt, crawling), parallel Lighthouse runs via `puppeteer-cluster`, streaming results to the client, and exporting reports (HTML, JSON, CSV, LHCI). External dependencies include Puppeteer (Chrome), Lighthouse, and optionally the CrUX API for historical field data. The codebase is well-structured, uses ESM, and has a modern build pipeline with Vite and Vitest. Some integrations (Nuxt, Vite, Webpack) are deprecated, but the core functionality remains actively maintained. The client UI is feature-rich, with dark mode, search, pagination, and detailed audit result views.
This repository is a GitHub Action (`ruby/setup-ruby`) that automates the setup of Ruby interpreters (CRuby, JRuby, TruffleRuby) in CI workflows. It downloads prebuilt binaries from official builders (ruby-builder, RubyInstaller2), adds them to PATH, and optionally configures RubyGems and Bundler with intelligent version resolution. A key feature is built-in caching of `bundle install` results via a sophisticated key scheme that accounts for OS, Ruby version, Bundler configuration, and gemfile lock hash. The action supports reading Ruby version from `.ruby-version`, `.tool-versions`, or `mise.toml`, and handles Windows toolchains (MSYS2, DevKit, VCPKG/MSVC) for native gem compilation. The architecture is modular (common utilities, Ruby builder, Bundler, RubyGems, Windows-specific code) and the code is well-structured with clear error handling and thorough CI testing across a matrix of 100+ combinations of OS, Ruby versions, and architectures. Maintenance is active with automated version updates via scheduled workflows and a defined release team.
This repository is a comprehensive collection of over 1200 standalone Bash scripts for DevOps automation, cloud infrastructure management, CI/CD pipeline orchestration, and system administration. It is not a single application but a modular toolbox designed to be used interactively or integrated into CI workflows. The architecture is decentralized: each script is self-contained, sourcing shared libraries from the `lib/` directory for common functions like error handling, API authentication, and OS detection. Key entry points include the top-level `Makefile` for bootstrapping, `lib/utils.sh` as the core utility library, and numerous API wrapper scripts (e.g., `github_api.sh`, `aws_foreach_profile.sh`) that provide consistent patterns for interacting with external services. The primary data flows involve querying cloud provider APIs (AWS, GCP, Cloudflare), managing CI/CD platforms (Jenkins, BuildKite, GitHub Actions), manipulating Git repositories, and performing system tasks like disk benchmarking or SSL certificate verification. External dependencies are extensive but well-managed: the scripts assume the presence of `curl`, `jq`, and platform-specific CLIs (`aws`, `gcloud`, `kubectl`, `gh`), with many install scripts provided to bootstrap these tools. The codebase demonstrates high craftsmanship with consistent error handling (`set -euo pipefail`), input validation, and cross-platform compatibility guards. While some scripts are tailored to the author's personal environment, the core patterns and libraries are designed for reuse across projects.
This is a GitHub Action that automates creating releases in Sentry (error monitoring platform). The action wraps the `@sentry/cli` tool and runs as either a Docker container on Linux runners or a composite action installing the CLI on macOS/Windows. Its core workflow (in `src/main.ts`) parses inputs, validates environment variables, then orchestrates a sequence of sentry-cli calls: creating a release, optionally setting commits (auto/skip/manual), injecting debug IDs into source files, uploading source maps, deploying to an environment, and finalizing the release. Telemetry via `@sentry/node` is collected to monitor action performance. The codebase is small (5 source files plus tests), cleanly structured, and well-tested with both unit tests and end-to-end integration tests against Sentry's API. It is actively maintained with recent dependency bumps and proper CI/CD pipelines.
This repository is a semantic-release plugin that automates the publishing of npm packages. It implements four lifecycle steps: verifyConditions (validates configuration and authentication), prepare (updates package.json version and optionally creates a tarball), publish (publishes the package to the npm registry), and addChannel (adds a release to a dist-tag). The plugin supports both token-based authentication (via NPM_TOKEN) and OIDC-based trusted publishing for GitHub Actions, GitLab Pipelines, and CircleCI. It can publish to custom registries, handle scoped packages, and skip publishing for private packages or when npmPublish is false. The architecture is a set of exported async functions that receive pluginConfig and context from semantic-release, delegating to internal lib modules. External dependencies include the npm CLI (executed via execa), fs-extra for file operations, registry-auth-token for authentication, env-ci for CI provider detection, and @actions/core for OIDC token retrieval. The codebase is well-structured with clear separation of concerns, comprehensive error handling using AggregateError, and extensive test coverage with both unit and integration tests.
Pipelines-as-Code is a Kubernetes-native CI/CD controller that triggers Tekton PipelineRuns in response to Git webhook events from multiple providers (GitHub, GitLab, Gitea/Forgejo, Bitbucket Cloud/Data Center). In production, it listens for webhook payloads on a configurable endpoint, detects and validates the provider, matches events to PipelineRun templates stored in the repository's `.tekton/` directory using CEL expressions and annotations, resolves remote tasks and pipelines via hub or URL, creates PipelineRun resources with appropriate parameters and secrets, and reports status back to the Git provider (commit statuses, check runs, comments). It supports ChatOps commands (`/test`, `/retest`, `/cancel`), GitOps-style push commands, concurrency limits, automatic cleanup of old PipelineRuns, and optional LLM-driven failure analysis. The architecture consists of three main controllers (controller, watcher, webhook) plus a CLI tool (`tkn-pac`) for bootstrapping, repository management, and local testing. The codebase is well-structured, with clean provider abstractions, a modular queue system, extensive OpenTelemetry instrumentation, and comprehensive test coverage across all providers. While the multi-provider support introduces some duplication, the core patterns (event matching, pipeline resolution, status reporting) are cleanly separated and reusable.
sbt-github-actions is an sbt AutoPlugin that generates and maintains GitHub Actions workflow files (ci.yml and clean.yml) for sbt builds. It derives the CI matrix from crossScalaVersions, adds checkout/setup/caching steps, and can publish from the exact binaries tested in the build. It also generates a separate clean.yml workflow that deletes old workflow runs and artifacts via the GitHub API, working around the limitation that workflow artifacts are not visible until the workflow finishes.
This repository implements the official GitHub Action `actions/setup-node`, which sets up a Node.js environment in GitHub Actions workflows. It downloads and caches the requested Node.js version (including LTS, nightly, RC, and v8-canary builds), adds it to the PATH, optionally caches npm/yarn/pnpm dependencies using `actions/cache`, registers problem matchers for TypeScript and ESLint, and configures authentication for private npm registries. The architecture is a composite action with a main entry point (`src/setup-node.ts`) and a post-job cache-save entry point (`src/cache-save.ts`), both compiled via ncc. The codebase is well-structured with abstract base classes for distribution handling, a factory pattern for selecting the correct distribution, and separate modules for cache utilities and authentication. It relies on the `@actions/*` toolkit libraries and external services (GitHub node-versions manifest, nodejs.org dist mirrors).
This repository implements the Azure Pipelines Agent, a cross-platform CI/CD agent that executes build, release, and deployment jobs for Azure DevOps and Team Foundation Server. The agent is written in C# on .NET Core and runs on Windows, macOS, and Linux. Its architecture consists of a Listener process that handles agent lifecycle (registration, authentication, message polling) and a Worker process that executes job steps (tasks, scripts, containers). The codebase includes a plugin system for source control (Git, TFVC, SVN), artifact management, pipeline caching, test result publishing, and code coverage. It features a robust configuration system based on knobs, secret masking, telemetry, and extensive logging. The agent communicates with Azure DevOps services via REST APIs and manages credential storage, proxies, and certificates. While the codebase is mature and well-structured, it contains some legacy code paths, platform-specific implementations, and feature flag complexity that reflect its long evolution.
This repository contains the source code for the New Relic documentation website, built with Gatsby and React. It is a static site generator that renders thousands of documentation pages in Markdown/MDX with full internationalization support (ES, FR, JP, KR, PT). The site includes a custom install wizard, reusable UI components (inline popovers, feedback modals, code definition blocks), multiple Gatsby plugins for remark processing, automated translation workflows, and extensive CI/CD pipelines for building, linting, and deploying. The codebase is well-organized with a clear separation of content, components, layouts, and scripts. While primarily a documentation site rather than a general-purpose application, the engineering is solid with automated testing, linting (Vale), and maintenance best practices.
This repository contains the complete LaTeX source for 'An Infinitely Large Napkin', a comprehensive advanced mathematics textbook by Evan Chen. The project is primarily a document production pipeline: the core content is a collection of modular .tex files organized by topic (algebra, topology, analysis, etc.), with extensive cross-references, custom macros, and Asymptote figures. However, the repository also exhibits strong software engineering practices: it includes a Nix flake for reproducible builds, GitHub Actions CI/CD workflows that compile the PDF and deploy to GitHub Pages, pre-commit hooks for code quality, and helper scripts (export-flowchart.sh, print-toc.py) for generating dependency graphs and split PDFs. This hybrid nature makes it both a textbook source and a well-automated document production application.
This is the official Heroku buildpack for Python applications. It implements the standard buildpack lifecycle (detect, compile, release, report) to install a Python runtime and manage dependencies using pip, pipenv, poetry, or uv. It handles Django collectstatic, NLTK corpora downloads, user-supplied hooks (pre/post compile), and Heroku CI. The codebase is a collection of modular shell scripts with a consistent library pattern, extensive integration tests via Hatchet/RSpec, and support for multiple Heroku stacks. It is actively maintained, with Dependabot for dependency updates and CI workflows for every commit. The architecture is straightforward: each lifecycle phase is a standalone script that sources reusable libraries from lib/. While the core logic is specific to Heroku's platform, the library functions (e.g., caching, version resolution, build data reporting) demonstrate good shell scripting practices and could be adapted for other build systems.
This repository is a comprehensive Python tutorial (28k+ stars) covering beginner to advanced topics, with content written in Markdown and published as a static documentation site via MkDocs. The codebase includes a custom tool (`tools/example_runner.py`) that extracts and executes Python code blocks from the Markdown files to verify correctness, integrated into CI. The project also uses modern Python tooling (uv, ruff, pytest) and provides an interactive learning site at learn-py.org. While primarily educational content, the repository demonstrates solid engineering practices with automated testing of examples, dependency management, and CI/CD pipelines.
This repository is a code generation and CI orchestration system for Terraform providers targeting Google Cloud Platform. The core functionality reads YAML definitions of GCP products and resources (hundreds of YAML files under mmv1/products/) and uses Go templates (mmv1/templates/terraform/) to generate the full source code for the google and google-beta Terraform providers, including resources, data sources, IAM policies, tests, and documentation. It also generates code for the terraform-google-conversion (TGC) library used for Cloud Asset Inventory conversion. The CI component (magician) manages pull request workflows: downstream generation, VCR-based acceptance testing, automatic reviewer assignment, scheduled PR reminders, and test failure triage. Additional tools handle breaking change detection, missing test/doc/identity analysis, issue labeling, and template validation. The architecture is a multi-module Go CLI (mmv1 generator + magician + several tools) with extensive use of Go templates, YAML configurations, and Bazel build system. While primarily an application, it includes data processing elements in the diff-processor and test reader that perform schema comparison and coverage analysis, giving it a hybrid flavor dominated by code generation and CI.