Understanding "Force Clean Build" under Source Code Checkout

[Heena Agrawal]

I selected "Force Clean Build" under my Source Code checkout task because I want Bamboo to checkout the fresh source code every time it creates a build. (Our binaries have SVN information embedded in them and if its not  fresh checkout then the SVN revision number gets embedded with an 'M' signifying a modified copy of subversion source code.)

However, with "Force Clean Build" option, the first manual run worked perfectly but after that the "Source Code checkout" task fails every time. Following is the log :

I also tried going to the path mentioned in the log on the remote server but C:\rw_apps\Bamboo-Home\xml-data\build-dir\GLUB-GLUS116-BAG this folder seems empty. Looks like Bamboo is not able to checkout the source code anymore. Since the task failed, even manual clean ups and SVN updates are not working.

Any suggestions?

[Victor Debone · Accepted solution]

Hello @Heena Agrawal

It seems that there is some process locking the folder clean-up. What version of Bamboo are you running? 

The folder seems empty because usually the folder `.svn` is treated as a hidden folder and will not be displayed without extra steps.

Also, you could try to clean working directory after each build. There is a special option for that under "Plan Configuration > Stages > [Select the stage] > Miscellaneous tab".

Did it help?

Victor

[Heena Agrawal]

Hello Victor.

Thanks for the reply.

We are using Atlassian Bamboo version 6.5.1

I tried setting up clean working directory fro miscellaneous tab but I received the following error. (Also I unchecked "Force Clean Build" since its only working the first time you try to create a build and then it makes all the other builds crash. Is it because of the "SVN cleanup" that is getting locked?)

Does this sound familiar?

[Heena Agrawal]

It looks like this is the same issue:

https://jira.atlassian.com/browse/BAM-16620

It shows resolved but I am experiencing this issue. Can you please let me know any work around for this?

Thanks!

[Victor Debone]

We have a similar bug already created https://jira.atlassian.com/browse/BAM-19597, and the workaround for it is to restart Bamboo. If that is not possible, you could try to manually delete the folder or through a "Script Task" run the removal of folder.

If that will not help you, I recommend contacting our support so we can investigate this issue further.

Victor

[Heena Agrawal]

Do you mean removing " C:\rw_apps\bamboo-home\xml-data\build-dir\GLUB-GLUS116-BAG" folder or the ".svn" file from thee folder?

Also, the workaround suggested in https://jira.atlassian.com/browse/BAM-16620 uses in a script before source code checkout.

attrib -R /S %bamboo_build_working_directory%/*

Is this only applicable to git repositories? What is the similar command for subversion?

[Victor Debone]

This workaround with the script removes the "Read-only" flag in all the files in your `C:\rw_apps\bamboo-home\xml-data\build-dir\GLUB-GLUS116-BAG` directory. It's a Windows Command Prompt command, so it will work regardless of the VCS you are using :)

[Heena Agrawal]

Thank you for answering all these questions.

I think my problem is that even if I go into my remote agent inside this folder " C:\rw_apps\bamboo-home\xml-data\build-dir\GLUB-GLUS116-BAG" and try to delete the .SVN file manually, its not getting deleted. I unchecked the "Read only" from properties but still the message shows that some other task is using that file and so you cant delete it.

Now, what I have had to do is restore the "GLUB-GLUS116-BAG" folder to a previous setting and then run builds from there but its not possible to do it manually every time for each build.

Would you know why that .svn is getting locked?

[Victor Debone]

You're welcome!

The .svn folder getting locket appears to be related to Windows file locks, and it requires that the process holding the lock to be freed, which in our case is Bamboo and might be related to the bug I've previously mentioned BAM-19597.

As you unchecked the "Read only" property, the workaround of running the `attrib` command also will not work, and I understand that it's not possible to do manual steps for every build, I recommend you to open a support case so we can investigate further what other options we can explore, with more detailed information on your environment. Make sure to mention this steps explored (or link this post).

Victor

[Heena Agrawal]

Thank you for your help Victor. I will add a support request. Just trying to figure out what our SEN is.