gocd: Saved Pipeline artifacts do not maintain mod flags when fetched

If you have a pipeline that saves an artifact for use in other pipelines, the flags on the files are not maintained, in particular the executable flag.

We have several jobs that generate common artifacts, for example the output from bundle install, that are then used in other piplines. We do this as the bundle install can take a long time and is not necessary to run on every build.

The issue is the when the output from a bundle install is passed to another pipeline, none of the executables can run because the executable flag is reset. We tried running bundle install --binstubs bin on the downstream pipeline to ensure the binaries where available but there is still issues with other modules that need the correct permissions.

The current solution is to have the upstream Pipeline tar the relevant directory and the downstream one untar. Seems a bit silly when that is exactly what the save artifact functionality does anyway.

About this issue

Original URL
State: closed
Created 10 years ago
Reactions: 1
Comments: 15 (4 by maintainers)

Most upvoted comments

Any updates about this issue ? I’ve been struggling with this for whole day (I blamed git at first and added checkout tasks) until I realized it was when I fetch my artefacts that permissions where gone… Suggested workaround does not fit my case, I ended up adding a task that chmod required scripts… quite an ugly fix

j-ledoux on Apr 26, 2017

+1, should really be adressed in the next release. Work-around is described here: http://stackoverflow.com/questions/22168557/thoughtworks-go-changing-artefact-file-permissions

marcelboettcher on Aug 25, 2015

@helmesjo You’re right, it should. However, no one is currently looking at it, as far as I know. 😦 I’ll put some more thought into how this can be made compatible with the existing zip implementation - since this will have to be controlled from the server side while the agents are the one that are doing the actual zipping.

This is not likely to be picked up soon, though. For the short term, your best best will be to tar the directory before upload and upload the tar file as the artifact and untar when fetching:

<tasks>
  <exec command="tar" args="cvf artifact.tar artifact-dir/" >
    <runif status="passed" />
  </exec>
</tasks>
<artifacts>
  <artifact type="build" src="artifact.tar" dest="my-artifacts" />
</artifacts>

Considerations (for me to think):

The performance profile of agents tar-gzipping vs. zipping [big and small artifact dirs]
Ideally, this is a flag turned on at the server side, which propagates to the agents - so that this change can be made with lesser risk.

arvindsv on Aug 30, 2018

+1 Any updates? I don’t like having dodgy work arounds

nikskiz on Aug 10, 2018