-
Couldn't load subscription status.
- Fork 7.3k
Fix GH_REPO usage with secret commands #10535
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
Fix GH_REPO usage with secret commands #10535
Conversation
9ade48d to
024bb68
Compare
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.
I think this is as clean of a solution we're likely to get outside of refactoring gh to use spf13/viper which is non-trivial and not being advocated for at this point.
pkg/cmdutil/repo_override.go
Outdated
| repoOverride, ok := os.LookupEnv("GH_REPO") | ||
| // If the envrionment variable was set, then set the value of the `repo` flag, | ||
| // this ensures that checks for `HasChanged` work correctly. It's a bit "spooky" | ||
| // action at a distance because the flag will not have been set by the user, | ||
| // but perhaps it makes sense? | ||
| // | ||
| // The reason we need this is because there are `secret` commands that need to know whether | ||
| // the user set the repo, and the alternative is them having knowledge of the flag and env var, | ||
| // or by adjusting all our types so that the "source" of the BaseRepo is surfaced, which is a | ||
| // pretty big change. | ||
| if ok { |
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.
Nothing wrong with the logic; just stating how this works.
If a user has GH_REPO="", then we will attempt to set the flag with the value if empty and defer to spf13/pflag to determine if the flag has been changed or not.
pkg/cmdutil/repo_override.go
Outdated
| // First, get the value of the flag. | ||
| // We can ignore errors here because the flag is guaranteed to exist and be string. | ||
| userProvidedRepo, _ := cmd.Flags().GetString("repo") | ||
| if userProvidedRepo == "" { | ||
| // If there was no flag set, then check the GH_REPO environment variable, | ||
| // which has lower precedence. | ||
| repoOverride, ok := os.LookupEnv("GH_REPO") |
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.
Just going to say this is more elegant of a solution than I was considering when we initially discussed this. I hadn't considered the utility logic setting up the persistent flag.
This helps keep the concerns in 1 place, so hopefully easier to grok and manage.
| type baseRepoFn func() (ghrepo.Interface, error) | ||
|
|
||
| func PrioritiseEnvBaseRepoFunc(baseRepo baseRepoFn) func() (ghrepo.Interface, error) { | ||
| return func() (ghrepo.Interface, error) { | ||
| repo := os.Getenv("GH_REPO") | ||
| if repo == "" { | ||
| return baseRepo() | ||
| } | ||
| return ghrepo.FromFullName(repo) | ||
| } | ||
| return f.BaseRepo | ||
| } |
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.
From what I can gather, there aren't any functional changes to this logic but refining it:
- decouple this from
Factoryfor some arbitrary logic that provides aghrepo.Interfacelike the base repo functions - focuses this solely on the environmental override
- defers to the provided default if environment is a no go
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.
focuses this solely on the environmental override
That's the functional change. Previously it also accepted a string to be like "just return this", which frankly, is a bad solution because the caller should just choose not to call the function if it were empty.
8e02b7b to
fa4e15c
Compare
|
@williammartin : With #10539 reviewed and merged, what are your thoughts regarding this draft? Is there a larger issue to follow up on with the former being a short term patch? |
|
Unlikely we are going to prioritise this. |
Description
Fixes #10525
Draft because I'm not convinced about the cost of the commented "spooky action at a distance" but wanted to put something out there.
I removed
OverrideBaseRepoFuncbecause it was in my opinion, not a very good abstraction to have exported as seen in the call site ofgh api:Now replaced by:
The code was then inlined into
EnableRepoOverride.Acceptance
Given my cwd is not a git repo
And I have
GH_REPOset to a repo I have permissions onWhen I run any of the
gh secretcommandsThen I am able to interact with secrets on that repo
Before:
After: