-
-
Notifications
You must be signed in to change notification settings - Fork 913
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
Global config file #46
Comments
I'm not sure I understand why this is needed... can you elaborate a little bit more? |
It all depends on use case, but for where people have control over a CI box (I'm thinking of on my jenkins slaves) or where they only expect to run locally there are a couple of reasons where this would be useful:
It would also help with stuff like #44 where people always, or even mostly, expect to override the default with a pattern. |
@jspc hmm, I think I understood now. Yeah, makes sense indeed. |
I'll open an RFC PR later, it's largely working but I'll wait for your templating so I don't get into merge hell |
@jspc sounds good, I plan to finish my PR tonight or tomorrow morning (gmt-3) |
can I close this one? |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
To help DRY up configuration, and to help with global options (perhaps a particular machine, developer expects to build mainly on ARM with BSD) I propose a global releaser.yml file.
It would look like:
Note the addition of a github token. This would allow the omission of the env var, and without the concern of committing it to source control given this file is outside of the repo.
It would introduce an order of precedence:
The text was updated successfully, but these errors were encountered: