jest-junit is a Jest reporter that transforms test results into JUnit-compatible XML files, commonly used in CI/CD pipelines for integration with tools like Jenkins, CircleCI, and GitLab CI. The codebase is a small, focused Node.js library with a clear architecture: an entry point that supports both the modern reporter API and the deprecated testResultsProcessor, a configuration resolver that merges settings from environment variables, package.json, and reporter options, and a core transformation module (`buildJsonResults`) that converts Jest's aggregated result objects into a structured JSON representation directly mappable to JUnit XML via the `xml` package. It handles template variables for test suite names, class names, and test titles, supports custom properties via external JS files, and manages edge cases like test compilation errors, empty suites, console output inclusion, and retried tests. The code is well-tested with Jest and includes XML schema validation. While the library is not architecturally groundbreaking, it is cleanly modular, follows Node.js best practices, and its configuration and transformation patterns could be reused in other test report generators.
This repository provides the Docker image build infrastructure for Composer, the PHP dependency manager. It contains Dockerfiles for multiple Composer versions (1.10 LTS, 2.2 LTS, latest), a common entrypoint script, and GitHub Actions workflows that build multi-architecture images and push them to Docker Hub, Amazon ECR, and GitHub Container Registry. The Dockerfiles use multi-stage builds to produce both a full runtime image and a standalone binary image, with security best practices such as SHA checksum verification for downloaded artifacts. The entrypoint script wraps the Composer CLI with tini for proper signal handling and supports transparent command forwarding. The repository also includes a script for generating the official Docker library metadata and automated dependency updates via Dependabot and Renovate. It is a well-maintained, production-grade CI/CD pipeline for containerizing Composer.
OVH CDS is an enterprise-grade continuous delivery and DevOps automation platform. The repository contains a set of Go services (API, CDN, hooks, VCS, repositories, hatcheries, worker, elasticsearch) managed via a common engine binary, supported by PostgreSQL, Redis, and OpenSearch/Elasticsearch, plus an Angular web UI, a cdsctl CLI, and gRPC-based action/integration plugins. In production it orchestrates pipelines and workflows, spawns workers on Kubernetes, Swarm, OpenStack, vSphere or local hosts, ingests VCS webhooks, stores job logs and artifacts through a pluggable CDN storage layer, and enforces fine-grained RBAC across projects, regions, workflows, and variable sets. Both legacy v1 workflows and newer as-code v2 workflows are implemented and actively maintained side-by-side.
Jpom is a production-grade, self-hosted DevOps platform built with Java (Spring Boot) and Vue 3. It adopts a server-agent architecture: a central server manages multiple agent nodes via HTTP/WebSocket, enabling remote project deployment, process lifecycle management, script execution, Docker container orchestration, SSH command dispatch, and real-time log monitoring. The server provides a web UI and REST API for configuration, while agents execute operations locally. The codebase is modular, with clear separation into `server`, `agent`, `common`, `storage-module`, and `sub-plugin` modules, plus a Vue frontend with internationalization (i18n) support. Key features include CI/CD build pipelines (Git/SVN), artifact distribution ('outgiving'), trigger tokens for webhook automation, role-based access control with workspaces, database-backend abstraction (H2, MySQL, PostgreSQL), and a plugin system for extensibility (Git, SVN, Docker, encryption, email, webhook). The architecture demonstrates strong engineering practices: SPI-based plugin loading, annotation-driven validation and permission checks, a layered service model with database-agnostic storage, and comprehensive WebSocket handling for real-time features. The codebase is actively maintained with frequent releases and a detailed changelog. While some modules show code duplication (e.g., `SocketSessionUtil` in server and agent) and a number of test files are exploratory or stale, the overall design is clean, the plugin system is genuinely reusable, and the storage abstraction layer (H2, MySQL, PostgreSQL) is a highlight for multi-dialect support. This is a solid implementation of a complex distributed management tool, suitable for teams needing a self-hosted alternative to commercial CI/CD or server management platforms.
This repository is the official GitHub Action for setting up the Google Cloud SDK (`gcloud`) in GitHub Actions workflows. It handles downloading, installing, and configuring the Cloud SDK, including optional components and authentication. The action is a thin TypeScript wrapper around the internal `@google-github-actions/setup-cloud-sdk` and `@google-github-actions/actions-utils` packages. The main entry point is `src/main.ts`, which reads inputs (version, project ID, install components, etc.), installs the SDK if necessary, authenticates using credentials from the `google-github-actions/auth` action, and sets the default project. It outputs the installed version. The code is well-structured, uses strict TypeScript with up-to-date dependencies, and includes both unit and integration tests. Because the heavy logic is delegated to internal packages, this action is straightforward and reliable but not architecturally remarkable. The repository is actively maintained by Google with rigorous CI/CD and dependabot security updates.
This repository is a GitHub template for bootstrapping Kotlin Android projects with a modern, opinionated build setup. It provides a multi-module structure (app, library-android, library-kotlin, library-compose) with pre-configured static analysis via detekt, CI/CD via GitHub Actions, and publishing to Maven Central. The codebase demonstrates best practices for Gradle Kotlin DSL, version catalogs, and precompiled script plugins. The sample modules include a simple factorial calculator to illustrate cross-module dependencies and testing patterns (unit, instrumentation, and Compose UI tests). While the template is not a production application itself, it serves as a solid foundation for new Android projects, emphasizing code quality and automation from the start.
This repository provides a regularly updated list of all public npm package names (including scoped packages) as a large JSON array. The primary artifact is `names.json`, which is versioned with Git LFS and updated daily via a scheduled GitHub Actions workflow. The core logic resides in `script/build.js`, which fetches normalized repository data from the `all-the-package-repos` npm package, extracts package names, filters out purely numeric names, and writes the result as a pretty-printed JSON array. The package exposes a Node.js entry point (`require('all-the-package-names')`) returning the array, and a CLI command that outputs newline-delimited names. Tests verify the array structure, size, and exclusion of numeric names. While the codebase is minimal and straightforward, it is professionally maintained with CI/CD, automated releases, and LFS support for large data. It serves as a dependency for many npm ecosystem tools that need offline name lookups or filtering.
This repository contains the official Dockerfiles and automation tooling for building and publishing Amazon Corretto Docker images across multiple versions (8, 11, 17, 21, 25, 26, 27) and base operating systems (Amazon Linux 2, Amazon Linux 2023, Alpine, Debian). The codebase does not contain a running application but instead acts as a build configuration and CI/CD orchestration layer. The Dockerfiles are meticulously crafted: they verify package signatures via RPM or APT keys, install dependencies (e.g., fontconfig), clean temporary files, and set environment variables. Notable 'slim' variants use `jlink` to produce smaller runtime images by stripping debug symbols, man pages, and header files—a non-obvious optimization. The repository also includes Python scripts (`bin/apply-template.py`, `bin/tag-generator.py`) and shell scripts (`bin/update-dockerfiles.sh`, `bin/test-image.sh`) that automate Dockerfile generation, version propagation, and image validation via container-structure-test. CI/CD is implemented in GitHub Actions and validates images for every push/PR. The repository is the authoritative source for the official amazoncorretto Docker images on Docker Hub and ECR, and its primary purpose is to produce reproducible, secure JDK containers.
The Jenkins Job DSL Plugin is a mature, actively maintained Jenkins plugin that provides a Groovy-based domain-specific language for programmatically defining Jenkins jobs, views, folders, and other configuration items. It enables 'Configuration as Code' for Jenkins, allowing infrastructure to be version-controlled and automatically generated. The plugin executes as a build step in a seed job, parsing DSL scripts and creating or updating Jenkins items. The architecture consists of a core library (`job-dsl-core`) with hundreds of context classes that map DSL method calls to XML configuration nodes, and a Jenkins plugin module (`job-dsl-plugin`) that integrates with the Jenkins API for script execution, security, and result tracking. The plugin supports all major Jenkins job types (freestyle, pipeline, multibranch, matrix, etc.), SCM integrations, build triggers, wrappers, publishers, and parameterized builds. A notable feature is the Dynamic DSL, which automatically discovers and exposes methods for any Jenkins plugin that follows the Describable pattern, reducing the need for built-in methods. The codebase is extensive with thorough Spock tests, but is tightly coupled to specific Jenkins plugin versions and Groovy 2.4, and the built-in DSL is in maintenance mode in favor of the Dynamic DSL. The repository includes a web-based API viewer and comprehensive documentation for migration and scripting.
This repository implements a GitHub Action that cancels previous workflow runs that are not completed (queued or in_progress) for a given workflow. The action is written in TypeScript and bundled using vercel/ncc for distribution. It processes inputs to determine which workflows to target, handles various GitHub events (push, pull_request, workflow_run), and uses the GitHub API via @actions/github to query and cancel workflow runs based on configurable conditions like ignoring SHA, canceling all but the latest, filtering by status, or force canceling. The architecture is a single source file (src/index.ts) that collects context from the GitHub Actions environment, resolves target workflows, lists relevant runs, applies filters, and cancels matching runs. The action demonstrates proper error handling, logging, and use of the GitHub Actions toolkit, making it a reliable tool for managing workflow concurrency.
PullPreview is a GitHub Action implemented in Go that provisions ephemeral preview environments for pull requests. It manages cloud instances (AWS Lightsail or Hetzner), installs Docker or Kubernetes (k3s), and deploys applications using Docker Compose or Helm. The action integrates deeply with GitHub PR workflows: it reacts to labels, synchronizes SSH keys from repository collaborators, updates PR comments with deployment status and preview URLs, and performs scheduled cleanup of dangling instances. The codebase is organized around a provider abstraction pattern, with concrete implementations for Lightsail and Hetzner that share common orchestration logic for instance lifecycle, SSH access, and deployment. It is a self-contained CLI binary that runs as a composite action step, bundling all dependencies into a single executable.
lewagon/data-setup is a Ruby-based documentation build system that generates the Le Wagon Data Science bootcamp environment setup guides for macOS, Windows, Linux, VM, and remote setups. It reads OS-specific YAML build specifications, resolves localized markdown partials from `_partials/` (including Spanish translations and remote partials fetched from other lewagon repositories), renders them with Liquid templating, and writes final bilingual guides back to markdown files. The primary entry point is `build.rb`, orchestrated by `lib/builder.rb` and `lib/generator.rb`, with CI via GitHub Actions rebuilding and committing generated files on every push. Despite the data-science branding, this is not a data-research repository: there is no pipeline, notebook, or model code. The only data-related artifacts are pinned Python package requirement files under `specs/releases/` and environment verification scripts in `checks/`. The dominant character is an application — specifically a content-generation toolchain for setup documentation. It demonstrates a clean partial-composition model, locale-aware fallback, remote content fetching with image-path rewriting, and parallel partial caching. The repository is actively maintained and technically current, though its reliance on pinned Python versions and remote GitHub raw URLs creates an ongoing need for upkeep. It is a well-structured niche tool rather than a general-purpose framework, but its modular design makes parts of the build pipeline reusable in similar multi-source documentation projects.
This repository is a Docker image build system for creating customized Ubuntu-based images optimized for GitHub Actions (via nektos/act) and CI/CD workflows. It uses a parameterized Dockerfile and modular shell scripts to install specific toolsets (Java, Go, Node.js, .NET, etc.) on top of base images. The build process is orchestrated by a PowerShell script (build.ps1) that leverages Buildah for multi-arch image creation and manifest handling, with GitHub Actions automating scheduled and triggered builds. The system produces images tagged for various use cases like 'act', 'runner', 'js', 'rust', etc., pushing to multiple container registries.
This is a Jenkins plugin that dynamically provisions Docker containers as ephemeral build agents. It acts as a cloud provider within Jenkins, managing the full lifecycle of containers: pulling images, creating and starting containers, connecting Jenkins agents via attach (docker exec), JNLP, or SSH, and cleaning up containers after builds. The architecture is a standard Jenkins plugin using core extension points (Cloud, Computer, Launcher, RetentionStrategy, Builder, Publisher) and deeply integrates with Pipeline (DockerNodeStep, DockerAgent). It communicates with the Docker daemon via the docker-java library, supports Unix sockets, TCP, and TLS with Jenkins credentials, and includes a management UI. The codebase is well-structured with clear separation of concerns (cloud, template, connectors, utilities) and several reusable patterns (client caching, multiplexed stream parsing, connection retries, ID generation). However, it carries significant technical debt from long-term backward compatibility, with many deprecated fields, migration code via readResolve(), suppressed SpotBugs warnings, and some thread-safety concerns. Test coverage is reasonable but some integration tests are flaky due to Docker dependency. Overall, it is a solid, actively maintained plugin suitable for production use in Jenkins-based CI/CD environments.
Cali is a TypeScript-based CLI application designed for React Native and Expo development teams. It functions as an AI-powered orchestration layer that automates mobile quality assurance, code review, and performance analysis. The system operates by ingesting repository context (PR data, mobile artifacts) and executing structured agent loops that interact with platform-specific tools (Android/iOS SDKs) via the Vercel AI SDK. It supports both local execution and CI environments (GitHub Actions, EAS), generating structured reports in JSON and Markdown formats. Architecturally, it follows a monorepo pattern with distinct packages for the core CLI (packages/cali) and platform-specific tool wrappers (packages/tools). The core logic relies on a role-based command structure where specific tasks (QA, Review, Dev) are delegated to specialized agent roles. Data flow is deterministic, moving from context resolution through tool execution to report publishing, ensuring consistent behavior across different environments. The tool distinguishes itself by managing complex mobile development contexts, such as artifact parsing (APK/IPA) and device management, which are typically brittle in automated workflows. It integrates skill discovery for AI agents and supports multiple output publishers (local file, Vercel Blob). While it solves a specific niche problem effectively, it introduces dependencies on external binaries and rapid-versioning AI SDKs that require careful maintenance.
This repository is the official awesome list for OpenCode, a terminal AI coding agent. It maintains a curated catalog of plugins, themes, agents, projects, and resources as YAML files under data/. A small set of Node.js scripts validates the YAML against a JSON schema, generates the README.md from a template, and exports a normalized dist/registry.json for downstream consumers such as opencode.cafe. CI workflows validate PRs and automatically regenerate the README/registry whenever the YAML data changes. Architecturally this is a data-driven build tool: YAML files are the source of truth, and scripts/validate.js, scripts/generate-readme.js, and scripts/export-json.js are the functional entry points. They use standard dependencies (ajv, js-yaml, glob) and are organized cleanly. There is no runtime service, API, or library here; the repo is a curated content registry plus lightweight tooling to keep the catalog consistent and machine-readable. The code is straightforward, with no tests but with solid validation and a well-designed schema.
Digger (now OpenTaco) is an infrastructure-as-code orchestration platform that automates Terraform, OpenTofu, Terragrunt, and Pulumi workflows within existing CI/CD pipelines. The system provides PR-level automation (plan/apply comments), drift detection, policy-as-code via OPA, and an optional Terraform Enterprise-compatible state management and remote execution layer. It integrates with GitHub, GitLab, Bitbucket, Azure DevOps, and Buildkite through webhooks and CI backends. The architecture is a multi-service monorepo: a Go backend (Gin/GORM) handles webhooks, job scheduling, and a web UI; a separate CLI tool (cobra) runs directly in CI; a drift detection service with cron scheduling; a sandbox sidecar (TypeScript/Node) for remote execution; and the Taco service (Echo) that reimplements TFE APIs for state management, RBAC, and run execution. The UI is a React/TanStack Router app with WorkOS authentication. The codebase is actively maintained with frequent releases, extensive SQL migrations, Helm charts for Kubernetes deployment, and dual open-core and enterprise (ee/) feature sets.
This repository is the operational backbone for Bazel's continuous integration system. It orchestrates Buildkite pipelines for hundreds of Bazel projects (including Bazel itself, rules repositories, and downstream projects like TensorFlow), manages cloud infrastructure on Google Cloud Platform (GCE, GCR, Cloud SQL, BigQuery), and provides a suite of tools for release management, cherry-picking, metrics collection, and a monitoring dashboard. The architecture is polyglot: a Rust agent uploads test artifacts from Build Event Protocol files, a Go service collects and publishes pipeline performance metrics, a Spring Boot backend with a Next.js frontend serves a dashboard for tracking GitHub issues and build stats, and Python scripts (primarily `bazelci.py`) handle dynamic pipeline generation and CI orchestration. Infrastructure is managed via Terraform, with GitHub Actions for automated PR review of the Bazel Central Registry and release workflows. The codebase is actively maintained but shows signs of technical drift, including hardcoded versions, references to end-of-life platforms, and a large number of manually defined pipelines that risk configuration drift.
This repository is a curated list of awesome Jupyter projects, libraries, and resources. It serves as a reference for developers and data scientists seeking tools to enhance their Jupyter experience, including runtimes, visualization libraries, collaboration tools, and more. The list is organized into thematic categories (e.g., Runtimes/Frontends, Collaboration/Education, Visualization) for easy navigation and discovery. The repository includes maintenance workflows to ensure the quality and consistency of the list. A GitHub Actions workflow runs awesome-lint and remark-lint to validate the format of the list and keep it alphabetized. Another workflow tracks GitHub traffic statistics. The project follows standard contribution guidelines and is licensed under Creative Commons Attribution-ShareAlike 4.0. While the repository itself does not contain executable code or data, it provides significant value as a discovery tool for the Jupyter ecosystem. The maintained workflows demonstrate good practices for keeping awesome lists clean and consistent, which can be reused in similar projects. The content is regularly updated, as evidenced by recent commits, indicating active maintenance.
This is a single-file Bash script that performs a comprehensive security and performance audit of a Linux VPS. It checks SSH configuration, firewall status, intrusion prevention systems (Fail2ban/CrowdSec), failed login attempts, system updates, running services, open ports, disk/memory/CPU usage, sudo logging, password policy, and SUID files. The script outputs color-coded PASS/WARN/FAIL results to the console and writes a detailed timestamped report to a file. It is designed for Ubuntu/Debian-based systems and requires root or sudo privileges. The architecture is a monolithic Bash script with no external dependencies beyond standard Linux utilities and optional tools like UFW, Fail2ban, and Docker. The code is well-structured with configurable thresholds and file paths, demonstrating solid Bash scripting practices. However, it is not designed for reuse as a library; it is a standalone tool.