Repository navigation
Production deploy logs still name a node address on the cluster-update summary line #4612
Description
🤖 Generated by the Agentic Engineer
Evidence
- fix(ci): mask the production API endpoint address for the rest of the job #4594 masks the production API endpoint address in deploy logs. Its own merge-queue deploy (run 37560566838, 2026-10-07) confirms that: the cluster-update summary line now shows the endpoint as
***, and no address followed by the API port appears anywhere in the 1,093-line deploy log. - The same summary line still ends by naming the address of the node the settings were read from. That is the only unmasked address left in that log (one line of 1,093).
- The line is printed on every successful production deploy, in a public repository's logs.
As on #4588 and #4591, the value is referred to only as a production node address. Please do not repeat it here, in the fix, or in any comment.
Audience and problem
Anyone can read these logs. A node's public address is less sensitive than the API endpoint, but it is still part of the cluster's layout that the earlier two fixes set out to keep out of public logs, and it is disclosed again on each deploy.
Hypothesis
Registering every production node address as a masked value at the point the endpoint is masked today closes this the same way, whichever tool prints one later.
Smallest useful change
Extend the existing masking step to cover the node addresses it can already read, with the same rule as before: the mask command only ever reaches the runner, never a file, summary or artifact.
Acceptance criteria
- A production deploy log contains no IPv4 address at all (checked on a real deploy, not only in a local test).
- The heal job and the manual deploy workflow are covered by the same step.
- If the summary line comes from KSail and can simply stop naming the node, a KSail issue is filed for that as the longer-term fix.
Metadata
Metadata
Assignees
Labels
Type
Fields
Projects
- Status
Activity
chore: agent-claim #4612 nonce=3452e66d5a1a7b2722cae47df2cc0cab
devantler commentedon Oct 7, 2026
Draft fix: #4615. Where the line comes from and what the fix covers:
The first acceptance criterion needs a real deploy, so it is checked after #4615 merges, on that merge's own deploy log.
devantler commentedon Oct 7, 2026
Verified on a real production deploy. #4615 merged at 07:59Z (
bdf93290); its own merge changed no manifests, so that merge ran no deploy. The next change through the queue did:bdf93290, finishedsuccess, ran the cluster update.Still open by design, as recorded on the pull request: a server created during the same deploy is not known when the mask step runs. devantler-tech/ksail#7594 (merged) fixes that at the source once production moves to a KSail release that includes it; devantler-tech/ksail#7595 covers the remaining error and create paths.