forked from jenkinsci/jenkins
/
concurrent-build-branch-note.txt
40 lines (28 loc) · 1.66 KB
/
concurrent-build-branch-note.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
TODO:
- think about the implications of this change to workspace deletion
- replace various "1.XXX" reference to the right revision when we merge this back to trunk.
Release Plan
============
1. have some interested users try this out
2. merge this to the trunk, but hide the feature. This allows plugins to be updated to use
checkpointing, in preparation of mass launch
3. solicit interested parties to activate this feature
4. soak time for stability
5. ship!
Notes
=====
- serialize post build steps, like computing test results, since they depend on the previous result.
we need some way to mark the build steps that need this service, in a way that preserves compatibility.
-> added check pointing
- serialize the changelog calculation. How do we handle backward compatibility?
-> it turns out that CVSSCM doesn't need checkpointing for this, because it uses a timestamp.
- think about the implications of this change to polling
-> introduced WorkspaceList to control the lock.
- figure out what to do with AbstractProject.getWorkspaceResource(). I just removed it from
AbstractProject.getResourceList() but this will break the lock mechanism with SCM polling, tagging, and
other related activities that require a workspace.
-> the way polling is now done should be followed by everyone else who needs to lock the workspace.
- how to preserve the compatibility with earlier plugins?
(in a way that doesn't carry the burdern forever --- marker interface, abstract method?)
it should force the build step to wait until the previous build completes.
-> new method on the interface, which maintains binary compatibility but not source compatibilit.