Closed dominykas closed 3 years ago
Thank you for thinking of these cases. Initially due to looking at this at the end of the day I did not understand the issues. But I think you have explained them. My turn to think aloud.
Essentially the wiby-some-branch may exist and there are different reasons to why it could be preexist. But these come down to 2 use cases ( a or b/c).
As a thought experiment I tried to rationalize methods of determining what the two cases are or avoiding having this situation.
If the branch names where unique to a particular run of wiby wiby-branch-name-unique-id then the use cases would be known and the means to address them would be understood. However that would mean keeping track of the unique branch names raised locally. So that would make things complicated at a stage we don't want them to be complicated further.
Place a well known comment in the PR ( if one exists ) before we attempt to clean it. If as in the raise draft PR we check to see if a comment from clean was added.
If we accept that we cannot know what use case caused the branch to exist we can ask the user. This would require the user to understand things and would mean that wiby would essentially have to scan the repos for these situations before asking the question of the user.
Hope my thinking out load helps with this conversation.
The actual options are limited and in some sense is a help to working out a potential solution.
OK, so after discussing this in PM WG meeting, here's my current thinking:
Going forward:
wiby result
(new feature)
wiby-[branch name]
when it is not up to date with its corresponding [branch name]
, if one exists - not just the default brancheswiby rebase
(naming TBD - we probably don't want to do an actual git rebase
), which would make sure that the target branches are up to date with their corresponding default branches wherever possible:tada: This issue has been resolved in version 0.9.0 :tada:
The release is available on:
Your semantic-release bot :package::rocket:
Scenarios:
some-branch
on the parent repowiby test
wiby-some-branch
a) It could be that you already ranwiby test
and did notwiby clean
afterwards (most common) b) It could be that whoever was testing, wanted to make additional changes on the branch to get the tests to pass with the linked parent c) It could be that it exists, because multiple dependencies are being testedThinking out loud:
git commit -m "This is a blank commit" --allow-empty
) to re-trigger the builds.HEAD
and link the parent again.wiby test
is running against outdated code (i.e. it no longer answers the question "will I break you"...)master
, before pushing a new commit? Can that be done via the API? We could then notify the user about the conflicts, if any, viawiby results
?Related issues: