#gocd

anyone here?

Hello.

i am having some problems with a template with two materials, ever come across that?

upon pipeline creation Go asks me for one material, then refuses to create the pipeline since a Fetch Artifact task uses a material not present

the wizard only lets me input one material then fails because two is needed

Ok, I think I see. That's tricky.

I can't think of a workaround at this point, apart from editing the XML. :(

I wonder if I can create it any other way. Just a second.

I didn't see an issue on GitHub for this

Yeah, I don't remember seeing one for this, as well. Please create one. I've never seen anyone come across this. However, this should be fairly common. Hmm.

Yeah, I thought about other ways, but everything leads to the wizard. :( So, editing XML is the only way right now.

ok

I will create an issue on GH

do you work with Go, arvindsv ?

I do. Yes.

I use the same username on github too.

so if I write in the issue that arvindsv on IRC said editing XML was the only option, whoever reads the issue would know what I meant?

You can use @arvindsv.

will do

There are others there who might know of a different way. Hopefully there is. I doubt it, though.

#986

even if there are workarounds, it should be fixed in the wizard

I see it. Thanks. I agree.

the way parameters work, that is golden.

maybe you can answer another thing as well. I have a build-->web.deploy-->test-->second.deploy setup.

by the time second.deploy came around, build had already done some more builds

second.deploy used the label {build} , and the second.deploy then got the newest label, not the same as web.deploy

if that made sense

So I was wondering when a task fetches an artifact, does it always get the newest? or the same as an upstream pipeline?

A fetch artifact task should always get the same as the upstream. Not the latest.

Are you saying you're not seeing that?

You shouldn't have to use label.

Fetch artifact task will do the resolution to the right revision.

since web.deploy, test and second.deploy all used label #{dev} (instead of {COUNT}) the second.deploy got a different label than web.deploy

since build has ran once or twice in the mean time.

If what you have is a linear setup like you said, runs should go like this (I'm not talking about pipeline labels, they're not really relevant to fetch artifact):

build/not_run -> web.deploy/not_run -> test/not_run -> second/not_run

build/1 -> web.deploy/not_run -> test/not_run -> second/not_run

build/1 -> web.deploy/1 -> test/1 -> second/not_run

build/1 -> web.deploy/1 -> test/1 -> second/1

when you have only one commit (say, "1"). If you have more commits and build runs quicker than deploy, you should see something like:

build/not_run -> web.deploy/not_run -> test/not_run -> second/not_run

build/1 -> web.deploy/not_run -> test/not_run -> second/not_run

build/1 -> web.deploy/1 -> test/not_run -> second/not_run

build/1 -> web.deploy/1 -> test/1 -> second/not_run

build/2 -> web.deploy/1 -> test/1 (running) -> second/not_run

build/2 -> web.deploy/2 -> test/1 (running) -> second/not_run

build/3 -> web.deploy/3 -> test/1 (finished) -> second/1

build/3 -> web.deploy/3 -> test/2 (running) -> second/2

... and so on.

Eventually, every run of "build" should have a run of "second.deploy". They might run at different times, and if you see them, while they're running, it'll look like they have different labels, since they're all running different instances, because of their respective times.

Finally, they should all settle down at /3. And, if you click on the label of any of the pipelines, you should be able to see that they're all consistent (meaning, the cause for /1 was an upstream /1 itself, and not a /2, unless you have setup labels incorrectly).

I might have setup it up wrong, since second.deploy has build, deploy and test all as materials.

Ok, it should still be consistent, but isn't completely linear, I suppose. I'd just setup a corresponding set of test pipelines, make a few commits and see what happens.

I think I did a manuall triggered run of second.deploy , if that makes any difference

Yes, then it's telling Go to force the latest on all dependencies.

build goes all the time, first deploy once an hour and second deploy nightly

So, what you should do, if you really want the ability to use it manually (to decide when to deploy) ...

do i need the first deploy to output an artifact for second.deploy to fetch?

… is to build a gate. :) Meaning, make the first stage a "gate". It doesn't do anything, but is used to bring all the correct upstreams together. Then, since the second stage is manual, they'll all wait. When you allow the second stage to start, then they will be consistent.

If you're using artifacts, then you can output an artifact.

However …

when you say 'then it's telling' , are you referring to a manually triggered run or since second.deploy has all previous pipelines as material?

Yes, I mean the manually triggered run.

If you click on that "play" button, then you're telling Go to pick the latest of all dependencies and run with it.

ah, ok.

Instead, you let it go ahead one stage, a dummy (gate) stage and make the second stage manual. Then, in the pipeline history page, you'll see available builds stopped at stage 2.

You can choose one and let it go through.

Then, they will be consistent, since Go started stage 1.

It would have made sure that stage 1 started consistently. You didn't force it.

If I don't touch anything and the second.deploy time trigger activates, then it will use the same build-revision that deploy used 12 hours earlier?

Hmm. I don't … remember, off the top of my head. Sorry. I can ask and tell you later. I think timer trigger honors that. But, I'm not completely sure.

ok

it would be nice to know

but I will leave the office now and will not return until september, so my coworkers would have to continue my go-ification of the build system

so the best solution would be to update the documentation if needed

Yeah, I agree.

I'll ask and update it, if I can find a reasonable place for it.

Have a fun 6 months!

Anyway, this sentence at the end of this section: http://www.go.cd/documentation/user/current/con... makes me think it'll be better to use a gate, since the documentation seems to suggest it is closer to a manual trigger, than an auto trigger.

both deploy.web and _Publish fetches artifact from Dev

I will ask them to read up on gates

Ok, I should probably write a blog post about that.

that would be great

thanks, I am looking forward to seeing what great things have happened in september