Perhaps my suggestion wasn't so clear? I wasn't referring to use of *environment variables* - I was referring to assigning pipelines to GoCD logical environments (which can contain env vars for use during tasks) since a config repo can restrict which logical environments it refers to. https://docs.gocd.org/current/introduction/concepts_in_go.html#environment and https://github.com/tomzo/gocd-yaml-config-plugin#environment
As Aravind mentioned at https://github.com/tomzo/gocd-yaml-config-plugin/issues/160 environment *variables* are a task runtime concept, not something at config time. Similar to what was discussed at https://github.com/gocd/gocd/issues/10843 However, after a little bit of digging, I think my original suggestion will not work, as after a bit of digging, I concluded that even if you restrict the "logical environments" that an elastic agent registers for (e.g by manually setting GO_EA_AUTO_REGISTER_ENVIRONMENT=app-a-build in the Elastic Profile) I think anything you set there will get overridden by GoCD when the elastic agent is started, and set to whatever environment the pipeline *needs* - which would defeat the control purpose you are trying to achieve here. So to support this, we probably would need to implement https://github.com/gocd/gocd/issues/10864 as raised by you already. -Chad On Wed, Sep 28, 2022 at 11:52 PM X-Cloud Lab <[email protected]> wrote: > Thanks @Chad. I also tried this to create an agent profile with token i.e. > app-a-build-agent-x9ym36re and store the agent profile name in GoCD's > environment. > > Then, I can config the environment permission for each config repo. > However, elastic_profile_id in YAML file cannot refer to environment > variable. > elastic_profile_id: "${env:AGENT_NAME}" or elastic_profile_id: > "$AGENT_NAME" or elastic_profile_id: "${AGENT_NAME}". > > Those always show an error in Config Repository page. By the way, it > stills can echo to get the agent name. > > On Wednesday, September 14, 2022 at 11:28:00 AM UTC+7 Chad Wilson wrote: > >> I haven't thought this through in detail however it might be possible to >> use GoCD's 'environment' concept to achieve this if different teams have >> different config repositories they have permissions on. >> >> You can restrict which environments a given config repository has >> permissions to link pipelines to in its permission configuration. >> >> I think (but need to double check) that you can also change elastic agent >> profiles so the elastic agents only register for particular environments >> using environment variables for the container (rather than any/all/no >> environment by default). That'd require different elastic agent profiles >> for different teams (or environment groupings) which it sounds like you >> have already. >> >> If this approach works, team A would have to link their jobs to an >> environment in their YAML config. They *could* refer to a team Bs profile >> in their job YAML, but when the instance starts up it wouldn't register for >> the correct environment their pipeline is assigned to and the job wouldn't >> get assigned. >> >> So it wouldn't prevent 'wasted elastic agent starts' due to misconfig but >> should prevent agent B from running team A's pipelines. >> >> Can you perhaps experiment with environments and the agent >> auto-registration environment vars and see if that approach works for you? >> >> -Chad >> >> On Sat, 10 Sep 2022, 00:06 X-Cloud Lab, <[email protected]> wrote: >> >>> Hello, >>> >>> I'm using GoCD EKS v22.1.0. I'm using it to run IaC on AWS. >>> >>> I create an EKS cluster and create each profile for each squad team. >>> I also using gocd-yaml-conflig plugin to write pipeline as codes from >>> GitLab. >>> So, the developers can write their own pipelines and using the elastic >>> agent based on their profile. >>> >>> For example, app-a-build-agents profile is for app-a squad team. >>> >>> My question is how to prevent other squad team to use app-a-build-agents >>> profile. >>> The other squad can configure their pipeline to use app-a-build-agents >>> profile to configure AWS resources on Squad A AWS account. >>> This could be mistake or intend to do that. >>> >>> Does GoCD has a mechanism to prevent this behavior? >>> >>> Regards, >>> Worapoj >>> >>> -- >>> 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]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/go-cd/d6995a9a-da40-47cd-8306-a6af1e433bc9n%40googlegroups.com >>> <https://groups.google.com/d/msgid/go-cd/d6995a9a-da40-47cd-8306-a6af1e433bc9n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/go-cd/9722081b-e9a4-4a6f-998a-fca2742e3e12n%40googlegroups.com > <https://groups.google.com/d/msgid/go-cd/9722081b-e9a4-4a6f-998a-fca2742e3e12n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/CAA1RwH-t-jxDqb9Q%3D6JiyHQ23ShG%3Dh3dqf20_ci4veBsjnC0eg%40mail.gmail.com.
