AI Decision System
Replayable, offline-verifiable records for AI-assisted go/no-go decisions: experiment promotions, typed model answers and human-approved actions.
翻译准备中
Upkeep is a maintenance orchestrator CLI for contributed Drupal modules.
翻译准备中
取自仓库 README
正在加载完整 README。 以下为已保存的摘录。
Upkeep is a maintenance orchestrator CLI for contributed Drupal modules. From
one "cockpit" directory it tracks every module you maintain across the Drupal
core versions you support, shows every open contribution with its CI and
local-check state on a single dashboard, runs each MR through a fully isolated
check flow (PHPUnit, PHPStan, PHPCS, install, smoke) in a disposable
per-module-per-core environment, and — for compat MRs that pass every gate —
offers a human-approved fast-lane merge.查看完整 README ↗Upkeep is a maintenance orchestrator CLI for contributed Drupal modules. From one "cockpit" directory it tracks every module you maintain across the Drupal core versions you support, shows every open contribution with its CI and local-check state on a single dashboard, runs each MR through a fully isolated check flow (PHPUnit, PHPStan, PHPCS, install, smoke) in a disposable per-module-per-core environment, and — for compat MRs that pass every gate — offers a human-approved fast-lane merge.
Environments are provisioned with ddev plus the ddev-drupal-contrib add-on (pinned at version 1.1.5) behind a thin adapter, and database fixtures come from the companion ddev-upkeep add-on. You never interact with either directly unless you want to.
# 1. Install
brew install owenbush/tap/upkeep # macOS; Linux/WSL2: grab the release archive
# 2. Scaffold a cockpit
upkeep init ~/my-cockpit && cd ~/my-cockpit
# 3. Build the base artifacts for a core version you maintain for
upkeep base-artifacts:build --version=11
# 4. Look at a module — any module, registered or not
upkeep issues pathauto
upkeep dashboard pathauto
Reading git.drupalcode.org needs no credential. A token is for writing: merging, commenting and publishing.
Getting started
| Install | Requirements, installing, shell completion |
| GitLab token | What needs a credential and what does not |
| Set up a cockpit | The registry, and what lives in a cockpit directory |
| Base artifacts | The per-core building blocks, pre-release core majors, rebuilding |
| Publishing: issue forks and SSH | How work reaches drupal.org |
Daily flow
| The dashboard | Everything open, and what a row represents |
| Work on an issue | issues → start → publish |
| Patch contributions | The work a merge-request view cannot see |
| Running checks | The isolated flow, and how it matches drupal.org CI |
| Review, merge and release notes | Looking at it, merging it, writing it up |
| Working in an environment | A shell, a path, a running site |
| Fixtures | Check against real database state |
Reference
| Command reference | Every command, generated from the CLI itself |
| Exit codes | The 0/1/2 contract |
| Disk housekeeping | Where the space goes, and reclaiming it |
| Upgrading a cockpit | What a version change expects |
Merges are one human approval per merge request, by Drupal Association policy.
There is deliberately no batch mode and no unattended merge path: merge
prompts per merge request and takes an answer, and nothing else in the tool
merges at all. A browser UI existed briefly and was removed, and the one action
worth a button was the one it deliberately never had — a button that POSTs an
action name is not the per-MR prompt that earns the approval. See
Review, merge and release notes.
MIT — see LICENSE.