| It is not possible with the design of the API to know if the event means that the job should be deleted or if a lower priority source in the multibranch project has already received an event for the same branch being created because the branch is being moved from one source to another. e.g. if you configure two sources in the same multibranch:
- g...@git.example.com:/development.git
- g...@git.example.com:/production.git
Now suppose you do something like:
$ git remote add origin g...@git.example.com:/development.git
$ git remote add production g...@git.example.com:/production.git
$ git fetch origin feature-1
$ git push production feature-1
$ git push origin :feature-1
So what happens if we follow Joshua Noble's suggestion is
- Jenkins gets the event from "production" saying "new branch 'feature-1'" and we say: "cool, but development is higher in the list of sources and already owns that branch name... I'll just drop that event on the floor"
- Jenkins gets the event from "development" saying "branch 'feature-1' has been deleted" and we'd delete the job and its history.
So you would lose all the job history of feature-1 being developed. What happens currently is as follows:
- Jenkins gets the event from "production" saying "new branch 'feature-1'" and we say: "cool, but development is higher in the list of sources and already owns that branch name... I'll just drop that event on the floor"
- Jenkins gets the event from "development" saying "branch 'feature-1' has been deleted" and we mark the branch as dead.
- If there is a subsequent event from "production" we let that event "take over" the branch, and all is good, history retained.
- When the scan comes along, we get the full list of branches from each source in priority order and we assign the branch to "production" as a live branch, because the revision is the same, we don't trigger a rebuild
|
