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

[tjgurwara99]

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]

@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]

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.

[mouismail]

Hi Folks! I can jump here and give an extra hand if you would like to, as per the conversation above the new funcs should something similar to the following, with extra validation to accept only yaml files.

func ReadFromPath(path string) (*Config, error) {
	m, err := mapFromFile(path)
	if err != nil {
		return nil, err
	}
	return &Config{entries: m}, nil
}

func WriteToPath(path string, c *Config) error {
	c.mu.Lock()
	defer c.mu.Unlock()
	return writeFile(path, []byte(c.entries.String()))
}

is that correct?