🔄 refactor(release): sync main with dev/v1.6 for v1.6.0-rc.10 - #643
🔄 refactor(release): sync main with dev/v1.6 for v1.6.0-rc.10#643scttbnsn wants to merge 1 commit into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthroughThe PR replaces elapsed-time update-available deduplication with signature-based state tracking. It adds Docker warnings for narrow maintenance-window minute fields and updates related documentation. Update confirmation dialogs now show eligibility documentation links for soft blockers. Additional documentation covers Edge limitations, Portwing Exec sessions, key rotation, and sockguard configuration. Possibly related PRs
🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@content/docs/current/faq/index.mdx`:
- Around line 482-486: Update the FAQ entry “Why doesn't my edge agent apply
updates?” to state only that Edge Mode cannot execute proxied docker or
dockercompose update actions and that update execution is unsupported. Remove
the assertions that updates silently do nothing or never appear as available in
the UI, and retain the guidance to use a standard inbound HTTP agent for update
triggers.
In `@content/docs/current/guides/security/index.mdx`:
- Around line 96-97: Update the portwing-with-exec.yaml guidance in the security
documentation so it is not presented as a usable v1.6 deployment option;
describe it only as protocol-implementer or future-integration setup, or remove
the activation instructions until Drydock exposes an Exec caller. Preserve the
default preset’s denial of Exec and avoid implying that enabling the file
provides a supported product path.
In `@test/qa-compose.yml`:
- Around line 97-102: Update the maintenance-window comments near
DD_WATCHER_LOCAL_MAINTENANCE_WINDOW to clarify that Docker.init() performs an
immediate startup check and may poll until the window opens; explain that a
parked cron and WATCHEVENTS=false do not disable this evaluation. State that a
runnable DD_WATCHER_LOCAL_CRON is required only when testing later scheduled
checks, while preserving the UTC matching guidance.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: a4aef81c-32c6-47b6-a7a2-631eb88b7eca
⛔ Files ignored due to path filters (1)
CHANGELOG.mdis excluded by!CHANGELOG.md
📒 Files selected for processing (32)
app/configuration/index.test.tsapp/configuration/index.tsapp/event/audit-subscriptions.test.tsapp/event/audit-subscriptions.tsapp/watchers/providers/docker/Docker.containers.additional-coverage-core.test.tsapp/watchers/providers/docker/Docker.containers.additional-coverage-helpers.test.tsapp/watchers/providers/docker/Docker.containers.test.tsapp/watchers/providers/docker/Docker.events.test.tsapp/watchers/providers/docker/Docker.test.tsapp/watchers/providers/docker/Docker.tsapp/watchers/providers/docker/Docker.watch.test.tsapp/watchers/providers/docker/maintenance.test.tsapp/watchers/providers/docker/maintenance.tscontent/docs/current/api/portwing.mdxcontent/docs/current/configuration/actions/update-eligibility.mdxcontent/docs/current/configuration/agents/index.mdxcontent/docs/current/configuration/server/index.mdxcontent/docs/current/configuration/watchers/index.mdxcontent/docs/current/faq/index.mdxcontent/docs/current/getting-started/index.mdxcontent/docs/current/guides/security/index.mdxcontent/docs/current/monitoring/index.mdxtest/qa-compose.ymlui/src/components/ConfirmDialog.vueui/src/composables/useConfirmDialog.tsui/src/composables/useUpdateStatus.tsui/src/locales/en/containerComponents.jsonui/src/views/DashboardView.vueui/src/views/containers/useContainerActions.tsui/tests/components/ConfirmDialog.spec.tsui/tests/views/DashboardView.spec.tsui/tests/views/containers/useContainerActions.spec.ts
💤 Files with no reviewable changes (3)
- content/docs/current/configuration/server/index.mdx
- app/configuration/index.ts
- app/configuration/index.test.ts
| ## Why doesn't my edge agent apply updates? | ||
|
|
||
| An Edge (Portwing) agent only proxies discovery/watch state, continuous container logs, and container delete over its WebSocket tunnel — `docker` and `dockercompose` action triggers are not yet proxied over Edge Mode. If update actions on an edge-connected host silently do nothing, or never show up as available in the UI, that's expected behavior in v1.6, not a misconfiguration. | ||
|
|
||
| **Fix:** Configure update triggers on a standard (inbound HTTP) agent instead. See [Edge-agent dial-out (Portwing)](/docs/configuration/agents#edge-agent-dial-out-portwing) for exactly what Edge Mode does and doesn't proxy today. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Remove the claim that Edge trigger support controls update availability.
The missing trigger proxy prevents an update action from reaching the Edge agent. It does not establish that updates never appear as available in the UI. The agent documentation states that Edge Mode proxies discovery and watch state.
State that execution is unsupported. Do not connect that limitation to update availability unless the implementation also suppresses availability reporting.
As per path instructions, review documentation content for accuracy against code, not prose style.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@content/docs/current/faq/index.mdx` around lines 482 - 486, Update the FAQ
entry “Why doesn't my edge agent apply updates?” to state only that Edge Mode
cannot execute proxied docker or dockercompose update actions and that update
execution is unsupported. Remove the assertions that updates silently do nothing
or never appear as available in the UI, and retain the guidance to use a
standard inbound HTTP agent for update triggers.
Source: Path instructions
| sockguard also ships a separate [`portwing-with-exec.yaml`](https://github.com/CodesWhat/sockguard/blob/dev/v1.5/app/configs/portwing-with-exec.yaml) preset for deployments that need remote exec through the Edge agent (see the [exec session protocol](/docs/api/portwing#exec-session-protocol)). To activate it, replace the preset file the compose example mounts (swap `sockguard.yaml` for a copy of `portwing-with-exec.yaml`, or point the sockguard service's config mount at it) and restart sockguard — merely having the file present changes nothing, and the default preset above denies all exec. Exec authorization — privileged/root escalation and per-command allowlisting — is enforced by sockguard's exec policy, not by drydock. | ||
|
|
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Do not present Exec enablement as a usable v1.6 deployment option.
The Portwing API reference states that v1.6 has no end-user Exec UI or API, and that no product path opens a session. This instruction enables the Exec socket policy despite that limitation. It expands Docker API permissions without a usable Drydock feature.
Describe this preset as protocol-implementer or future-integration setup, or remove the activation guidance until Drydock exposes an Exec caller.
As per path instructions, review documentation content for accuracy against code, not prose style.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@content/docs/current/guides/security/index.mdx` around lines 96 - 97, Update
the portwing-with-exec.yaml guidance in the security documentation so it is not
presented as a usable v1.6 deployment option; describe it only as
protocol-implementer or future-integration setup, or remove the activation
instructions until Drydock exposes an Exec caller. Preserve the default preset’s
denial of Exec and avoid implying that enabling the file provides a supported
product path.
Source: Path instructions
| # To test: also set DD_WATCHER_LOCAL_CRON above to a runnable schedule | ||
| # (it's parked at `0 0 29 2 *` and WATCHEVENTS=false, so nothing | ||
| # reevaluates the window otherwise), then pick a UTC window that | ||
| # matches/misses the current time. | ||
| # Matched per minute, so keep `*` in the minute field for a real window. | ||
| # - DD_WATCHER_LOCAL_MAINTENANCE_WINDOW=* 2-6 * * * |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Correct the QA maintenance-window instructions.
Docker.init() always schedules a startup watchFromCron(). If that check is outside the window, it queues a check and polls until the window opens. A parked cron and WATCHEVENTS=false do not prevent maintenance-window evaluation.
State that a runnable cron is needed only to test later scheduled checks.
Proposed fix
- # To test: also set DD_WATCHER_LOCAL_CRON above to a runnable schedule
- # (it's parked at `0 0 29 2 *` and WATCHEVENTS=false, so nothing
- # reevaluates the window otherwise), then pick a UTC window that
- # matches/misses the current time.
+ # The startup check evaluates this window even though the scheduled cron
+ # is parked. If startup is outside the window, drydock queues a check
+ # and polls until the window opens. Set a runnable CRON only to test
+ # later scheduled checks, then pick a UTC window that matches or misses
+ # the current time.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # To test: also set DD_WATCHER_LOCAL_CRON above to a runnable schedule | |
| # (it's parked at `0 0 29 2 *` and WATCHEVENTS=false, so nothing | |
| # reevaluates the window otherwise), then pick a UTC window that | |
| # matches/misses the current time. | |
| # Matched per minute, so keep `*` in the minute field for a real window. | |
| # - DD_WATCHER_LOCAL_MAINTENANCE_WINDOW=* 2-6 * * * | |
| # The startup check evaluates this window even though the scheduled cron | |
| # is parked. If startup is outside the window, drydock queues a check | |
| # and polls until the window opens. Set a runnable CRON only to test | |
| # later scheduled checks, then pick a UTC window that matches or misses | |
| # the current time. | |
| # Matched per minute, so keep `*` in the minute field for a real window. | |
| # - DD_WATCHER_LOCAL_MAINTENANCE_WINDOW=* 2-6 * * * |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@test/qa-compose.yml` around lines 97 - 102, Update the maintenance-window
comments near DD_WATCHER_LOCAL_MAINTENANCE_WINDOW to clarify that Docker.init()
performs an immediate startup check and may poll until the window opens; explain
that a parked cron and WATCHEVENTS=false do not disable this evaluation. State
that a runnable DD_WATCHER_LOCAL_CRON is required only when testing later
scheduled checks, while preserving the UTC matching guidance.
|
Superseded by #648, which merged the final v1.6.0-rc.10 tree to main; v1.6.0-rc.10 has since been published from that sync. |
3 participants
Advances
mainto the exact tree ofdev/v1.6(49301617) ahead of the v1.6.0-rc.10 cut.Delta since rc.9:
* 2-6 * * *), update dialog wording documented (discussion What is maintenance window? #639)DD_AUDIT_UPDATE_AVAILABLE_DEDUPE_MSremovedWholesale-tree commit on top of
main(same pattern as #600/#603/#629/#634); tree equality is asserted by the release-cut drift guard.Changelog
update-availableaudit events to record only when the update signature changes or state resets.DD_AUDIT_UPDATE_AVAILABLE_DEDUPE_MSand its configuration helper.Concerns
hasNarrowMinuteFieldhandles all supported cron formats and invalid expressions consistently.