Baselines created during builds?
So, I discovered something that surprised me. Can someone explain it?
So, we have continuous and daily builds. I was training some of our engineers on Jazz, and used an example of needing to fix a defect found in one of our daily builds. So here is what I did: Opened the broken daily build. Clicked on the link for the snapshot for that build Created a repo workspace Fixed my bug. Then I had to add the development stream to the list of flow targets. So, this is where things got confusing. When I saved the repo-workspace definition, I saw a few things added to the pending changes view. Some I expected (incoming change sets for example). But what I didn't expect was there were a number of outgoing baselines. One for each component. They matched various continuous builds (not all the same continuous build). So, what is going on? We are not creating baselines explicitly in our build scripts. Can someone explain how baselines are managed by builds? |
5 answers
When the jazz build engine (or the teamAccept task) accepts the latest
changes into the build workspace, a baseline is created on any component that has unbaselined changes. This means a baseline is only created if necessary, but that there WILL be a baseline for all changes. Also, a snapshot is created to contain those baselines. When you create a workspace from that snapshot, the baselines are present in the workspace. Of course, these baselines are not present in the development stream (only in the build workspace and your new workspace), so they show as outgoing when you flow with the development stream. I understand it can be annoying to have pending changes when you don't know where they come from. I would probably just ignore those baselines and not deliver them to the main development stream. I think the scenario you are in is not exactly what is intended to happen very often. Typically, you would only perform the "create workspace from snapshot" action when you need to address a problem in the codebase which the build was done, AND the build workspace has diverged far from your main development stream. In that case, its really the only way to get yourself a workspace to repro and fix the problem. Once you've fixed it, you typically very carefully deliver that change set to a maintenance stream, and perhaps also to main development stream, but its done carefully and I wouldn't deliver baseines in that case. For the "needing to fix a defect found in one of our daily builds" case, I'd just create yourself a workspace off the main development stream (if you didn't yet have one) and make the fix there. I don't know that there is a right or wrong answer here, but I've tried to shed some light. --- Ryan Manwiller Jazz Team |
|
Got it.
But riddle me this... We have "build only if changes accepted" is checked for our daily builds. But when I look at the workspace created for the daily build, it is only showing baselines for previously run continuous builds. Based on what you are saying, I would have expected at least one baseline created for one of the components, otherwise there would be nothing new, and thus no build? |
Baselines are only created if they are needed. So in the case that a team delivers baselines regularly, the build workspaces won't have to create them when the snapshot is created.
In your case, there is a special preference called "hide empty baselines" which you can use to filter the pending changes view. In most cases, since the build is just remembering snapshots for you which contain the same change sets as the stream, you can ignore them when you flow. Jean-Michel |
Baselines are only created if they are needed. So in the case that a team delivers baselines regularly, the build workspaces won't have to create them when the snapshot is created. That's my point, no baseline appeared to be created for the daily build, so why was the build done since we checked "only build if acceped incoming changes"? |
|
If you click the changes link in the build result, you should see why the
build was done. No new baseline may be necessary, but the build workspace may still not have that baseline yet. This is the typical case. Teams deliver new baselines to the main development stream. The build will accept all the changes and any baselines (thus a build is performed since changes were detected), but the changes are already in a baseline, so no new baseline is created. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.