The branch#
A work item gets its branch the moment its work starts, not when an agent decides to make one. Eido Build cuts it from the project’s default branch and names it from the work item:
eido/PULSE-142-export-truncates-long-namesBecause the name is known from the start, the build view has something to show from the first minute and every stage’s documents have somewhere to live.
- The first part of the name,
eido, is the project’s branch prefix. An administrator can change it. A work item keeps the branch it was given. - A work item whose type does not cut a branch, such as a task, never gets one.
Documents on the branch#
Each version of a document an agent writes is committed to the branch under .buildengine/<KEY>-<n>/. The commit message includes [skip ci], so editing a design does not redeploy anything.
Builds#
Build on the work item shows the builds for its branch: each run, its jobs, and the failing log in full. It is read from your repository host each time you look, so what you see is always the current state.
Changes#
Changes shows what the branch changes compared with where it will merge: a tree of the files, and each file in full with its differences marked.
The pull request#
In the stock workflows the pull request is one stage, Merge. It:
- Opens a pull request from the work item’s branch.
- Checks it once a minute and shows what it is waiting for: “Waiting for approval”, “Changes requested”, or “Merged”.
- Merges it once somebody approves it on your repository host.
Approving the pull request happens on GitHub or Azure DevOps, under your own branch protection rules. Eido Build does not approve its own pull requests.
The merge commit#
Eido Build writes the merge commit itself: the pull request’s title and number, and one line of its own. This matters because the document commits on the branch say [skip ci]. If those messages were carried into a squash commit, the build for the target branch would be skipped.
Merging into more than one branch#
A merge stage merges into a named branch, and a workflow can have several. A workflow that takes work through UAT might be:
- Merge into
uat - An approval
- Merge into
main
Each merge is its own pull request from the work item’s branch. It is never a promotion of uat into main, which would carry everybody else’s work with it.
A later stage can wait for the uat deployment, so that QA on the UAT environment starts once the merge has reached it.
Deleting the branch#
A merge stage can delete the branch after merging. The workflow sets the default, and you can change it on a work item until it merges. The branch is kept anyway while a later stage still needs it, or while it has commits the merge did not take.