Why does Jenkins teamconcert plugin discard changesets?
Andy Jewell (242●3●63●74)
| asked Dec 05 '13, 6:00 p.m.
retagged Dec 13 '13, 2:04 p.m. by David Lafreniere (4.8k●7)
I've been using the teamconcert plugin and it's been great. Originally, I was not utilizing the 'automatically accept changes' in the build definition, but since I started doing that, the plugin properly identifies the changesets and links them back to work items in the changeset. Very cool.
There's something I'm wondering about, though. Why does it sometimes reject changesets? E.g.:
Obviously, there's some kind of logic to it. It doesn't look like a misbehavior. But can someone tell me why it discards certain changesets?
Thanks for any ideas!
- Andy
|
One answer
Hi Andy,
You can do a component replace in a stream to kind of "deliver" a discard of a change set. You might do so if you delivered a change set that causes problems and then you want to undo the deliver. If you're unaware of that feature then you are probably kicking the tires and your build is likely using the same workspace that you have loaded in your sandbox. If that is the case, what happens is you check something into your repository workspace and then the build notices those change sets aren't in the flow target and discards them. This is a common mistake when trying things out. If that's not the case, then maybe someone actually did a component replace unbeknownst to you. Regardless, you've touched on a deeper topic. Build doesn't actually just automatically accept incoming changes it too does a component replace of the build workspace components with those in the flow target. And it does so just for this particular scenario you've identified. Hope that helps, Scott Comments I'm not sure if those scenarios apply, but it's good information to understand. I'm still reading through trying to fully grasp it!
In this situation, there have been no discarded changesets in the downstream flows, in other words, no discarded changesets have been delivered nor do we do any checkins into the build repo workspace. I'm not sure why the build would throw out changesets that aren't in the flow target.
I think somehow your third paragraph must be at play. The build definition includes an option to auto-Accept prior to kicking off the build so what you're suggesting is that Jenkins doesn't actually implement it as accept, rather it does a component replace to revert the build workspace to the flow target. I'm not sure I understand that but if that's what it's doing, somehow it might account for my issue.
The only other thing I can think of is that someone is delivering change sets directly to the build workspace.
Geoffrey Clemm
commented Dec 18 '13, 2:32 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
WRT the replace vs. accept behavior, note that this behavior is defined by the RTC Jenkins integration, not by Jenkins. The rationale is that you should be building what is in the stream, and the way to ensure the workspace has what is in the stream is to use the "replace" operation to replace the configuration in the workspace with that of the stream.
|
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.