• In my opinion, it is normal for the polling to trigger a build if the config spec has been changed by the user.
• As you said, when using automated time rules, this check shouldn't be enabled because the plugin actually controls the content of the config spec.

• When you say 'plenty' of blocking issues, are there more than JENKINS-15196 (already fixed) and this one? Although these can be considered as 'blocking', I also think that they are very easy to fix so I don't really see the point of rollbacking everything.

Hello,

i've created the pull request 11. I was in vacation last week and i'm surprised about fast integration and delivery. Thank You Vincent!

About JENKINS-15196: it was "left over" from our test version, we simulated cleartool at test build machines and forget to remove this hack. The fallback to cleartool covered this problem. Sorry.

About "new config spec detection": the difference between entered CSPEC and real view CSPEC always confusing our developers. It's not consistent if build was not triggered in this case and manually build was needed to "repair" blocked jobs at CI server.

About "automatic time rules": we do not use time rules, i've actually no idea how it affects polling. May be you can explain how it works. I want to understand and fix this issue asap.

I think we have some special workflows and maybe some other are not covered or broken. We've used the "old" version based at 1.3.5 (pull request 9) for long time (1 year) and did not expected such problems.

Sorry for the inconvenience.

Regards,
Andre

Hello,

Well, perhaps the "plenty" was an overstatement. Sorry, I was a bit emotional, because those 2 existing issues have blocked a team of ~20 persons for a day. I'm simply concerned: if just after upgrade I've discovered 2 issues that have broken long-existing functionality, I'm not really eager to take the risk again and upgrade.

As for the automatic time rules: their description is in Advanced section of plugin configuration:

Use time rule in config spec
If checked, Hudson will use a time rule in the dynamic view's config spec, locking the view contents in as of the beginning of the build, even if files are changed on the branch during the build.

When using CC dynamic view, it's actually an essential option. Otherwise, content of the build may change during its compilation - which is very likely for team with a CI branch, the more probable, the bigger the team is.

It's mostly about adding a time rule at when updating the view's CS, eg:

time 17-sep-12.11:53:51utc+0000
[... config spec set by user - the original from Jenkins UI ]
end time

Please note also that the original CS may contain time rules, too.

I must though say that I like the new feature that allows setting config spec from file (I guess that was also part of the pull request?). I'm just very cautious and a bit afraid that perhaps there are some other changes that might not have been tested well enough: on snapshot and dynamic views, in standalone and master-slave, with Linux/Unix.

Waldek

Hello Waldek,

while I understand this can be seen as frustrating, unfortunately the clearcase plugin has a lot (too many ?) of features/options (because people have a lot of different workflows using clearcase base/ucm), so making changes CAN break some previously working stuff. Hopefully as said before, the regressions that you observed hopefully can be fixed quite easily without breaking the new features.

That said, this is open source software, I'm developping this on my (few) free time, so feedback on new releases like you did is always welcome, as long as it is done in a constructive way. I also welcome patches/pull requests, although these seem to be less frequent than complaints (how strange ).

Now it's clear to me: hasNewConfigSpec() is also called for dynamic views. We're using snapshot views only. For snapshot views there is no such feature in this plugin. I readed the ClearCase docs about "time rules" now and understand how it works. Generally time rules option can be used with snapshot views too.

I'm software developer and user of ClearCase. I'm also working on this in my free time and share it with our dev team. I spended a lot of time to understand how this plugin is working. Yes the main reason for my work and pull request are needed features for our wokflow:

• JENKINS-8305: using ClearCase plugin without config spec and load rules field (load them from files)
• JENKINS-8949: Provide list of folders and/or files for polling (lshistory)
• changeset can be generated from updt files after checkout in snapshot views

My pull request introduced some fixes and new features. It was easier for me test all things together and push at once. In future i will try to make more commits, so it should easier to merge and test.

Yes, feedback is always welcome to find the right way

Hi, Vincent
I do understand that this is open source, and I do appreciate your work. Perhaps because the plugin has been so useful and robust, I got to expect it always to be perfect I'll try to be only constructive in the future. And, thanks!
Waldek

I would like to add that I have similar issue. We are using snapshot views and from time to time I see rebuilds without reason. It says that CSPEC configured != catcs (view), but nobody actually changed cs. I'm not sure why jenkins thinks that something changed, but would it be possible to add a checkbox in plugin config to disable/enable this feature, and make it off by default?

Is there a chance for a fix for this one? This would be great, because without it, users of dynamic views (and some users of snapshots) are stuck with 1.3.8.

I've just released 1.3.11 which disables the config spec comparison if time rule is enabled. This should fix your issues.

I've finally found some time to verify the fix. Well - it works Thanks!

Is it possible this bug has been re-introduced in 1.3.14 (possibly earlier)? I am using a snapshot view, with a time-based config spec. The clearcase polling log is shown below:
Started on Jun 20, 2013 1:30:25 PM

• • • • • • • • • • • • • • • • • • • • • • • • • • • get view CSPEC ***********************
                                                      [PSoC-Programmer-Build] $ cleartool catcs -tag Jenkins_build_CMSBUILD6.cms.cypress.com_PSoC-Programmer-Build
                                                      time 20-Jun-13.13:20:25
                                                      element * CHECKEDOUT
                                                      element * .../main_pp319/LATEST
                                                      element * PP3.18_B1534
                                                      element * /main/LATEST
                                                      load \ps1_swtools\Source
                                                      ******************************************************************
                                                      [WARNING] CSPEC configured != catcs (view)
                                                      REASON: New config spec detected.
                                                      Done. Took 0.47 sec
                                                      Changes found

The build executes each time it is polled since the timestamp is different.

The same problem with dynamic views. When "Do Not Reset Config Spec" option is set and "Config spec" field empty or default.

...
[WARNING] CSPEC configured != catcs (view)
REASON: New config spec detected.
Done. Took 0.17 sec
Changes found