mirror of
https://github.com/OpenHands/OpenHands.git
synced 2026-10-07 16:08:23 +08:00
Require Helm and (pending) Replicated install testing in the bug bash
Checklist item 3 ("gated by ENABLE_<FEATURE> and exposed through Helm /
embedded-cluster configuration") only checked that the flag and Helm
wiring exist in code, not that anyone had actually installed the
feature and exercised it that way. This closes that gap by requiring
real install testing during the mandatory bug bash, where 3+ people
and an environment are already required.
- repos.yml: add a capabilities block (helm_preview_supported: true,
replicated_preview_supported: false) so automations read one flag
instead of hardcoding whether Replicated testing is required yet.
- linear/feature-landing-issue-template.md: bug-bash evidence line now
requires a helm-test field (always) and a replicated-test field
(real evidence once the capability flag flips, n/a-pending-support
until then).
- automations/04-bug-bash-reminder.md, 05-bug-bash-gate.md: the
requested/validated bug-bash-report format now includes both
helm-test and replicated-test fields, with 05's validation reading
the capabilities flag to decide whether replicated-test must be real
evidence.
- linear/state-machine.md, tracker-format.md, PLAN.md,
automations/README.md, PULL_REQUEST_TEMPLATE_snippet.md: propagate
the same requirement through the state-machine transition
description, tracker rendering examples, and PR template notes.
Referenced OpenHands/enterprise#92 (the SaaS-side feature-preview
skill) as the closest existing precedent, and noted that no equivalent
self-hosted Helm/Replicated preview tooling exists yet — bug-bash
participants currently install by hand.
Co-authored-by: openhands <openhands@all-hands.dev>
This commit is contained in:
openhands
@@ -121,6 +121,34 @@ Enterprise feature merge
|
||||
|
||||
A release tag, image, or chart PR by itself is not sufficient.
|
||||
|
||||
## Self-hosted install testing during the bug bash
|
||||
|
||||
Checklist item 3 (flag + Helm/embedded-cluster wiring) is a pre-merge code
|
||||
check: it confirms the wiring exists, not that anyone has actually installed
|
||||
and exercised the feature that way. Real install testing happens during the
|
||||
mandatory bug bash instead, where 3+ people and a real environment are
|
||||
already required:
|
||||
|
||||
- **Helm install test — required today.** A bug bash is not valid without a
|
||||
non-empty `helm-test:` field in its `bug-bash-report`, recording a real
|
||||
Helm-based install (against `OpenHands/OpenHands-Cloud`'s
|
||||
`charts/openhands` chart) with the flag turned on.
|
||||
- **Replicated / embedded-cluster install test — required once that
|
||||
capability ships.** `repos.yml`'s `capabilities.replicated_preview_supported`
|
||||
gates this: while `false`, `n/a-pending-support` is accepted for the
|
||||
`replicated-test:` field; once flipped to `true`, a real note/link is
|
||||
required, same as `helm-test`.
|
||||
|
||||
There is currently no scripted or documented equivalent, for either Helm or
|
||||
Replicated, of the SaaS-side feature-preview flow that
|
||||
`OpenHands/enterprise#92` added (which spins up a `saas-deploy` staging
|
||||
namespace via ArgoCD's PR-generator ApplicationSet — a different mechanism
|
||||
from a self-hosted Helm or Replicated install). Until an equivalent
|
||||
self-hosted preview tool exists, bug-bash participants stand up and tear down
|
||||
Helm installs by hand; this is a known gap worth closing with tooling similar
|
||||
in spirit to `enterprise#92`'s preview-environment skill, scoped to
|
||||
self-hosted rather than SaaS.
|
||||
|
||||
## Hidden documentation lifecycle
|
||||
|
||||
Feature documentation is checked into `OpenHands/docs` during development with
|
||||
@@ -148,6 +176,9 @@ See `docs-visibility.md` for details.
|
||||
- Enterprise-specific production release detection in Automation 3.
|
||||
- Post-release evidence checks for real docs, E2E coverage, self-hosted wiring,
|
||||
bug-bash completion, release availability, and social launch URL.
|
||||
- Explicit Helm install-test requirement (and a Replicated install-test
|
||||
requirement, gated behind a `repos.yml` capability flag) wired into the
|
||||
bug-bash report format and Automation 5's validation.
|
||||
- Hidden-doc verification and reveal lifecycle.
|
||||
|
||||
Nothing is deployed, committed, or pushed from this workspace yet.
|
||||
|
||||
@@ -16,9 +16,11 @@ _Required before merge:_
|
||||
_(add the page to `OpenHands/docs`, but set `hidden: true` in its frontmatter — the feature isn't public yet. Automation removes `hidden: true` only after two tech-council approvals and independent verification that the flag is enabled in production.)_
|
||||
- [ ] E2E test added covering regression / up-to-spec behavior
|
||||
- [ ] Feature is gated by an ENABLE_<FEATURE> flag and exposed through the appropriate Helm / embedded-cluster configuration
|
||||
_(this checks the flag and Helm/embedded-cluster wiring exist in code; the mandatory bug bash below independently tests a real Helm install — and, once that capability ships, a Replicated/embedded-cluster install — with the flag ON.)_
|
||||
|
||||
_Tracked post-merge (do not check manually — automation updates these):_
|
||||
- [ ] Bug bash completed (3+ engineers), issues filed for next cycle
|
||||
_(must include a Helm-based install test of the feature with the flag ON; a Replicated/embedded-cluster install test is also required once `repos.yml`'s `capabilities.replicated_preview_supported` is true. Automation 5 checks for `helm-test:`/`replicated-test:` fields in the bug-bash report.)_
|
||||
- [ ] Feature is available in the most recent release
|
||||
- [ ] Feature included in an X / LinkedIn post
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ curl -X POST "${OPENHANDS_HOST}/api/automation/v1/preset/prompt" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"name": "Landing: Bug Bash Reminder",
|
||||
"prompt": "Find every Linear issue in the '\''Feature Launches'\'' project with label stage:in-prod.\n\nFor issues that have been in this stage for 3+ business days with no bug-bash sub-issues yet created:\n1. Add label stage:bug-bash-pending.\n2. Post a friendly comment @-mentioning the assignee (the original PR author — they are always the bug-bash DRI per team process, no rotation), asking them to schedule a bug bash with 3+ team members within the next week, file every issue found as a child of this ticket, and add a structured completion comment in the exact format '\''bug-bash-report: <date> | attendees: <three or more distinct Linear users> | issues: <zero or child issue IDs>'\''. A zero-issue bash still needs the report.\n3. Update the DRI/due-date detail line on the PR'\''s Feature Landing Tracker comment (marker '\''<!-- landing-tracker:v1 -->'\'', GITHUB_TOKEN, PATCH the existing comment — the 8-stage bar itself does not change here, still '\''🔄 Bug Bash'\'') to note the reminder was sent and a bug bash is now pending scheduling. Fetch landing-checklist/tracker-format.md from OpenHands/OpenHands (raw, main) for exact formatting.\n4. Read the '\''slack-thread: <channel>/<ts>'\'' comment left on this Linear issue by the Prod Tracker automation, and post a threaded reply (chat.postMessage with that thread_ts, SLACK_BOT_TOKEN secret) to #tech-council noting the bug-bash reminder just went out to the DRI, per tracker-format.md'\''s lighter in-thread-reply format (a single section block, not the full block set). If no slack-thread comment is found, skip the Slack reply and note that in your summary (the Prod Tracker automation may not have run yet for this issue).\n\nFor issues already labeled stage:bug-bash-pending:\n- Check whether the assignee has since created child issues OR added a bug-bash-report comment. If either exists, treat the bash as scheduled/underway: move the label to stage:bug-bash-active and stop reminding. Automation 5 validates the report and completion.\n- If it has been 2+ weeks since the reminder with neither child issues nor a bug-bash-report, escalate by posting an in-thread Slack reply to #tech-council (same thread_ts lookup as above) tagging the DRI'\''s manager if known, otherwise just the DRI, and noting the escalation in the tracker comment'\''s detail line too.\n\nEnd every human-facing GitHub, Linear, or Slack body you create with: '\''_Automated by an OpenHands AI agent on behalf of the engineering team._'\''\n\nSummarize how many issues were reminded, escalated, and moved to bug-bash-active.",
|
||||
"prompt": "Find every Linear issue in the '\''Feature Launches'\'' project with label stage:in-prod.\n\nFor issues that have been in this stage for 3+ business days with no bug-bash sub-issues yet created:\n1. Add label stage:bug-bash-pending.\n2. Post a friendly comment @-mentioning the assignee (the original PR author — they are always the bug-bash DRI per team process, no rotation), asking them to schedule a bug bash with 3+ team members within the next week, file every issue found as a child of this ticket, and add a structured completion comment in the exact format '\''bug-bash-report: <date> | attendees: <three or more distinct Linear users> | issues: <zero or child issue IDs> | helm-test: <note/link confirming a real Helm-based install test of the feature with the flag ON> | replicated-test: <note/link confirming a Replicated/embedded-cluster install test with the flag ON, or n/a-pending-support if that capability is not yet available>'\''. Read repos.yml'\''s capabilities.replicated_preview_supported to tell the DRI whether replicated-test must be a real test or n/a-pending-support is acceptable. A zero-issue bash still needs the report, including both test fields.\n3. Update the DRI/due-date detail line on the PR'\''s Feature Landing Tracker comment (marker '\''<!-- landing-tracker:v1 -->'\'', GITHUB_TOKEN, PATCH the existing comment — the 8-stage bar itself does not change here, still '\''🔄 Bug Bash'\'') to note the reminder was sent and a bug bash is now pending scheduling. Fetch landing-checklist/tracker-format.md from OpenHands/OpenHands (raw, main) for exact formatting.\n4. Read the '\''slack-thread: <channel>/<ts>'\'' comment left on this Linear issue by the Prod Tracker automation, and post a threaded reply (chat.postMessage with that thread_ts, SLACK_BOT_TOKEN secret) to #tech-council noting the bug-bash reminder just went out to the DRI, per tracker-format.md'\''s lighter in-thread-reply format (a single section block, not the full block set). If no slack-thread comment is found, skip the Slack reply and note that in your summary (the Prod Tracker automation may not have run yet for this issue).\n\nFor issues already labeled stage:bug-bash-pending:\n- Check whether the assignee has since created child issues OR added a bug-bash-report comment. If either exists, treat the bash as scheduled/underway: move the label to stage:bug-bash-active and stop reminding. Automation 5 validates the report and completion.\n- If it has been 2+ weeks since the reminder with neither child issues nor a bug-bash-report, escalate by posting an in-thread Slack reply to #tech-council (same thread_ts lookup as above) tagging the DRI'\''s manager if known, otherwise just the DRI, and noting the escalation in the tracker comment'\''s detail line too.\n\nEnd every human-facing GitHub, Linear, or Slack body you create with: '\''_Automated by an OpenHands AI agent on behalf of the engineering team._'\''\n\nSummarize how many issues were reminded, escalated, and moved to bug-bash-active.",
|
||||
"trigger": {"type": "cron", "schedule": "0 15 * * 1-5", "timezone": "America/Los_Angeles"},
|
||||
"timeout": 600
|
||||
}'
|
||||
|
||||
@@ -1,6 +1,17 @@
|
||||
# Automation 5: Landing — Bug Bash Gate
|
||||
|
||||
**Trigger:** cron, daily.
|
||||
|
||||
**Install-test evidence:** the bug-bash report (Automation 4) must include a
|
||||
real Helm-based install test of the feature with the flag ON — this repo has
|
||||
no scripted equivalent yet of the SaaS-side feature-preview flow documented
|
||||
in `OpenHands/enterprise#92` (which spins up a `saas-deploy` staging
|
||||
namespace, not a self-hosted Helm/Replicated install), so bug-bash
|
||||
participants currently do this by hand against `OpenHands/OpenHands-Cloud`'s
|
||||
`charts/openhands` chart. A Replicated/embedded-cluster install test is also
|
||||
required once `repos.yml`'s `capabilities.replicated_preview_supported`
|
||||
flips to `true`; until then `n/a-pending-support` is accepted for that field.
|
||||
|
||||
**Slack:** posts the "please review" ask in-thread to `#tech-council`
|
||||
(confirmed channel name). This is the one message in the whole flow phrased
|
||||
as a direct request rather than a status update — see `tracker-format.md`.
|
||||
@@ -15,7 +26,7 @@ curl -X POST "${OPENHANDS_HOST}/api/automation/v1/preset/prompt" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"name": "Landing: Bug Bash Gate",
|
||||
"prompt": "Find every Linear issue in the '\''Feature Launches'\'' project with label stage:bug-bash-active. For each one, list its child issues and read its latest bug-bash-report comment. Validate that the report names at least three distinct human team members and that the issues field is either zero or matches the filed child issues. A child issue counts as cleared when it is Done/Canceled OR explicitly labeled landing:deferred with a target next-cycle project/cycle recorded; an unlabeled open issue is not clear.\n\nIf the bug-bash report is valid and every child issue is cleared (the bug-bash punch list is clear) AND checklist items 1-5 are checked with evidence recorded by Automation 3 / the bug bash:\n1. Resolve the original PR author to a Slack user by reading the Linear assignee email and calling users.lookupByEmail. If no unique active Slack user is found, fail closed: leave stage:bug-bash-active and post a deduplicated identity-mapping reminder instead of requesting approval. Stop processing this feature before any other side effects if identity mapping fails.\n2. Post a summary comment listing how many bugs were found, how many were fixed vs deferred to next cycle (deferred ones should already be separately labeled/moved by the assignee — just report the count, do not re-triage them yourself). Do not change the stage yet.\n3. Update the PR'\''s Feature Landing Tracker comment (marker '\''<!-- landing-tracker:v1 -->'\'', GITHUB_TOKEN, PATCH the existing comment) so the 8-stage bar reads '\''✅ Review → ✅ Merged → ✅ In Prod → ✅ Bug Bash → 🔄 Council Review → ⬜ Council Approved → ⬜ Flag On → ⬜ GA'\'', the release/bug-bash checklist items are ticked, and the current-stage line says it'\''s awaiting tech-council sign-off. Fetch landing-checklist/tracker-format.md from OpenHands/OpenHands (raw, main) for exact formatting.\n4. First check whether one Linear comment already contains both machine-readable marker lines described below. If it does, reuse that approval message and do not post a duplicate. Otherwise, read the '\''slack-thread: <channel>/<ts>'\'' comment on this Linear issue (left by the Prod Tracker automation) and post a threaded reply to #tech-council (chat.postMessage with that thread_ts, SLACK_BOT_TOKEN secret) summarizing the bug-bash results (bugs found/fixed/deferred) and its ENABLE_<FEATURE> flag name. Phrase it as an explicit approval request and include this exact sentence immediately before the required AI disclosure: '\''Council members: react ✅ to approve or 🚫 to block. Two distinct human approvals are required; reactions from the original PR author do not count, and any blocking reaction wins until removed.'\'' If no slack-thread comment is found on the Linear issue, post a new top-level message to #tech-council instead (following the full Block Kit template in tracker-format.md) and record its channel+ts as a '\''slack-thread: ...'\'' comment on the Linear issue. In either case, capture the approval request response'\''s own channel and ts, then add a separate Linear comment containing both exact machine-readable lines '\''council-approval-message: <channel-id>/<message-ts>'\'' and '\''council-pr-author-slack-user: <slack-user-id>'\''. Automation 6 counts reactions only on that exact approval message, not on the thread starter or other replies, and excludes that Slack user from both approval and blocking votes.\n5. Only after the tracker, Slack request, and both machine-readable marker lines are confirmed, replace stage:bug-bash-active with stage:council-review.\n\nIf the report is missing/invalid or any child issue is not cleared by the rule above, leave stage:bug-bash-active and post at most one deduplicated reminder describing the exact gap. If the report and bug-bash list are clear but any of checklist items 1-5 lacks evidence, do not request council approval: leave stage:bug-bash-active, add one Linear comment listing the missing evidence, and update the existing Slack thread and PR tracker without creating a council-approval-message marker.\n\nEnd every human-facing GitHub, Linear, or Slack body you create with: '\''_Automated by an OpenHands AI agent on behalf of the engineering team._'\''\n\nSummarize how many issues were checked and how many moved to stage:council-review.",
|
||||
"prompt": "Find every Linear issue in the '\''Feature Launches'\'' project with label stage:bug-bash-active. For each one, list its child issues and read its latest bug-bash-report comment. Validate that the report names at least three distinct human team members and that the issues field is either zero or matches the filed child issues. A child issue counts as cleared when it is Done/Canceled OR explicitly labeled landing:deferred with a target next-cycle project/cycle recorded; an unlabeled open issue is not clear. Also validate the two install-test fields: helm-test must be present and non-empty (a real note or link, not a placeholder). For replicated-test, first read repos.yml'\''s capabilities.replicated_preview_supported: if false, either a real note/link or the literal n/a-pending-support is acceptable; if true, a real note/link is required and n/a-pending-support is no longer acceptable. Treat a report missing helm-test, or missing/insufficient replicated-test per that rule, as an invalid report — same remediation path as a missing attendee count.\n\nIf the bug-bash report is valid and every child issue is cleared (the bug-bash punch list is clear) AND checklist items 1-5 are checked with evidence recorded by Automation 3 / the bug bash:\n1. Resolve the original PR author to a Slack user by reading the Linear assignee email and calling users.lookupByEmail. If no unique active Slack user is found, fail closed: leave stage:bug-bash-active and post a deduplicated identity-mapping reminder instead of requesting approval. Stop processing this feature before any other side effects if identity mapping fails.\n2. Post a summary comment listing how many bugs were found, how many were fixed vs deferred to next cycle (deferred ones should already be separately labeled/moved by the assignee — just report the count, do not re-triage them yourself). Do not change the stage yet.\n3. Update the PR'\''s Feature Landing Tracker comment (marker '\''<!-- landing-tracker:v1 -->'\'', GITHUB_TOKEN, PATCH the existing comment) so the 8-stage bar reads '\''✅ Review → ✅ Merged → ✅ In Prod → ✅ Bug Bash → 🔄 Council Review → ⬜ Council Approved → ⬜ Flag On → ⬜ GA'\'', the release/bug-bash checklist items are ticked, and the current-stage line says it'\''s awaiting tech-council sign-off. Fetch landing-checklist/tracker-format.md from OpenHands/OpenHands (raw, main) for exact formatting.\n4. First check whether one Linear comment already contains both machine-readable marker lines described below. If it does, reuse that approval message and do not post a duplicate. Otherwise, read the '\''slack-thread: <channel>/<ts>'\'' comment on this Linear issue (left by the Prod Tracker automation) and post a threaded reply to #tech-council (chat.postMessage with that thread_ts, SLACK_BOT_TOKEN secret) summarizing the bug-bash results (bugs found/fixed/deferred) and its ENABLE_<FEATURE> flag name. Phrase it as an explicit approval request and include this exact sentence immediately before the required AI disclosure: '\''Council members: react ✅ to approve or 🚫 to block. Two distinct human approvals are required; reactions from the original PR author do not count, and any blocking reaction wins until removed.'\'' If no slack-thread comment is found on the Linear issue, post a new top-level message to #tech-council instead (following the full Block Kit template in tracker-format.md) and record its channel+ts as a '\''slack-thread: ...'\'' comment on the Linear issue. In either case, capture the approval request response'\''s own channel and ts, then add a separate Linear comment containing both exact machine-readable lines '\''council-approval-message: <channel-id>/<message-ts>'\'' and '\''council-pr-author-slack-user: <slack-user-id>'\''. Automation 6 counts reactions only on that exact approval message, not on the thread starter or other replies, and excludes that Slack user from both approval and blocking votes.\n5. Only after the tracker, Slack request, and both machine-readable marker lines are confirmed, replace stage:bug-bash-active with stage:council-review.\n\nIf the report is missing/invalid or any child issue is not cleared by the rule above, leave stage:bug-bash-active and post at most one deduplicated reminder describing the exact gap. If the report and bug-bash list are clear but any of checklist items 1-5 lacks evidence, do not request council approval: leave stage:bug-bash-active, add one Linear comment listing the missing evidence, and update the existing Slack thread and PR tracker without creating a council-approval-message marker.\n\nEnd every human-facing GitHub, Linear, or Slack body you create with: '\''_Automated by an OpenHands AI agent on behalf of the engineering team._'\''\n\nSummarize how many issues were checked and how many moved to stage:council-review.",
|
||||
"trigger": {"type": "cron", "schedule": "0 15 * * 1-5", "timezone": "America/Los_Angeles"},
|
||||
"timeout": 600
|
||||
}'
|
||||
|
||||
@@ -80,9 +80,22 @@ and feature flags currently live in `frontend/src/utils/feature-flags.ts`.
|
||||
`stage:flag-on`.
|
||||
- Central artifacts live in `OpenHands/OpenHands` under
|
||||
`.github/landing-checklist/` and `.github/workflows/`.
|
||||
- The bug bash must include a real Helm install test of the feature with the
|
||||
flag ON (`helm-test:` field in the bug-bash report, always required). A
|
||||
Replicated/embedded-cluster install test is also required once
|
||||
`repos.yml`'s `capabilities.replicated_preview_supported` flips to `true`;
|
||||
until then, `n/a-pending-support` is accepted for `replicated-test:`.
|
||||
|
||||
## Remaining implementation gap
|
||||
|
||||
No scripted or documented self-hosted preview mechanism exists yet for
|
||||
either Helm or Replicated/embedded-cluster install testing — unlike the
|
||||
SaaS-side feature-preview flow `OpenHands/enterprise#92` added (which spins
|
||||
up a `saas-deploy` staging namespace, a different, SaaS-only mechanism).
|
||||
Bug-bash participants currently install by hand; consider building an
|
||||
equivalent self-hosted preview skill before relying on this requirement at
|
||||
scale.
|
||||
|
||||
The production reconciler for this transition is not yet built:
|
||||
|
||||
```text
|
||||
|
||||
@@ -29,9 +29,15 @@ Use this body for the shared Linear `Feature Launches` issue template. Automatio
|
||||
independently verified flag-on.
|
||||
- E2E: test file and scenario that exercise the feature behavior.
|
||||
- Self-hosted: exact flag plus implementation and Helm / Replicated paths or
|
||||
linked downstream PRs.
|
||||
linked downstream PRs (code wiring, verified at review time).
|
||||
- Bug bash: `bug-bash-report: <date> | attendees: <three or more distinct
|
||||
Linear users> | issues: <zero or child issue IDs>`.
|
||||
Linear users> | issues: <zero or child issue IDs> | helm-test: <note or
|
||||
link confirming a real Helm-based install test with the flag ON> |
|
||||
replicated-test: <note or link confirming a real Replicated/embedded-cluster
|
||||
install test with the flag ON, or n/a-pending-support if repos.yml's
|
||||
capabilities.replicated_preview_supported is still false>`. The
|
||||
`helm-test` field is always required; `replicated-test` becomes required
|
||||
(not just `n/a-pending-support`) once that capability flag flips to true.
|
||||
- Release: release tag, image, chart, and production pin as applicable to the
|
||||
repository's rule in `repos.yml`.
|
||||
- Social: public `x.com`, `twitter.com`, or `linkedin.com` post URL.
|
||||
|
||||
@@ -52,7 +52,7 @@ issue rather than trying to reconstruct state from GitHub each time.
|
||||
| `stage:merged` | `stage:in-prod` | merge commit SHA found in production release/deploy | Automation 3 (cron) |
|
||||
| `stage:in-prod` | `stage:bug-bash-pending` | 3 business days elapsed with no bug bash scheduled | Automation 4 (cron) |
|
||||
| `stage:bug-bash-pending` | `stage:bug-bash-active` | child issues or structured `bug-bash-report` appears | Automation 4 (cron, next pass) |
|
||||
| `stage:bug-bash-active` | `stage:council-review` | valid 3+ attendee report, all findings fixed or explicitly moved to a named next cycle, checklist items 1-5 have evidence, and approval request is posted in `#tech-council` | Automation 5 (cron) |
|
||||
| `stage:bug-bash-active` | `stage:council-review` | valid 3+ attendee report (including Helm install-test evidence, and Replicated install-test evidence once that capability ships), all findings fixed or explicitly moved to a named next cycle, checklist items 1-5 have evidence, and approval request is posted in `#tech-council` | Automation 5 (cron) |
|
||||
| `stage:council-review` | `stage:council-approved` | two distinct human `#tech-council` members react `✅`, with no `🚫` from a channel member | Automation 6 (deterministic reaction poller) |
|
||||
| `stage:council-approved` | `stage:flag-on` | flag-enablement change independently confirmed in production | Production reconciler (not yet implemented) |
|
||||
| `stage:flag-on` | `stage:ga` | 3 months elapsed, flag removed in code, and supported public X/LinkedIn post URL recorded | Automation 7 (cron) |
|
||||
|
||||
@@ -16,6 +16,23 @@
|
||||
# 4. Done — no automation changes needed; automations resolve this file
|
||||
# at run time rather than hard-coding the list.
|
||||
|
||||
# Feature-preview / testing capabilities relevant to the landing checklist's
|
||||
# self-hosted item. Automations 4/5 read this instead of having a capability
|
||||
# hardcoded, so flipping one flag turns on the new requirement everywhere.
|
||||
capabilities:
|
||||
# Helm-based self-hosted install testing (against OpenHands/OpenHands-Cloud's
|
||||
# charts/openhands chart) is available today and is REQUIRED evidence in
|
||||
# every bug bash's structured report (see automations/04 and 05).
|
||||
helm_preview_supported: true
|
||||
# Embedded-cluster / Replicated install testing is not yet supported by any
|
||||
# documented or scripted preview mechanism (as opposed to the SaaS-side
|
||||
# feature-preview flow added in OpenHands/enterprise#92, which only covers
|
||||
# saas-deploy staging namespaces, not a self-hosted Replicated install).
|
||||
# Flip this to true once that capability ships; Automations 4/5 will then
|
||||
# require a non-empty `replicated-test:` field in the bug-bash report
|
||||
# instead of accepting `n/a-pending-support`.
|
||||
replicated_preview_supported: false
|
||||
|
||||
production_repos:
|
||||
- repo: OpenHands/OpenHands
|
||||
release_mechanism: github-release # tags like cloud-1.47.1; ships the
|
||||
|
||||
@@ -56,7 +56,9 @@ carries the pending-vs-active distinction.
|
||||
1. Docs added
|
||||
2. E2E test added
|
||||
3. Flag gated + exposed via Helm/embedded-installer
|
||||
4. Bug bash (3+ engineers)
|
||||
4. Bug bash (3+ engineers) — includes a real Helm install test with the
|
||||
flag ON, plus a Replicated/embedded-cluster install test once that
|
||||
capability ships (see `repos.yml`'s `capabilities` block)
|
||||
5. Available in most recent release
|
||||
6. Included in an X/LinkedIn post
|
||||
4. A **footer** cross-linking every surface: PR, Linear ticket, and (once
|
||||
@@ -89,7 +91,7 @@ Example comment body:
|
||||
- [x] Docs added for the feature on the website (hidden until flag-on - see docs-visibility.md)
|
||||
- [x] E2E test added covering regression / up-to-spec behavior
|
||||
- [x] Flag gated (`ENABLE_MY_FEATURE`) + exposed via Helm / embedded-installer
|
||||
- [ ] Bug bash (3+ engineers) - in progress, 2 issues open
|
||||
- [ ] Bug bash (3+ engineers) - in progress, 2 issues open (helm-test: pending, replicated-test: n/a-pending-support)
|
||||
- [x] Available in most recent release (`v1.7.0`, shipped 2026-06-10)
|
||||
- [ ] Included in an X / LinkedIn post
|
||||
|
||||
@@ -134,7 +136,7 @@ to reply in the same thread (every later automation). Requires a
|
||||
},
|
||||
{
|
||||
"type": "section",
|
||||
"text": { "type": "mrkdwn", "text": "*Checklist*\nDocs: done (hidden until flag-on)\nE2E test: done\nFlag + Helm/embedded-installer: done\nBug bash (3+ engineers): pending - 2 issues open\nAvailable in latest release: done (v1.7.0)\nX/LinkedIn post: pending" }
|
||||
"text": { "type": "mrkdwn", "text": "*Checklist*\nDocs: done (hidden until flag-on)\nE2E test: done\nFlag + Helm/embedded-installer: done\nBug bash (3+ engineers): pending - 2 issues open (helm-test pending, replicated-test n/a-pending-support)\nAvailable in latest release: done (v1.7.0)\nX/LinkedIn post: pending" }
|
||||
},
|
||||
{
|
||||
"type": "context",
|
||||
|
||||
Reference in New Issue
Block a user