No way to revert modifications in checkout?

[kf-jstatz]

Maybe I missed it, but it would be nice to be able to ensure nothing is changed locally. We're building a Unity project and occasionally someone might end up opening the project manually on the build machine, and some minor things like materials/etc may end up modified. As a general case I'd like to be able to ensure nothing locally is changed when running a Jenkins build, however it might have happened.

[mig42]

Hi @kf-jstatz!

The checkout operation first cleans the workspace and then performs a workspace update to download the appropriate contents. That first clean step means undoing all checked-out and locally change files in the workspace. You can see it in action in method CheckoutAction.checkoutWorkspace() here.

plasticscm-plugin/src/main/java/com/codicesoftware/plugins/hudson/actions/CheckoutAction.java

Line 51 in 0449a50

WorkspaceManager.cleanWorkspace(tool, workspace.getPath());

So, I'd say your scenario is covered: if anyone perform changes in the Jenkins workspace, Jenkins would then revert those changes when a new build is triggered.

Did you verify this?

Thanks!
Miguel

[kf-jstatz]

Okay, no, you're probably right and we haven't noticed any problems. Nothing in the documentation called this out though and we started looking for commands to do it explicitly, not realizing this behavior existed. Cool, works for us I guess. Sorry to bother you!

…

On Thu, Apr 2, 2020 at 1:55 AM Miguel ***@***.***> wrote: Hi @kf-jstatz <https://github.com/kf-jstatz>! The checkout operation first cleans the workspace and then performs a workspace update to download the appropriate contents. That first clean step means undoing all checked-out and locally change files in the workspace. You can see it in action in method CheckoutAction.checkoutWorkspace() here <https://github.com/jenkinsci/plasticscm-plugin/blob/0449a500d35a39da22ee585a2d87340beaa94dfb/src/main/java/com/codicesoftware/plugins/hudson/actions/CheckoutAction.java#L51> . So, I'd say your scenario is covered: if anyone perform changes in the Jenkins workspace, Jenkins would then revert those changes when a new build is triggered. Did you verify this? Thanks! Miguel — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEHUKVRICBUY2JXYPNXOK6DRKRAHVANCNFSM4L2CRC2Q> .

[mig42]

No worries 😄

You're right, there's no mention of it in the documentation! I'll leave this issue open until we update the docs. I'm happy to hear that there isn't any actual problem though!

Regards,
Miguel

[knapsu]

Hi. It all depends on the modifications that are done on the build node and how the build is actually being done.

1. If the file is modified in the workspace (tracked change) then it would be reverted by default.
2. If a file is added to the workspace (not tracked change) it would not get discarded. This can lead to problems on subsequent runs.
3. Sometimes the intermediate build files that were put in ignore.conf could be causing issues . Cleaning those might sometimes be needed.

I had a type 2 case with Unreal where some extra files needed to be present to make a specific build. Unfortunately as the cleanup was not done completely it was causing incorrect builds on subsequent runs on this Jenkins agent node.

Type 3 case also happened few times for me. Going to each agent node (had 7 of those) and manually doing a cleanup was very tedious.

A potential workaround for this problem was running custom cleanup command after workspaec synchronization. In pipeline script it would look like this:

bat script: """
    @cd workspaeDir
    @cm rm private -r .
    @cm undocheckout --all --silent .
"""

The good thing is that in pull request #30 branch there are improvements that allows to specify a cleanup method, how deep it should revert the workspace. I am using this on production for more than a year now.

[mig42]

As I said in my previous comment, I added a mention in the README to let everyone know that the Plastic SCM checkout undoes all changes in controlled items before running updates.

Closing the issue now!