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

Global config file #46

Closed
jspc opened this issue Jan 4, 2017 · 7 comments
Closed

Global config file #46

jspc opened this issue Jan 4, 2017 · 7 comments
Labels
enhancement New feature or request wontfix This will not be worked on

Comments

@jspc
Copy link
Contributor

jspc commented Jan 4, 2017

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:

github:
  token: github-token
build:
  oses:
    - freebsd
  arches:
    - amd64

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:

  1. default values in releaser
  2. global config
  3. repo config
  4. env vars/ cli args
@caarlos0
Copy link
Member

caarlos0 commented Jan 4, 2017

I'm not sure I understand why this is needed... can you elaborate a little bit more?

@jspc
Copy link
Contributor Author

jspc commented Jan 4, 2017

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:

GITHUB_TOKEN will largely not change, so using an env var isn't as useful as it could be. It would help people who tend to build for specific environments/ usecases that aren't just OSX and Linux not have to copy/paste build sections from project to project.

It would also help with stuff like #44 where people always, or even mostly, expect to override the default with a pattern.

@caarlos0
Copy link
Member

caarlos0 commented Jan 4, 2017

@jspc hmm, I think I understood now.

Yeah, makes sense indeed.

@jspc
Copy link
Contributor Author

jspc commented Jan 4, 2017

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

@caarlos0
Copy link
Member

caarlos0 commented Jan 4, 2017

@jspc sounds good, I plan to finish my PR tonight or tomorrow morning (gmt-3)

@caarlos0
Copy link
Member

can I close this one?

@caarlos0 caarlos0 closed this as completed May 3, 2017
@caarlos0 caarlos0 added the wontfix This will not be worked on label Jul 8, 2017
@caarlos0 caarlos0 added feature enhancement New feature or request labels Mar 6, 2018
@github-actions
Copy link
Contributor

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 19, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants