-
Notifications
You must be signed in to change notification settings - Fork 8
Thoughts on design
The current method of pushing and building does not work correctly, we need to change the steps in which things happen
This is how it currently works:
Hg changegroup hook:
- User pushes a branch
- Changegroup-hook in hg notifies jenkins and asks for a build
Jenkins precheckout:
- Build starts, and is queued
- The current branch tip is saved
- The stage Repository is pulled from the server
Jenkins postcheckout:
- If the build succeeds, push to company truth
- If the build fails, restore
This is an outline of the steps that should work:
Hg changegroup hook:
- User pushes changeset
- Hg changegroup-hook creates consecutively enumerated tag of tip
- Hook orders Jenkins build
Jenkins precheckout:
- Build saves (getMasterHead)
- Build starts, gets "least" tip from stage repository and finds (getDevelopmentHead)
- Jenkins cherrypicks hg pull -r (prepareWorkspace)
- Jenkins merges with branch. If merge fails, the build fails: hg update -C - - (cleanupWorkspace)
Jenkins build:
- Jenkins builds using the configured build-steps.
Jenkins postcheckout:
- If build succeeds: hg commit --close-branch; hg push (commitWorkspace)
- If build fails: (cleanupWorkspace)
Using multiple remotes obviously increases the possibility for connectivity problems: Response times, firewall access or internet outage. Further, having multiple remotes increase the odds of introducing strange read/write permissions.
Currently we use two remotes: Company Truth and Jenkins Remote. One should be read-only (CT) and one should be write-only (JR). If users push to CT or read from JR stuff will act up. As the read/write rules are determined on the client-machines in -settings we cannot guarantee that all users will follow these rules.
Thus we need to carefully handle what should happen if CT changes without it happening through a build step. Somehow the PRTECO-plugin needs to validate the state of CT. This require testing so that:
- A build does not use a remotely modified CT
- A remotely modified CT is automatically reverted OR A remotely modified CT always fails builds with a proper warning. This is further discussed in the section Using a guarded branch.
If people decides to pull directly from JR, stuff will fail when they attempt to build next time if needed, why we do not need to handle this in any special fashion. We do however need to test this.
TODO
An obvious error occurs when a guarded branch is not guarded properly, allowing developers to push broken code directly to the given branch causing all future builds following this to fail.
We can check if the guarded branch is dirty by pulling it before merging the stage repository - if any updates has been made to that branch we can consider the branch dirty, as the latest thing that should have been pushed is already in our workspace. There is a special case when the workspace is initialised where this is not true.
We need to test that this dirtyness-awareness is possible and can be handled properly.