RE: [go-cd] shouldn't required resources also be at the pipeline level?

ources, I’m pretty sure I covered it in my earlier post so I won’t repeat myself here. Cheers, Jason From: go-cd@googlegroups.com On Behalf Of Joshua Franta Sent: July 25, 2023 02:04 To: go-cd@googlegroups.com Subject: Re: [go-cd] shouldn't required resources also be at the pipeline level? sem

Re: [go-cd] shouldn't required resources also be at the pipeline level?

semantics in a broad sense of arguing something not relevant to the thread. everybody who responded said something meaningful to them, no doubt there. I'm pretty sure it's not a good idea to introduce logic based on the name of a variable and not it's content. (obv not the same as saying it's not

Re: [go-cd] shouldn't required resources also be at the pipeline level?

Yeah, just semantics.  Like you can't know the parameters "name" or anything like that in the script itself, or do things like "iterate on all parameter names" - you can only know their injected *value*, so if you want to make logic depend on a parameter's name, you have to assign it to a local

Re: [go-cd] shouldn't required resources also be at the pipeline level?

yes- i'm aware that parameters are replaced before the script is written into the agent and executed. while it's correct that scripts don't know where the information inside them comes from, this is true for any script not just ones used by gocd. perhaps these are more semantic level points. eg i

Re: [go-cd] shouldn't required resources also be at the pipeline level?

On Mon, Jul 24, 2023 at 10:44 AM Chad Wilson wrote: > On Mon, Jul 24, 2023 at 8:44 PM Joshua Franta wrote: > >> >> chad thanks for your answer. >> >> i think the main source of confusion is that I thought parameters could >> only be referred to in scripts! >> I didn't know you could refer to

Re: [go-cd] shouldn't required resources also be at the pipeline level?

If you read Jason's message a bit more closely he is conveying that the script's runtime environment has no knowledge of the parameters - not that they can't be used at all. They are just tokens that have already been 'realized' or replaced into the content by the time the script/task runs. So

Re: [go-cd] shouldn't required resources also be at the pipeline level?

Jason, your knowledge here is off. Parameters can be used in scripts, see a previous email I this thread that shows how it works. On Mon, Jul 24, 2023, 4:11 PM Jason Smyth wrote: > Hi Josh, > > I think there may be some confusion here regarding GoCD terminology and > common concepts. > > > i

Re: [go-cd] shouldn't required resources also be at the pipeline level?

Hi Josh, I think there may be some confusion here regarding GoCD terminology and common concepts. > i think the main source of confusion is that I thought parameters could only be referred to in scripts! > I didn't know you could refer to them inside of other configuration properties! To the

Re: [go-cd] shouldn't required resources also be at the pipeline level?

On Mon, Jul 24, 2023 at 8:44 PM Joshua Franta wrote: > > chad thanks for your answer. > > i think the main source of confusion is that I thought parameters could > only be referred to in scripts! > I didn't know you could refer to them inside of other configuration > properties! > Is this

Re: [go-cd] shouldn't required resources also be at the pipeline level?

On Mon, Jul 24, 2023 at 8:44 PM Joshua Franta wrote: > > chad thanks for your answer. > > i think the main source of confusion is that I thought parameters could > only be referred to in scripts! > I didn't know you could refer to them inside of other configuration > properties! > Is this

Re: [go-cd] shouldn't required resources also be at the pipeline level?

chad thanks for your answer. i think the main source of confusion is that I thought parameters could only be referred to in scripts! I didn't know you could refer to them inside of other configuration properties! Is this documented? Regardless that's super useful, there's probably some other

Re: [go-cd] shouldn't required resources also be at the pipeline level?

With that description, if you want to use *environments * rather than resources (and assuming you don't use environments for any other purpose), I

Re: [go-cd] shouldn't required resources also be at the pipeline level?

You would have agents on the various machines, tag the agents with specific resource tags, and tag specific jobs with those resource tags. — Sriram On Sun, 23 Jul 2023 at 8:21 PM, Joshua Franta wrote: > appreciate so many responses. i think we're a little apart so i'll take > the suggestion

Re: [go-cd] shouldn't required resources also be at the pipeline level?

appreciate so many responses. i think we're a little apart so i'll take the suggestion to give our example: GROUPA = machines that have less beefy hardware GROUPB = more expensive machines we'd like to: 1. have a couple of pipelines only run on the more expensive machines 2. have all

Re: [go-cd] shouldn't required resources also be at the pipeline level?

Taking another stab after Chad at answering the following question, > We have some pipelines that are given higher preferences for agent/build resources. Wanting to do a lot more of this, but it's tricky because resources can only be defined at the job level (in the UI). Also we use a lot

Re: [go-cd] shouldn't required resources also be at the pipeline level?

On Sat, Jul 22, 2023 at 8:21 PM Joshua Franta wrote: > re: using environments rather than resources... environments can't be > defined at the pipeline level either though? > A pipeline is *assigned* to 0 or 1 environments (via the Admin > Environments UI if not using pipelines-as-code) - thus

Re: [go-cd] shouldn't required resources also be at the pipeline level?

thanks ashwanth- we already use parameter a ton. i don't understand how a job could look at a parameter and force the job to a more capable agent. i can definitely have a job fail based on a pipeline level parameter, but obviously trying to keep everything green here. if you're sure it's

Re: [go-cd] shouldn't required resources also be at the pipeline level?

chad, thx for your reply. re: using environments rather than resources... environments can't be defined at the pipeline level either though? or i guess it's more correct to say that using environments is a bit of a side-car feature, in that we use interact w/environments through a different

Re: [go-cd] shouldn't required resources also be at the pipeline level?

Use Parameters. On Sat, Jul 22, 2023, 16:24 Josh wrote: > QUESTION: > > Shouldn't we also be able to communicate a resource requirement at the > pipeline level, and not just inside a single job? > > I get that it definately needs to be at the job level since that's the > smallest unit of work

Re: [go-cd] shouldn't required resources also be at the pipeline level?

Have you tried to use "environments" (or a mix of environments and resources) to achieve what you are trying to? When scheduling jobs it's the combination of the resource and the environment that are matched to an agent, but the relevant environment is declared at the pipeline level like you

[go-cd] shouldn't required resources also be at the pipeline level?

QUESTION: Shouldn't we also be able to communicate a resource requirement at the pipeline level, and not just inside a single job? I get that it definately needs to be at the job level since that's the smallest unit of work and some machines can't execute certain tasks. But at the