Skip to content
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

Add the ability to introduce repository specific configurations for gh-cli and its extensions #130

Open
tjgurwara99 opened this issue Aug 18, 2023 · 2 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@tjgurwara99
Copy link

Feature request description

I would like to propose the addition of a feature that enables the integration of repository-specific configurations into the pkg/config package, drawing inspiration from the way Git handles local .git/config versus XDG_CONFIG_HOME configurations. This enhancement could prove invaluable for various extensions creators who could leverage distinct settings tailored to each repository's requirements.

Motivation

Consider a chat-op deployment scenario - a good gh extension that integrates well with external platforms like Discord or Slack, having the ability to define and commit repository-specific configurations directly within the repository itself can offer significant advantages. For instance, imagine a use case where different repositories need to route communications to specific channels on these platforms. The current config package is limited in that the configs are global (AFAIK - please let me know if this is incorrect) which leaves the current approach of providing options each time a command is invoked which can become cumbersome, especially when the values for channels differ across repositories. This is just one scenario where repo specific configs might be useful but I'm sure extension creators can think of creative ways to use this feature 😄

Implementation

The proposed implementation could involve creating a dedicated configuration file within the repository, such as .ghconfig, where users can define repository-specific settings. This file would be committed alongside other source code and assets.

Conclusion

Introducing repository-specific configurations to the "gh" library has the potential to enhance the usability, consistency, and flexibility of the tool in scenarios where distinct settings are essential on a per-repository basis. This feature aligns with the natural progression of version control practices and would undoubtedly contribute to streamlining workflows and improving overall efficiency.

@samcoe
Copy link
Contributor

samcoe commented Aug 23, 2023

@tjgurwara99 Thanks for the feature request. This type of feature has come up a couple times in the cli/cli repo, mainly around being able to support multiple accounts GitHub accounts and switching them based on the current local repository. I think gh itself should be vary wary of creating its own per repository config files as that greatly complicates the reading and writing of gh configurations, but if an extension wants to create its own configuration files I think we can support that.

Right now the limiting factor for this feature is the hardcoded locations for reading and writing configuration files using the generalConfigFile() and hostsConfigFile() functions as you mentioned. I think if we introduced two new functions to the config package ReadFromPath(path string) (*Config, error) and WriteToPath(path string, c *Config) error that would allow extensions to read/write/manipulate yaml files and it would be on the extensions to manage their own configuration files as they see fit.

Note that the config package only has infrastructure for working with yaml files so I don't think we will want to support any other formats.

What do you think of this approach?

@tjgurwara99
Copy link
Author

I think if we introduced two new functions to the config package ReadFromPath(path string) (*Config, error) and WriteToPath(path string, c *Config) error that would allow extensions to read/write/manipulate yaml files and it would be on the extensions to manage their own configuration files as they see fit.

This sounds good to me. I think its a good approach as this would provide the extension owner the freedom to set their configuration however they see fit.

@samcoe samcoe added enhancement New feature or request help wanted Extra attention is needed labels Aug 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants