, then between (2) and (3) you have to push your diff off to somewhere, so that you can come back to it if PB fails and you can work on bug B without mixing bug A. Whatever you do there, it isn't integrated with the delayed commit workflow, and so you can't use delayed commits in the fire-and-forget style.įor example, say you want to (1) work on bug A, (2) do a delayed commit, (3) work on another bug B, (4) do a delayed commit.
#Jenkins teamcity Patch#
Don't reinvent the patch managementįor a developer to make a progress while a PB is running, he has to come up with his own patch management mechanism, such as quilt. OTOH, the delayed commit part is very tedious - if we are to do this outside IDE, we need to write the SCM commit handling, and if we are to do this inside IDE, we have to add this functionality into all the IDEs. TC implements this basically as a build with a patch as a build parameter, so it's straight-forward.
I can see this process in the IDE editor panes, as they change the contents. This appears to be done by (1) pushing my current files aside, (2) bringing back the files as they were when a PB was started, (3) run SCM commit, then (4) bring back the files set aside in step 1. The delayed commit correctly excludes all the additional changes that I made after submitting a PB.This just appears to be a limitation in the implementation, as I don't see anything preventing them from just sending a diff. This situation is detected later when IDE tries to commit them, as it then notices that the file being committed is not the latest. So if the tip of SCM contains a change from Bob in the same file, Bob's change is overwritten by mine. When I submit a PB, entire files are sent to TeamCity, instead of just diff.My PB is tested against the tip of SCM, not against the revision I had locally.This is both good and bad - good because you can continue to make the follow up changes (say you are 50% done in a big refactoring, so you can submit a build, then continue to work on the remaining 50%), bad because you can't move on to work on something totally different. When I submit a PB, those changes also remain in the workspace.It's presumably done this way to handle both kinds of builds uniformly internally. But PBs are invisible to people other than the submitter, so this causes some gap in the build number. Every personal build (PB) and team build gets a build number from the same counter.
#Jenkins teamcity how to#
Trying to hash out different ideas of how to attack the pre-tested commit feature ( JENKINS-1682.) TeamCity implementation Test before merge, after merge, or both?.Should the same set of tests be used for all branches?.What constitutes a successful merge to trunk?.Working on multiple bug fixes in the fire-and-forget style.
0 kommentar(er)
