Producer code:
String root = "/opt/martin"
String workspace = "${root}/${env.JOB_NAME}/${env.BUILD_NUMBER}"
node() {
    ws(workspace) {
        writeFile file: 'file.txt', text: "1234"
    }
}

Consumer code:
String root = "/opt/martin"
String folder = env.JOB_NAME.split('/')[0..-2].join('/')
String workspace = "${root}/${folder}/producer/${PRODUCER_BUILD_NUMBER}"
node() {
    ws(workspace) {
        String text = readFile 'file.txt'
        echo text
    }
}

The consumer has an input parameter called PRODUCER_BUILD_NUMBER, and that 
is of course annoying for users to type it in. What I want for this 
parameter is to give users the option to choose a producer build number, or 
if they leave it empty, the most recent successful producer build number is 
used. Finding this most recent producer build number programmatically is a 
bit of a challenge currently but in the past with freestyle jobs I have 
done it with curl. With the Workflow I would prefer to use a plugin based 
on a groovy RESTClient or the apache fluent api. If I understood how to 
return an object to the workflow (as opposed to perform a build action) 
perhaps I would be able to write a decent REST API plugin but I don't write 
plugins for a living so it would take me a lot of time to learn to do this. 
I am also aware of Jenkins Workflow - Creating a Class to Wrap Access to a 
Secured HTTP Endpoint 
<https://www.cloudbees.com/blog/jenkins-workflow-creating-class-wrap-access-secured-http-endpoint>,
 
but it uses the Global Library which is not a good long term solution yet 
as explained in JENKINS-31155 
<https://issues.jenkins-ci.org/browse/JENKINS-31155>.

Concurrent consumer builds: the workspace has to be copied before the build 
jumps into action, unless you are certain that no files will collide on 
write. For me copying the workspace is still cheaper than re-creating it 
from scratch, so I will go for a full copy. Code is TBD but the easiest is 
probably a simple unix copy inside an "sh" build step.

Martin

On Wednesday, December 30, 2015 at 5:24:26 AM UTC-5, Thomas Goeppel wrote:
>
> Hi John,
>
> your approach sounds interesting. Could you please share some Workflow 
> code that shows how you compute the Workspace location, use ws(), and pass 
> workspace locations to subsequent jobs? 
>
> When accessing workspaces in Workflow you're also facing the problem of 
> concurrent runs. How do you deal with that?
>
> Thanks in advance!
>
> Greetings,
> Thomas
>  
>
> On Wednesday, December 30, 2015 at 3:11:46 AM UTC+1, Martin d'Anjou wrote:
>>
>> On Wednesday, December 23, 2015 at 9:45:57 PM UTC-5, John D. Ament wrote:
>>>
>>> Hi,
>>>
>>> I was wondering if anyone had any best practices or tips to share on 
>>> have a common workspace for a pipeline job.
>>>
>>
>> I use Workflow job definitions, and I compute the location of the 
>> workspace in each job of the build chain before the actual build actions 
>> take place, using the ws() built step. Subsequent jobs in the build chain 
>> use the same workspace (the location can be computed). Subsequent jobs need 
>> not to be in the same workflow definition, nor in a formal pipeline (I do 
>> not use triggers nor pipeline plugins). I have enough input parameters for 
>> the subsequent jobs in the chain to locate the workspace of the previous 
>> job. I do not move nor archive data (I have thousands of files and 
>> gigabytes of data over NFS so I don't want to spend time moving it or 
>> archiving/extracting it).
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/df3d3729-603b-4e7b-acd2-228f94e20290%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to