-
Notifications
You must be signed in to change notification settings - Fork 16
fix: accept comma-separated values on deployment target and scope flags #692
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft
NickJosevski
wants to merge
4
commits into
main
Choose a base branch
from
nj/issue-556
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
d25b40c
fix: accept comma-separated values on deployment target and scope flags
NickJosevski 8c07b92
refactor: collapse the duplicated comma-expansion block into one helper
NickJosevski c64ab93
fix: reject blank comma-separated values instead of silently dropping…
NickJosevski b77c149
fix: add a backslash escape hatch for commas in target and scope values
NickJosevski File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Altitude: the expansion lives in two run functions rather than the flag layer. Two costs:
tenant connect --environment/-e(pkg/cmd/tenant/connect/connect.go:108) still does not split commas, so-e "dev,test"works onrelease deploybut sends the literal string ontenant connect.flags.X.Valueat the top of the run function creates an ordering dependency — any future code reading these flags inPreRunEor before these lines sees unsplit values, and every new command must remember to add the block.A parse-time mechanism (a small splitting
pflag.Valuewrapper, or autil.StringArrayCommaSeparated(...)registration helper next toAddFlagAliasesStringSliceinpkg/util/pflagaliases.go) would give every command the behavior consistently and remove the ordering hazard.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both sub-points hold, but I've left the expansion where it is and want your call, because the obvious parse-time version silently undoes the blank-value fix from c64ab93.
Point 1 confirmed.
tenant connectregisters-e/--environmentwithStringArrayVarP(connect.go:108) and does no splitting, so-e "dev,test"is one environment name there and two onrelease deploy.Point 2 is real but currently latent. The only
PreRunEon either command isutil.ApplyFlagAliases, and the expansion is the first statement ofdeployRun/runbookRun, so nothing reads unsplit values today. It is an invariant held by convention, which is your point.Why I didn't move it. A splitting
pflag.Valuehas to reject blanks inSet, andutil.ApplyFlagAliasesdiscardsSeterrors —pflagaliases.go:63and:66are both_ = primaryFlag.Value.Set(...). I checked both shapes with a throwaway test drivingApplyFlagAliases:Valuethat errors on a blank component,--deployTo ","leaves the primary flagniland no error escapes;[]string{"", ""}and fails with--environment has a blank value; ....So parse-time splitting reintroduces exactly the silent scope change from the blank-drop thread, on the legacy alias path (
--deployTo,--env,--tag,--tenantTag,--target,--specificMachines,--exclude-target,--excludeMachines).The version that doesn't regress is three parts:
util.ApplyFlagAliasesreturnserror. 7 call sites (buildinformation upload,package upload,release create,release deploy,release progression allow,release progression prevent,runbook run) — each is already inside aPreRunEthat returnserror, so it is one line each. Checked the other aliasSetpaths: string/stringArraySetnever fail and bool aliases are fed from a bool flag's ownString(), so the new splittingValuewould be the only thing that can error.AddFlagAliasesStringSlicewrapping a splitting/blank-rejectingpflag.Value(keepingType() == "stringArray"so help output and completion don't change; nothing in the repo callsGetStringArray, so that's free).executionscommonintopkg/utilor a leaf package, becausepkg/utilcan't importexecutionscommon.I think (1) is worth doing on its own merits — swallowing
Seterrors during alias application is a latent bug independent of this PR. What I don't want to do unilaterally is (2)+(3) plus opting the other commands into comma splitting, under a PR scoped to the deploy/runbook scope flags — there are 11StringArray--environmentflags inpkg/cmd(these two,tenant connect, and the eightaccount ... createcommands), and changing the rest is an observable behaviour change to commands #556 doesn't mention.Decision I need: land #556 with the expansion in the two run functions and take (1)+(2)+(3) as a follow-up that also decides which other commands opt in — or do you want all of it here, and if so should the splitting
Valuego on everyStringArray--environmentor only on the deploy/runbook ones?