Name wiby test branches based on the dependency branch name

[dominykas]

At the moment, wiby test will create a branch called wiby-[dependency name] on the dependent being tested (and wiby result will check here).

This is very restricting - it means that you can only test one set of changes in the dependency at a time (i.e. if you have multiple PRs open on wiby, they would both try to write into wiby-wiby). Moreover, this does not allow automated linking of multiple dependencies into a single test branch.

The proposal here is to name the branch based on the dependency branch, i.e. if I'm testing feat/new-stuff on wiby, then the test branch would be called wiby-feat/new-stuff on the dependent. This way other dependencies could have feat/new-stuff and would all link into the same wiby-feat/new-stuff branch.

• The wiby- prefix is necessary, to avoid touching non-wiby branches that people may be working on. It also makes it easier to implement the wiby clean...
• If the dependency branch already starts with wiby- - the prefix will not get added multiple times. Rationale: people may need to make tweaks to make the tests pass, esp. when linking multiple dependencies together.
• If the dependent already has a branch called feat/new-stuff, then wiby should base the wiby-feat/new-stuff off that, rather than off main / master.
• Bonus points: figure out how to best name the wiby-* branch when the branch being tested is a master / main on a fork of the dependency. wiby-author-master? wiby-pr-NNN [if PR already exists - it might not in the pure CLI case]?

Examples

Assuming the following imaginary dependency tree:

• update-notifier
  • is-ci
    • ci-info
  • ci-info

Someone is authoring things in ci-info and wants to make sure they don't break is-ci and update-notifier.

New feature in ci-info

1. The author has push access to ci-info, they create a new branch with feat/awesome-stuff
2. They wiby test
3. wiby creates a wiby-feat/awesome-stuff branch in is-ci and in update-notifier where it updates the ci-info to be pulled from git #feat/awesome-stuff.

New feature spanning ci-info and is-ci

1. The author has push access to ci-info, they create a new branch with feat/awesome-stuff
2. The author has push access to is-ci, they create a new branch with feat/awesome-stuff
3. They wiby test in ci-info
4. wiby creates a wiby-feat/awesome-stuff branch in is-ci (based off feat/awesome-stuff) and in update-notifier where it updates the ci-info to be pulled from git #feat/awesome-stuff.
5. They wiby test in is-ci
6. wiby updates wiby-feat/awesome-stuff in update-notifier to pull is-ci from #wiby-feat/awesome-stuff
   • This means that update-notifier now has ci-info linked from git, and deduped as well.

New feature in ci-info, wiby uncovers tweaks required in is-ci

1. The author has push access to ci-info, they create a new branch with feat/awesome-stuff
2. They wiby test
3. is-ci breaks - the author pushes some modifications to fix that directly into wiby-feat/awesome-stuff branch
4. They wiby test in is-ci
5. wiby sees wiby-feat/awesome-stuff branch in update-notifier and links is-ci from git #wiby-feat/awesome-stuff branch.

(I'll consider drawing up some diagrams for this...)