This repository provides a GitHub Action (stale-repos) that scans a GitHub organization or user account to identify repositories that have been inactive for a configurable number of days. It is implemented as a Python script packaged in a Docker container, using the PyGithub library to interact with the GitHub API. The action supports authentication via personal access token or GitHub App installation, and can optionally include additional metrics such as days since last release or pull request. Output is generated as both a Markdown report and JSON, and can be automatically added to the GitHub Actions workflow summary. The codebase is well-structured with clear separation of concerns (auth, env, markdown, main logic), comprehensive test coverage, and modern Python tooling (uv, type hints, linting). It is actively maintained with a robust CI/CD pipeline and follows semantic versioning.
actions/github-script is a GitHub Action that allows users to run JavaScript/TypeScript scripts in their workflows with access to a pre-authenticated GitHub API client and other GitHub Action toolkit packages. The action executes user-provided scripts as asynchronous functions within a context that includes github, context, core, glob, io, exec, getOctokit, and require objects. Scripts can make GitHub API calls, perform file operations, and return values that become action outputs. The architecture follows standard GitHub Action patterns with TypeScript source code compiled and bundled via ncc into a single distributable file. Key components include async-function.ts for safely executing user scripts, create-configured-getoctokit.ts for creating secondary authenticated clients with inherited configuration, and wrap-require.ts for handling module resolution. The action integrates with GitHub's retry and request-logging plugins and supports configurable retries, user-agent, base URL, and result encoding.
Wait-for-secrets is a GitHub Action designed to pause workflow execution until a user manually inputs required secrets via a web interface. It leverages GitHub's OIDC tokens to authenticate with the StepSecurity API, which temporarily stores secret metadata and provides a unique URL for user interaction. The action polls the API until secrets are submitted, then makes them available as outputs for subsequent workflow steps. Key features include optional Slack notifications and configurable timeouts. The architecture is straightforward: a TypeScript-based action compiled via ncc into a single JavaScript file, with core logic separated into utility functions for environment parsing, URL generation, and secret handling.
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.
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.
WinGet Releaser is a GitHub Action that automates publishing application releases to the Windows Package Manager (WinGet). When triggered by a GitHub release, it fetches release assets, uses the komac tool to generate/update WinGet manifests, and submits a pull request to the microsoft/winget-pkgs repository. The action supports configurable version retention, installer filtering, and custom release notes. Core functionality resides in a PowerShell script that handles input validation, release data fetching, fork synchronization, komac execution, and version cleanup. The action relies on external tools (gh CLI, komac) but encapsulates complex WinGet publishing logic into a reusable CI component.
This is a standalone Rust web server that implements Turborepo's remote caching API. It acts as a sidecar process, typically started inside CI pipelines (GitHub Actions, GitLab, Kubernetes), that forwards artifact storage and retrieval requests to any S3-compatible object store (AWS S3, Cloudflare R2, RustFS). The server exposes a small set of REST endpoints: health check, artifact upload/download/head, event logging, and a team artifact listing stub. Artifacts are streamed directly from the HTTP body to S3 (and vice versa) without buffering into memory. Optional Bearer-token authentication uses constant-time comparison, and the server is instrumented with OpenTelemetry for distributed traces and system-level metrics (CPU, memory) that are exportable via OTLP. The repository also includes a GitHub Action wrapper (Node.js) that manages the binary lifecycle—startup health polling, graceful shutdown, and log collection—and a multi-stage Docker build that produces statically linked Linux binaries and a universal macOS binary. The architecture is a monolith (single binary) built with actix-web, with clear separation into modules for settings, storage, authentication, routes, and telemetry. All artifacts are scoped under a team prefix derived from the Turborepo client's query parameters.
This is a GitHub Action that parses JaCoCo XML coverage reports and posts a formatted coverage summary as a comment on pull requests. It supports single and multi-module projects, aggregate reports, multiple counter types (INSTRUCTION, BRANCH, LINE, COMPLEXITY, METHOD), custom emojis, and comment update strategies. The action fetches the list of changed files from the PR via the GitHub API, computes overall and per-file coverage percentages, and renders a markdown table with pass/fail indicators based on configurable thresholds. The codebase is written in TypeScript, well-structured with clear separation of concerns (action orchestration, XML parsing, coverage computation, markdown rendering), and includes a comprehensive test suite with fixtures covering various report structures and edge cases.
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 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.
file.d is a high‑throughput log and event processing daemon written in Go, designed for production data pipelines. It reads events from various sources (files, Kafka, Kubernetes, HTTP, syslog, sockets, journalctl), runs them through a configurable chain of action plugins (masking, throttling, transformation, decoding, joining, etc.), and delivers them to multiple outputs (Elasticsearch, ClickHouse, Loki, S3, Kafka, Splunk, Postgres, GELF, file, stdout). The architecture is plugin‑based: inputs, actions, and outputs register into a central registry, and pipelines are defined via YAML configuration. The system provides at‑least‑once delivery semantics, stream‑based ordering, batching with backoff, and dead‑queue failover. The codebase demonstrates strong engineering practices: extensive unit and integration tests (including e2e scenarios with external services), performance optimizations (zero‑copy JSON via insane‑json, event pooling, memory limits), and a rich set of reusable internal libraries (HTTP client with circuit breaker, metric controllers, match rules, configuration parsing). It includes a Helm chart for Kubernetes deployment, Prometheus monitoring with a Grafana dashboard, and a playground web service for interactively testing pipelines. The transform action includes a custom expression language with a Pratt parser and compiler. While the core is solid, there are some maintenance risks: many plugins contain global caches or mutable state, several code paths call `logger.Fatal` on misconfiguration (making the whole process exit), and the file input offset persistence is hand‑rolled. The large number of input/output/action plugins (~40 total) increases surface area for drift, and some e2e tests depend on external Docker services. Overall, file.d is a mature and capable data pipeline framework, well‑suited for log aggregation and transformation in containerized environments.
This repository is a GitHub Action designed to capture screenshots of websites across different operating systems. It takes inputs such as source URL or HTML content, destination filename, and optional parameters like full-page capture, width, and delay. The action uses the `capture-website` package (which relies on Puppeteer) to generate the screenshot, then uploads it as an artifact in the GitHub Actions workflow and exposes the file path as an output. The architecture is straightforward: the entry point (index.js) delegates to core logic in lib/screenshot-website.js, which handles input processing, Chrome executable location based on the runner OS, screenshot capture, artifact upload, and output setting. While the main logic is tightly coupled to the GitHub Actions environment, the repository contains a reusable utility function for normalizing and parsing action inputs (lib/load-inputs.js) that could be extracted for use in other Node.js projects. The action shows signs of technical drift due to its reliance on Node.js 12 (end-of-life) and outdated dependencies like Puppeteer 13.7.0, though it remains functional through active Dependabot updates and CI workflows.
This repository provides a GitHub Action to run Composer commands within a Docker container. It wraps the Composer CLI, allowing users to specify a command (default `install`), PHP version, Composer version, and various flags like `--no-dev`, `--no-progress`, and `--no-interaction`. The action downloads the appropriate Composer PHAR from getcomposer.org, sets up SSH keys for private repositories if provided, and executes the command inside a Docker container based on the php-actions/php-build image. The workspace is mounted at `/app`. The implementation is a single composite action with a bash script that handles argument parsing, SSH key setup, and Docker execution. It is a straightforward, well-documented action that solves the common problem of running Composer in CI pipelines. No reusable components beyond the action itself exist; the bash script is tightly coupled to GitHub Actions and Docker.