If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/github/janky shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• 13 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 4y ago
• ⚠ Concentrated ownership — top contributor handles 61% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live github/janky repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/github/janky.

What it runs against: a local clone of github/janky — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in github/janky | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 1526 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of github/janky. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/github/janky.git
#   cd janky
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of github/janky and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "github/janky(\\.git)?\\b" \\
  && ok "origin remote is github/janky" \\
  || miss "origin remote is not github/janky (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1526 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1496d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/github/janky"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Janky is a continuous integration (CI) server built on Jenkins, controlled through Hubot chat commands, and designed for GitHub repositories. It automates build triggers on push events via GitHub webhooks, manages Jenkins jobs, and posts build status notifications to chat services (Slack, HipChat, Campfire). The core value is wrapping Jenkins complexity behind simple chat commands so teams can manage CI without leaving their chat platform. Monolithic Rails/Sinatra app (lib/janky/app.rb is the Rack entry point). Core logic splits into: Builder (lib/janky/builder/) handles Jenkins interaction, ChatService (lib/janky/chat_service/) abstracts multiple chat backends, Database (lib/janky/database/) manages schema via migrations. config.ru loads as a Rack app; Dockerfile and docker-compose.yml show containerized deployment with Jenkins sidecar.

Engineering teams using GitHub who want to manage CI/CD workflows through chat (Hubot) rather than Jenkins UI. DevOps engineers and team leads who set up repositories and configure build notifications across multiple chat services.

Abandoned as of April 2022 per the README. The codebase has accumulated migrations dating back to 2011, suggesting it was production-used for ~11 years, but is no longer maintained. Last commit appears stale; this should be treated as legacy/reference code only, not for new deployments.

Critical risk: repo is officially deprecated and unmaintained since April 2022, so no security patches or bug fixes will be applied. Dependencies are likely outdated (Ruby, gems, Jenkins plugins). Deployment to Heroku is mentioned but may break with platform changes. No visible test suite in file list suggests low test coverage.

Nothing—repo is archived and unmaintained since April 2022. No active development, PRs, or issues being worked on.

Clone the repo, install Ruby dependencies, and start via Docker: git clone https://github.com/github/janky && cd janky && docker-compose up. Alternatively, bundle install && rackup config.ru to run the Rack app locally, but requires a running Jenkins instance and environment config (DATABASE_URL, GitHub OAuth tokens, chat service credentials).

Daily commands: docker-compose up (requires Docker); or locally: bundle install, set environment variables (DATABASE_URL, GITHUB_OAUTH_TOKEN, JENKINS_URL, chat service creds), run rackup config.ru on port 9292, and ensure Jenkins server is accessible.

• lib/janky/app.rb: Main Rack app entry point; contains web routes for status pages, GitHub webhook receiver, and Jenkins callback handler
• lib/janky/builder/client.rb: Abstracts Jenkins HTTP client; core bridge between Janky and Jenkins for triggering builds and fetching status
• lib/janky/builder/receiver.rb: Handles GitHub webhook payloads; parses push events and creates build requests
• lib/janky/chat_service.rb: Base class defining interface for all chat service implementations (Slack, HipChat, Campfire, Hubot)
• lib/janky/database/migrate/: Schema evolution; 15+ migrations show core data model (repos, branches, builds, commits, queued_at timestamps)
• config.ru: Rack app loader; minimal entry point that mounts lib/janky/app.rb
• docker-compose.yml: Orchestrates Janky app container + Jenkins container; shows expected architecture for local dev and deployment

To add a new chat service: create lib/janky/chat_service/newservice.rb following the interface in lib/janky/chat_service.rb. To change Jenkins interaction: edit lib/janky/builder/http.rb or lib/janky/builder/payload.rb. For database schema: add migration to lib/janky/database/migrate/ with timestamp prefix. Web UI routes are in lib/janky/app.rb. Hubot commands are likely in a separate Hubot script (not visible in file list).

Jenkins URL must be configured in Jenkins UI itself (/configure) else builds won't report status back. GitHub webhooks must be created by the ci setup Hubot command—manual webhook creation is not supported. Database migrations are timestamped (not sequential); order matters and must be run in migration order. Environment variables required: DATABASE_URL, GITHUB_OAUTH_TOKEN, JENKINS_URL, plus chat service credentials (SLACK_TOKEN, HIPCHAT_API_TOKEN, etc.). No visible env.example file—check README or docker-compose.yml for all required vars. Heroku deployment mentioned but repo is archived; buildpack and Procfile likely missing.

• GitHub Webhooks — Janky's entire triggering mechanism relies on GitHub calling back to lib/janky/builder/receiver.rb on push events; understanding the webhook payload format and signature validation is essential
• Jenkins Remote Trigger API — lib/janky/builder/http.rb calls Jenkins via HTTP to trigger builds and fetch job status; requires knowledge of Jenkins' parameterized build and API authentication
• Rack Protocol — Janky is a Rack app (config.ru); understanding Rack's request/response cycle is needed to modify routes and middleware in lib/janky/app.rb
• Database Migrations (Sequel) — All schema changes go through timestamped migration files in lib/janky/database/migrate/; must understand how Sequel ORM orders and applies migrations
• OAuth 2.0 / GitHub API Authentication — Janky authenticates with GitHub via GITHUB_OAUTH_TOKEN to fetch org membership for access control and create webhooks; implicit in lib/janky/app.rb
• Strategy Pattern (Chat Adapters) — lib/janky/chat_service/ implements Strategy pattern with swappable backends (Slack, HipChat, Campfire); understanding this pattern helps add new notification channels
• Build Queue / Asynchronous Job Dispatch — lib/janky/build_request.rb and lib/janky/builder/runner.rb queue builds and manage async execution; understanding queueing prevents race conditions when multiple pushes hit simultaneously

• github/hubot — Janky is controlled entirely through Hubot chat commands; Hubot is the peer system for command interface
• jenkinsci/jenkins — Janky wraps Jenkins; understanding Jenkins architecture and plugin ecosystem (Notification Plugin) is required
• hashicorp/vagrant — Similar era DevOps automation tool for teams; represents alternative approach to CI/CD orchestration pre-Kubernetes
• buildkite/buildkite-agent — Modern successor to Janky's problem space—provides chat-integrated CI without Jenkins complexity
• github/actions — GitHub Actions is the native GitHub replacement for Janky's webhook + CI automation pattern

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for lib/janky/builder/payload.rb

The payload.rb file is critical for transforming build requests into Jenkins-compatible payloads, but there are no visible test files in the repo structure for builder modules. This is a high-risk area since payload construction directly affects CI reliability. Adding tests would ensure payload formatting works correctly across different build scenarios and prevent regressions.

• [ ] Create spec/janky/builder/payload_spec.rb with tests for payload initialization and transformation
• [ ] Add test cases for different repository types and build configurations
• [ ] Test edge cases like missing fields, special characters in commit messages, and various GitHub webhook payloads
• [ ] Verify tests pass with rake test or equivalent test runner defined in Rakefile

Add integration tests for lib/janky/github/payload_parser.rb

The payload_parser.rb is the entry point for GitHub webhook handling and is critical for CI triggering. Without visible tests, there's risk of breaking webhook parsing for different GitHub event types (push, pull_request, etc.). Integration tests would validate that the parser correctly handles various GitHub webhook formats and edge cases.

• [ ] Create spec/janky/github/payload_parser_spec.rb with tests for various GitHub webhook event types
• [ ] Add test fixtures in spec/fixtures/ for real GitHub webhook payloads (push, PR, release events)
• [ ] Test error handling for malformed or unexpected webhook payloads
• [ ] Verify payload parsing correctly extracts branch, commit, author, and repository information

Add GitHub Actions workflow to automate testing and Docker image building

The repo has .travis.yml (outdated CI service) but the project is archived. Adding a modern GitHub Actions workflow would help future maintainers or forks validate changes. The presence of Dockerfile and docker-compose.yml suggests Docker is important to the project workflow, but there's no automated image building or testing pipeline documented.

• [ ] Create .github/workflows/test.yml that runs Ruby tests against multiple versions
• [ ] Add .github/workflows/docker-build.yml to build and test the Docker image on PR/push
• [ ] Include steps to run rake test and validate docker-compose.yml configurations
• [ ] Document in CONTRIBUTING.md that PRs should pass GitHub Actions checks before merging

• Write integration tests for lib/janky/builder/http.rb—no test files visible in repo, but this is critical for Jenkins communication. Start by mocking HTTP responses and testing build trigger and status fetch.
• Document the GitHub webhook payload format and expected fields in lib/janky/builder/receiver.rb—currently no inline docs. Add docstrings explaining how push, pull_request, and ping events are handled.
• Add missing chat service implementations or improve existing ones: lib/janky/chat_service/mock.rb is stubbed but other services lack error handling. Add retry logic and timeout handling for Slack/HipChat API calls.

• Critical · Outdated Ruby Version with Known Vulnerabilities — Dockerfile (line 1: FROM ruby:2.4). The Dockerfile uses Ruby 2.4, which reached end-of-life in March 2019 and contains numerous known security vulnerabilities. Ruby 2.4 no longer receives security patches. Fix: Upgrade to Ruby 2.7 or later (ideally 3.1+). Rebuild the Docker image with a supported Ruby version.
• Critical · Empty Database Password Configuration — docker-compose.yml (line 7: MYSQL_ALLOW_EMPTY_PASSWORD: 1). The docker-compose.yml explicitly sets MYSQL_ALLOW_EMPTY_PASSWORD=1, allowing the MySQL database to run without any password authentication. This exposes the database to unauthorized access. Fix: Remove the empty password configuration. Set a strong MYSQL_ROOT_PASSWORD and create database-specific credentials for the application.
• High · Missing Security Headers Configuration — lib/janky/app.rb and related Sinatra configuration. The Sinatra-based web application (lib/janky/app.rb) likely lacks proper security headers (CSP, X-Frame-Options, X-Content-Type-Options, etc.) to mitigate XSS, clickjacking, and MIME-sniffing attacks. Fix: Implement security middleware to add HTTP security headers. Consider using gems like 'secure_headers' or manually configure CSP, X-Frame-Options, X-XSS-Protection, etc.
• High · Insecure HTTP Repository Configuration — Dockerfile (line 8: echo 'deb http://repo.mysql.com/apt/debian/ jessie mysql-5.7'). The docker-compose.yml and Dockerfile reference HTTP repositories for package management (http://repo.mysql.com/apt/debian/). Using unencrypted HTTP for package downloads increases risk of man-in-the-middle attacks. Fix: Change HTTP to HTTPS: 'deb https://repo.mysql.com/apt/debian/ jessie mysql-5.7'. Verify GPG signatures of downloaded packages.
• High · Jenkins CLI Port Exposed Without Authentication — docker-compose.yml (Jenkins service) and docker/jenkins/Dockerfile. The repository includes docker/jenkins/disable-cli.groovy but there's no evidence it's properly enforced. Jenkins instances typically expose ports that could allow remote code execution if CLI access is enabled. Fix: Verify Jenkins CLI is disabled and ensure the Jenkins instance only exposes HTTPS ports with proper authentication. Restrict Jenkins network access within docker-compose.
• High · No HTTPS Configuration for Web Application — Dockerfile (EXPOSE 9393) and docker-compose.yml (ports: 9393:9393). The application exposes port 9393 without evidence of HTTPS/TLS configuration. Sensitive CI/CD data, build logs, and authentication tokens are transmitted over unencrypted HTTP. Fix: Configure TLS/SSL for the Sinatra application. Use a reverse proxy (nginx/HAProxy) with SSL certificates, or configure Sinatra with TLS directly. Never expose HTTP for production.
• Medium · Potential SQL Injection in Database Queries — lib/janky/database/schema.rb, lib/janky/build.rb, lib/janky/repository.rb. The codebase includes multiple database migration and query files. Without visibility of the full implementation in lib/janky/build.rb, lib/janky/repository.rb, and database operations, there's risk of SQL injection if queries aren't properly parameterized. Fix: Ensure all database queries use parameterized statements or ORM methods that prevent SQL injection. Review all raw SQL queries and replace with prepared statements.
• Medium · Potential XSS Vulnerabilities in Mustache Templates — lib/janky/templates/console.mustache and lib/janky/templates/index.mustache. The application uses Mustache templates (lib/janky/templates/console.mustache, index.mustache) to render content. If user-controlled data is rendered without proper escaping, XSS attacks are possible. Fix: Ensure all user-controlled data is properly escaped in templates. Use

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.