BAMBOO: Why do artifacts in folders from Linux agents display differently than from Windows agents

[David R. Cattley]

In a mix of build agents with both Linux based and Windows based agents, when an artifact is serialized from a Linux agent and that artifact copy pattern has "/**/" (path) matching in it the resulting artifact displays in the Bamboo UI as a link with an icon of a folder.   One must click into that folder and into every descendant folder until the artifact file is located.

When that same Job runs on a Windows agent and the same artifact is serialized, the Bamboo UI shows the artifact as a long URL that directly resolves (one click) to downloading the file.

Why the difference?

Is this something that can be controlled?

FWIW this is version 5.14.1.  The server runs on Linux.   Only the agents are a mix of Linux and Windows.

[Edwin Kyalangalilwa]

Hi @David R. Cattley,

Try using a copy pattern that includes the file extension

**/*.jar

 This should return the file itself. ** - matches any number of levels

[David R. Cattley]

Thanks for that suggestion.

However, I actually want to capture a number of files that are the descendants of a path match such as  **/foo/*.*

So it is appropriate in some sense for this to be captured as a "folder".

What is odd (to me anyway) is why the choice of agent OS has anything to do with how this is rendered in the WebUI of Bamboo.

[Edwin Kyalangalilwa]

Yes that's very odd. It seems they are displaying the paths differently based on the OS or it might be an OS specific issue. I'll look more into this for you.

Are the artifact files being deployed together?

[David R. Cattley]

>Are the artifact files being deployed together?

I'm not sure exactly what you mean but I can tell you the following:

• When used as Shared Artifacts the full set of files does flow into subsequent Jobs as expected in either case (Linux or Windows -> Linux or Windows).
• When accessed via sufficient clicking-through on Linux, all of the artifacts expected are present and can be downloaded.

I am not using an associated Deployment Plan and thus do not know what the behavior might be with respect to artifact flow in that regard but I would expect that since it works via Shared Artifacts Stage/Job -> Stage/Job then it probably works to a Deployment Plan.

[Edwin Kyalangalilwa]

Gotcha! I was talking about the Artifact download deployment task. You select which artifact to deploy, so i was wondering whether all files were being deployed. But i understand about the subsequent jobs.

[Troy Knapp]

I ran into this problem as well. In my case there was an associated deployment project and artifact download task. The files were downloaded to my agent like the following:

The file names built in windows were being interpreted as strings on the Linux OS. I imagine that instead of the Bamboo artifact being stored as a series of files in folders, each file name is being stored as a string that gets interpreted by the agent's OS into a given file/folder structure... Therefore, the artifact as built on a windows agent is incompatible with a *nix agent.

So steps to reproduce would be as follows:
1) Using 7.1.1 build 70117, set up a windows agent to download a complex git repo
2) save this repo as an artifact
3) have a unix build agent download the artifact

In the above example I just have a stupid simple build/deployment for a helm package to a k8s cluster w/ redis commander so the build/deploy steps are rather trivial.