I've got a bit skeptical about the backward compatibility, as the current implementations for already provides the account|org/repo format:
The proposal of creating a new env variable will provide a misleading since CHANGE_FORK and CHANGE_FORK_FULL env variables will behave differently based on the specific branch source plugin and therefore might confuse. Besides, the API is the one which specifies what it should be done, therefore the implementation should proceed with the requirement. In other words:
- github-branch-source will contain two env variables: CHANGE_FORK=account CHANGE_FORK_FULL=account/repo
- bitbucket-branch-source: CHANGE_FORK=account/repo CHANGE_FORK_FULL=account/repo
- gitlab-branch-source: CHANGE_FORK=account/repo CHANGE_FORK_FULL=account/repo
As the implementation is not right, it means it's required to touch even in the API to solve it which it might be awkward. For sure it's a breaking change, but people should already be aware the implementation itself should be account/repo as already noticed in the docs. So they should not be surprised about it, although adding an entry in the release notes with the implication of those changes might be enough. Besides, I've got a question, the current implementation for CHANGE_FORK is invalid when the fork name differs from the upstream name, therefore how do we encourage people to avoid using it and use CHANGE_FORK_FULL? |