Explict release configuration should disable inferring release targets (multiple-tokens error)

[dekimsey]

Is your feature request related to a problem? Please describe.

I use my personal access token to release code to some projects on GitLab (private) and GitHub (public). Currently, when goreleaser has access to both tokens via ~/.config/goreleaser/gitlab_token and ~/.config/goreleaser/github_token respectively the application fails to deploy with an error message:

multiple tokens found, but only one is allowed: GITHUB_TOKEN, GITLAB_TOKEN

Learn more at https://goreleaser.com/errors/multiple-tokens

Describe the solution you'd like

My project's goreleaser.yml has an explicit release block configured. I'd like it's presence to indicate that this scm should be used, and that the inferring logic be disabled.

Describe alternatives you've considered

I tried setting the env_files.gitlab_token to a custom path but that also does not work. It seems the presence of both tokens makes it impossible to opt-out of the default targets.

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

[caarlos0]

seems valid, yes, thanks for the suggestion!

[caarlos0]

its a bit weird, but you could, in theory, set the path to a file that does not exist for the token you don't want to use, e.g.:

# .goreleaser.yaml
env_files:
  gitlab_token: /nope

seems like an usable workaround....

[caarlos0]

I think that this is actually a pretty good fix, anything else I can think of is pretty much the same config with different semantics...

I'll just update the docs explaining this.

[dekimsey]

Is null a valid value here?

[caarlos0]

it will be interpreted as a path to a file named null, but other than that, should be fine, yes

[dekimsey]

Hrmm, I think that'd be odd behavior as null is keyword in yaml.

[caarlos0]

Hrmm, I think that'd be odd behavior as null is keyword in yaml.

ahh right, then it'll probably default to empty, which goreleaser will default the default file path for each token.

my suggestion would be to set to something like ~/.this-file-does-not-exist or something clear enough for future you as well as for other people...

[dekimsey]

I'd argue the non-existent path issue hides a user error (a perfectly valid path with a typo). I think it's a bit unexpected to point to a non-existent path and have it not error. But that's me. You tell me what you think is best :)

I prefer being a bit stricter on inputs myself, and we cannot really tell the difference between an explicit null and an unset key in YAML, but we can tell if the value is the empty string:

What we have right now:

Value	Effect
"/valid/path"	loads
"/typo/path"	silently ignored
explicit null	default behavior, will load default paths
implicit null	default behavior, will load default paths
""	empty string, default behavior

What I think makes more sense, to me (still uses a sentinel which is a bit meh):

Value	Effect
"/valid/path"	loads
"/typo/path"	error: no such path
explicit null	default behavior, will load default paths
implicit null	default behavior, will load default paths
""	empty string, disable this flag

That's just my take, error on non-existent paths, support default behavior, but give an opt-out for the behavior. I haven't really thought about the fact that we also have POSIX environment loading here.

One could get fancy and make a boolean false the off, but that might going too far.

[caarlos0]

if all token provider mechanisms fails, it will fail as well... it ignores file not found errors because of the defaults, and that error per se is not that relevant, whereas if that error happens and its also not possible to load any others, it means things will fail later, so it errors.

anyway, for now, will proceed as said before as its 100% backward-compatible with no tricks needed.

thanks!

[dekimsey]

Makes sense, thinking about this morning I thought similarly. It's documented now, that'll work just fine.

Thank you!

[github-actions]

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.