You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the various ospo actions are completely independent. But users who adopt several of them end up restating a lot of configuration for them which would ideally be centralized. As concrete examples, setting:
a list of repositories to ignore from reporting, or conversely a list of ones to only report
whether to execute in dry run mode or not
output formats / destinations that are not the default
... probably others ...
would be better served by a common configuration file that all of the actions know to look for.
The text was updated successfully, but these errors were encountered:
a central ~/.githubospo (not married to the name) file that has all the contents from each repositories .env-sample or README environment variables (some are not in the samples currently) in there. Like asked above, if exists, it will be used and then fall back to repo directory .env file.
Questions:
you mean this from a contributor's perspective, correct? When a developer is working on a pull request locally each action could look for the "centralized" environment variable file and use it if it exists, otherwise fall back to the repo's .env file. I ask this because when the actions run they will be told where the environment variables are located, usually in repo secrets (e.g, ${{ secrets.GH_APP_ID }})
do we want to do one or the other regarding parsing (either ~/.githubospo or repo_dir/.env)? Or do we parse from both. I prefer the former, easier to manage. Otherwise you have to set expectation on presidence re: overwrites (i.e, GH_APP_ID is in ~/.githubospo and also in repo_dir/.env, which has presidence?)
Currently, the various ospo actions are completely independent. But users who adopt several of them end up restating a lot of configuration for them which would ideally be centralized. As concrete examples, setting:
would be better served by a common configuration file that all of the actions know to look for.
The text was updated successfully, but these errors were encountered: