refactor(config): enable default environment token per hvcs #774
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Purpose
Update the configuration parser to optionally default to the VCS specific token
Rationale
In preparation to facilitate the request of #734, I need to find a way to solve the missing token when the
remote.type
isnone
. This led me to determining that it would be helpful if we looked for the default token names for each of the VCS. This refactor enables the configuration to be aware of each VCS's default.Current downside is that
Gitea
does not provide a pre-authed CI-like token based on this discussion. I just guessed to useGITEA_TOKEN
. I could potentially have it be empty instead, which would force the user to provide it.Consideration also should be made for
GitLab
as GitLab's default tokenCI_JOB_TOKEN
has permissions problems withpython-semantic-release
. The fact thatpython-semantic-release
usesgit push
both commits and tags are both unauthorized actions by aCI_JOB_TOKEN
. This means users are forced to provide a PAT as that is how we mark versions. What the users define as that token name is up to them. My guess would be to useGITLAB_TOKEN
but maybe we need to force them to be specific here also. Curious on your thoughts.Separately, there is still some investigation that I'm doing here to hopefully find a better implementation for GitLab.
One of the other issues (besides for
none
) that I have with the current implementation is that if the user does not know to specify a token value or forgets, we default toGH_TOKEN
when I have specifiedremote.type = 'gitlab'
.How I tested
Build a paramaterized unit test with all the expected valid & invalid tests.
How to verify