Our jenkins projects are generally set up with template (classic) workspaces, and "poll SCM". That combination is causing *lots* of revisions in our spec depot. It looks like every poll updates the jenkins workspace (client spec) from the template.
On the one hand, this is the "safe" thing to do, making sure the jenkins workspace has the current mapping. But our templates don't change much, so we don't need constant refreshing from the template.
Is there a different jenkins workspace type I should use instead? (Manual, Spec File, Static)
Or is "poll SCM" the source of the spec depot revision churn?
Jenkins affect on spec depot
1 reply to this topic
Posted 15 October 2018 - 07:56 PM
Edit the spec depot specification, and add exclusion mappings for patterns you don't want revisions for. For example, if all your Jenkins client workspaces are named something like jenkins_project_foo and jenkins_project_bar you can add an entry under SpecMap: "-//spec/client/jenkins_project_*" and it will ignore any client that matches. Jenkins polling shouldn't generate new revisions unless it's deleting & creating a workspace every time. If you let Jenkins manage the workspace, it usually creates a unique name like projectname-1234567 but it will reuse that same name, at least on a given slave. If multiple slaves can build the same project you'll probably get 1 workspace per slave.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users