Issue Details (XML | Word | Printable)

Key: BAM-518
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Minor Minor
Assignee: Mark Chaimungkalanont [Atlassian]
Reporter: Ben Walding
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
Bamboo

Unable to copy build artifacts

Created: 05/Dec/06 04:26 PM   Updated: 29/May/07 06:26 PM
Component/s: Build Artifacts
Affects Version/s: 0.7.1
Fix Version/s: 1.1.2

Time Tracking:
Original Estimate: 4 hours
Original Estimate - 4 hours
Remaining Estimate: 4 hours
Remaining Estimate - 4 hours
Time Spent: Not Specified
Remaining Estimate - 4 hours

Environment:
Bamboo standalone,
uname -a: "Linux hostname 2.6.15 #1 SMP Sun Jan 8 20:10:15 EST 2006 x86_64 x86_64 x86_64 GNU/Linux",

java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_06-b05, mixed mode)

We have applied the patch from BAM-503

Issue Links:
Cause
 

Participants: Ben Walding and Mark Chaimungkalanont [Atlassian]
Since last comment: 1 year, 18 weeks, 5 days ago
Number of comments: 6
Internal Priority: 2. High
Internal Work Bucket: Confirmed
Labels:


 Description  « Hide
When a build completes, it's supposed to copy artifacts (as I understand it). Unfortunately this doesn't work for us - and returns an error as follows.

(Failed to copy /home/bamboo-server/home/xml-data/build-dir/APP-MAIN/output/db/classes/com/networks/db/DatabaseRuntimeException.class to /home/bamboo-server/home/xml-data/builds/APP-MAIN/download-data/artifacts/build-55/output/db/classes/com/networks/db/DatabaseRuntimeException.class due to /home/bamboo-server/home/xml-data/build-dir/APP-MAIN/output/db/classes/com/networks/db/DatabaseRuntimeException.class (No such file or directory))

Now admittedly I don't need the .class file to be copied, but it's just easier to configure that way (so I get everything), and I can't see why it wouldn't be copied.

I've checked that the .class file in question exists - and it does (I can't guarantee it exists when the copy occurs, but there's nothing magic in the build - so I'd wager it does exist).

The configuration I use in the build configuration is:

Label Source Directory Copy Pattern
output output */

Am I dumb, or is something amiss?



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Ben Walding added a comment - 05/Dec/06 04:28 PM
JIRA ate my formatting:

The copy pattern is **/*


Mark Chaimungkalanont [Atlassian] added a comment - 05/Dec/06 04:46 PM
Ben,

Something does indeed look amiss.

I think I've seen this problem before for some temporary files. i.e. the file being moved, were actually removed by another process while Bamboo was trying to copy it.

Your setup seems fine to me. A few questions

  1. Does this problem always occur? Or is it intermittent?
  2. Can you make sure that the user running Bamboo has read access o /home/bamboo-server/home/xml-data/build-dir/APP-MAIN/output/db/classes/com/networks/db/DatabaseRuntimeException.class and write access to {[/home/bamboo-server/home/xml-data/build-dir/APP-MAIN/output/db/classes/com/networks/db/DatabaseRuntimeException.class}}. I wonder if it may be a permissions thing.

Cheers,

Mark C


Ben Walding added a comment - 05/Dec/06 05:01 PM
1. I think it happens every time - I've cleared the logs out so I can't confirm that; but from memory they were appearing an awful lot.

2. Everything for the server runs as "bamboo-server".

This user has r/w access to the source file in question. They also have write access to the target directory and can write a file to this directory without any problems.

I don't think the class files are temporary - they still exist after the server has finished working and after it has complained about them not existing.

I'll try restarting the server with an strace and see if I can see where the server is looking.


Ben Walding added a comment - 15/Dec/06 03:35 AM
The stracing thing generate a bajillion gigabytes of logs, so I stopped doing that in hope of a better solution.

Interestingly, I discovered this in the log this morning:

14-Dec-2006 20:15:02 Executing build 108
14-Dec-2006 20:15:02
Starting to build 'project - Main Build'
... running command line: /opt/apache-ant-1.6.5/bin/ant -f build.xml clean compile compile-tests comprehension
... in : /home/bamboo-server/home/xml-data/build-dir/PROJECT-MAIN
... using java: /usr/java/jdk1.5.0_10
... using environment variables:
14-Dec-2006 20:15:03 Buildfile: build.xml
14-Dec-2006 20:15:14
14-Dec-2006 20:15:14 clean:
14-Dec-2006 20:15:14 [delete] Deleting directory /home/​bamboo-server/​home/​xml-data/​build-dir/​PROJECT-MAIN/​output
14-Dec-2006 20:15:14 Failed to copy build artifacts using pattern "*/"

Now why is it trying to do the artifact copy at the START of the build process?

Seems very very weird, some kind of parallelism problem perhaps?


Mark Chaimungkalanont [Atlassian] added a comment - 17/Dec/06 04:48 PM
Ben,

Looking at the code again, it does indeed look like a possible multi-threaded issue. Currently, we deal with artifacts as a build post process, which means that it's possible that another build could be kicked off before the post processes would occur. This wouldn't be such a problem with notifications and the like, but obviously is a problem with artifacts (since the files are being ripped from underneath it).

Thanks for helping us out on this. I'll see if I can patch it for 0.9

Cheers,

Mark C


Mark Chaimungkalanont [Atlassian] added a comment - 29/May/07 06:26 PM
This should finally be fixed in 1.1.2 now