How do concurrent builds work with a single repository workspace?
Hi all, I understand about multiple build engines needing separate workspaces and load directories but I have a concern about the single repository workspace.
The Jazz Source Control page of the build definition provides for a single repository workspace to be specified, but consider two builds of one build def running concurrently; the repo workspace is loaded into two load directory sandboxes. The end of my build process checks in and delivers the changes to the stream then takes a snapshot.
How will this work if two builds are trying to check in and deliver at the same time?
This is in the context of CLM 4.0.7 on Windows Server 2008 R2.
The Jazz Source Control page of the build definition provides for a single repository workspace to be specified, but consider two builds of one build def running concurrently; the repo workspace is loaded into two load directory sandboxes. The end of my build process checks in and delivers the changes to the stream then takes a snapshot.
How will this work if two builds are trying to check in and deliver at the same time?
This is in the context of CLM 4.0.7 on Windows Server 2008 R2.
Accepted answer
Hi Cliff,
I've already have this problem, and then I tried to avoid it. It works if the file checked-in in the two builds are different. Otherwise the second deliver will get an error because it needs a merge (which is the case if you're trying to check-in generated artifacts, as I suppose), unless you're managing it with your custom check-in-and-delivery script/extension.
I've already have this problem, and then I tried to avoid it. It works if the file checked-in in the two builds are different. Otherwise the second deliver will get an error because it needs a merge (which is the case if you're trying to check-in generated artifacts, as I suppose), unless you're managing it with your custom check-in-and-delivery script/extension.
Comments
2 other answers
If you use the JBE and the Jazz Source Control Tab, there is no problem at all.
The Jazz Build Engine does not check in or deliver any changes from the build repository workspace.
Quite the opposite, the Jazz Source Control options are set up in a way that the repository workspace can accept the changes from the stream in public builds. If set up this way this essentially means that the JBE loads what is in the stream to the build workspace and builds that.
The snapshot is taken after accepting - not after any delivery, since delivery never happens.
For private builds the JBE does not even have write permissions, so here it loads exactly the content of the workspace and builds this. Any created content would only be local to the load location and never show up in the repository workspace itself. The JBE couldn't check anything in, even if it tried to, due to the lack of permissions.
If you create automation and additional scripting that checks in generated files from the build, I don't know what would happen. As far as I can tell, the repository workspace, once loaded is never checking consistency. This would happen in custom build scripts e.g. using the CLI in which case you might run into errors if you check into the repository workspace in two places.
I am not a fan of checking in artifacts that are generated during a build. To me, these are generated and should not be in source control anyway.
The Jazz Build Engine does not check in or deliver any changes from the build repository workspace.
Quite the opposite, the Jazz Source Control options are set up in a way that the repository workspace can accept the changes from the stream in public builds. If set up this way this essentially means that the JBE loads what is in the stream to the build workspace and builds that.
The snapshot is taken after accepting - not after any delivery, since delivery never happens.
For private builds the JBE does not even have write permissions, so here it loads exactly the content of the workspace and builds this. Any created content would only be local to the load location and never show up in the repository workspace itself. The JBE couldn't check anything in, even if it tried to, due to the lack of permissions.
If you create automation and additional scripting that checks in generated files from the build, I don't know what would happen. As far as I can tell, the repository workspace, once loaded is never checking consistency. This would happen in custom build scripts e.g. using the CLI in which case you might run into errors if you check into the repository workspace in two places.
I am not a fan of checking in artifacts that are generated during a build. To me, these are generated and should not be in source control anyway.
Comments
Thanks for your comments and it looks like I need to use the build def to drive a CLI process that will create, use then destroy a repo workspace for a better solution.
I have valid reasons for storing generated artefacts in RTC, and I understand the point about such stuff being derived and therefore re-derivable but there are certain advantages of being able to tie source and object togther with a snapshot, and other advantages of being able to drive automated deployment from a snapshot on a release stream. For us, 'some artefacts repository' for deployable artefacts is RTC and the advantages of this approach outweigh the disadvantages.
I have valid reasons for storing generated artefacts in RTC, and I understand the point about such stuff being derived and therefore re-derivable but there are certain advantages of being able to tie source and object togther with a snapshot, and other advantages of being able to drive automated deployment from a snapshot on a release stream. For us, 'some artefacts repository' for deployable artefacts is RTC and the advantages of this approach outweigh the disadvantages.
Comments