Finally having time to dig deeper into this I spotted in the cruise-output's console.log ?1 (ie. the task's exit code)
*!!|13:21:11.250 [go] Task: /bin/sh -xvc "ls -altr"?1|13:21:11.268 [go] Task status: failed (16 ms)* Ok, that explains why GoCD treats the task as failed, however: it doesn't give info on why the exit code is 1 rather than 0 for the command. Only for this task in this pipeline on this agent... "Only for this task in this pipeline on this agent"* - *this and the fact that these commands are not exactly "exotic" either, I turned towards the pipeline's environment variables. None stood out immediately, but I ended up spotting that I had one of the secure variables (we make use of https://github.com/tomzo/gocd-json-config-plugin) down as... *{* * "name": "SECURE_VARIABLE",* * "encrypt_value": "ENCRYPTEDPLAINTEXTVALUE <https://api.gocd.org/current/#encrypt-a-plain-text-value>"* *}* instead of: *{* * "name": "SECURE_VARIABLE",* * "encrypted_value": "ENCRYPTEDPLAINTEXTVALUE <https://api.gocd.org/current/#encrypt-a-plain-text-value>"* *}* ...talking about some red herrings - I had a schoal of them on this issue, but eventually got the build going. Thanks André, Ketan and Aravind for your help! Have a great weekend, David 2018-04-20 14:31 GMT+01:00 David Joos <[email protected]>: > Hi André, > > the task on this job/pipeline just doesn't run any command successfully, > without a trace of why not... > [go] Task: /bin/sh -c "ls -altr" took: 0.16s > [go] Task status: failed, took: 0.16s > *INFO [loopThread] CommandLine:366 - Running command: /bin/sh -c ls -altr* > *INFO [loopThread] DefaultGoPublisher:99 - Agent [my-agent, > XXX.XXX.XXX.XXX, my-agent] is reporting build result [Failed] to Go Server > for Build [qa_project/1/prepare/5/package/270]* > > Running ls -altr in the respective folder from the CLI on the agent all > looks fine... It also is no problem at all in other pipelines, similar > behaviour as described before. > > Any ideas on further logs/tools available to debug/inspect this odd > behaviour? > > Thanks in advance! > David > > > > 2018-04-20 13:59 GMT+01:00 André Neves <[email protected]>: > >> First thing I usually do when using certains files reported as not >> accessible or a command that fails which depends on the previous job is to >> do an ls command to see what is my current content and folder structure. >> I've configured a dummy set of pipelines I have on my DEV environment in >> order to reproduce what you have stated. I've even added more complexity by >> publishing it as an artifact and fetching that artifact on another pipeline >> and uncompressing the file there and I couldn't reproduce the issue you are >> facing. Usually the job output in the "console" on GoCD UI is enough for >> the basic problems. >> >> Just do an extra job and configure it's command as "ls" and it's >> arguments as "-altr" without anything extra. What does it outputs? >> >> -- >> You received this message because you are subscribed to the Google Groups >> "go-cd" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "go-cd" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
