Add explicit read-only validation of the remote sync path#5944
Draft
pietern wants to merge 1 commit into
Draft
Conversation
Contributor
Approval status: pending
|
Collaborator
Integration test reportCommit: eeb68e3
8 interesting tests: 4 RECOVERED, 4 SKIP
Top 10 slowest tests (at least 2 minutes):
|
pietern
marked this pull request as draft
July 16, 2026 12:30
pietern
force-pushed
the
validate-ensure-remote-path
branch
from
July 16, 2026 12:33
a52656b to
f1a5fcb
Compare
bundle validate currently checks that workspace.file_path is a usable remote destination only as a side effect of building a file syncer: FilesToSync -> files.GetSync -> sync.New, whose constructor calls EnsureRemotePathIsUsable. That call also creates the directory as a side effect, which is undesirable from a read-only validator. An upcoming refactor centralizes the sync file-list computation and stops constructing a syncer during validation, which would silently drop this destination check. Extract it into an explicit, read-only ValidateRemoteFilePath validator that calls EnsureRemotePathIsUsable with dryRun=true, so the path is asserted to be a directory/repo without creating it. Wire it into the slow Validate() set. sync.New is intentionally left untouched, so bundle deploy and the sync commands keep creating the remote directory as before. During this transition bundle validate reports the destination error twice (once from this validator, once from FilesToSync via sync.New); a follow-up PR removes the check from sync.New by moving it to the syncer launch path. Co-authored-by: Isaac
pietern
force-pushed
the
validate-ensure-remote-path
branch
from
July 16, 2026 13:28
f1a5fcb to
eeb68e3
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
bundle validatevalidates the remoteworkspace.file_pathonly incidentally, via thesync.Newconstructor'sEnsureRemotePathIsUsablecall, which also creates the directory as a side effect. An upcoming refactor centralizes the sync file-list computation and stops constructing a syncer during validation, which would silently drop this check. This PR extracts the check into an explicit, read-onlyValidateRemoteFilePathvalidator (using the existingEnsureRemotePathIsUsablewithdryRun=true, so no directory is created), wired intobundle validate. Behavior forbundle deployand thesynccommands is unchanged.What
ValidateRemoteFilePath(bundle.RO) inbundle/config/validate/, checking onlyworkspace.file_path. It callssync.EnsureRemotePathIsUsable(..., dryRun=true)— the single source of truth shared with deploy — so there is nomkdirside effect. It skips when there are no sync paths (mirroringFilesToSync) or whenfile_pathis empty.Validate()set alongsideFilesToSync().diag.Errorwith the path; no-sync-paths → skip. NoMkdirsByPathexpectation is set, so an unexpected mutating call fails the test (proves the dry run).acceptance/bundle/validate/remote_file_path/.Scope / transition
This is deliberately single-purpose.
sync.New,FilesToSync,files.GetSync, andEnsureRemotePathIsUsable's implementation are intentionally not modified, sobundle deployand thesynccommands keep creating the remote directory as before.During this transition
bundle validatereports the destination error twice for a bad path — once from the new validator (with a location), once fromFilesToSyncviasync.New. This is the accepted, brief redundancy. A follow-up PR removes the check fromsync.Newby movingEnsureRemotePathIsUsable(dryRun=false)to the syncer launch path (RunOnce/RunContinuous), which covers deploy/sync/bundle-sync (all of which construct-then-launch) while making sync construction free of remote calls.Note on the acceptance test
bundle validateruns its slow validators in parallel (bundle.ApplyParallel) and streams diagnostics in completion order, so full output is not deterministically ordered when multiple validators emit. The test captures full output to aLOG.validatefile (excluded from the golden) and asserts a sorted projection of the diagnostic lines, so it is stable.This pull request and its description were written by Isaac.