Passing in env variables to orb jobs

Ecosystem Orbs
1

https://circleci.com/docs/2.0/env-vars/ mentions using environment in (normal) job steps:

Whether I use key / value or an array + key value, this seems to fail validation, since environment isn’t a valid param of the orb:

version: 2.1

orbs:
  bar: foo/bar@1

workflows:
  version: 2
  pipeline:
    jobs:
      - bar/deploy:
          context:
            org-global
          environment:
            - FOO: 'bar'
          target-env: blah

What’s the canonical way to allow setting env vars in an orb? Just having a passthrough parameter? Anyone have a good example of this? Alternately, I guess I could override environment for the executor instead?

1 Like
2

Correct, there’s not a great way to do this @wyardley.

If you’re making the orb, and you anticipate folks will want to pass a lot of environment variables, then you might make a passthrough parameter. That said, since we don’t currently provide a list type, or any built-in looping functionality, etc., it would be hard to make it work for multiple environment variables without creating a single parameter for each one, which isn’t ideal.

It’s worth mentioning that run steps also take environment variables, so if there’s a particular thing you want to use them for in your job, you can always use pre-steps and post-steps and set the environment variables on a run step there.

That said, if the environment variables are needed for the actual orb logic being carried out by the job, then I’d say that suggests the job should already have the requisite parameters for folks to pass it whatever environment variables it will need.

3

Got it, thanks.

And I found some basic docs, but can someone confirm how I would set a parameter for an excutor rather than a host?

Also, if I already have

environment:
  - FOO: << parameters.foo >>

Is there any way to also do a merge of an environment parameter, such that all the values in that param are merged? Or would I have to parameterize every value needed individually?

4

Also, do conditionals only work for steps? I checked, and seems like they don’t work with env.

1 Like
5

@wyardley I think you would need to parameterize them individually:

Not sure exactly what you mean, but does this help?

https://github.com/CircleCI-Public/orb-tools-orb/blob/master/src/executors/node-cci.yml#L5-L13

Basically, set parameters for an executor the same way you’d set them for any other orb object type (command, job, etc.).

Correct.

6

Basically, set parameters for an executor the same way you’d set them for any other orb object type ( command , job , etc.).

So if I have an executor bar in orb foo, with param ‘myparam’ would I do (in my actual workflow):

orbs:
  foo: myorg/foo@1
executors:
  foo/bar:
    myparam: xyz

or just (like with jobs)

executors:
  bar:
    myparam: xyz

I’ll test this out, but I’m assuming the latter?
The other problem I’m having is that I want to set an env var to the string ‘True’ but only if a param is set with a boolean true. Seems like that may not be possible?

7

Neither. A job has a single executor. It would look like this:

executor:
  name: foo/bar
  myparam: xyz
8

Sure, you can do this with Mustache templating.

myparam: <<#parameters.if-true-else>>True<</parameters.if-true-else>><<^parameters.if-true-else>>optionally, set the value you'd like if it's NOT true here<</parameters.if-true-else>>
1 Like
9

Neither. A job has a single executor. It would look like this:

So if I want to override a param for an executor, I have to do it for each job, vs. at top level?

Sure, you can do this with Mustache templating.

That works perfect more or less as in your example for my use case.
Question: Can that templating only be used in values, or could I use the Mustache templating to suppress the field from existing entirely (conditionally)? Are there any more docs about using Mustache templating inside orbs? A quick search didn’t turn up too much.

10

Not sure what you mean… What is “top level” in this case? You only ever really pass parameters to a particular instance of an executor, i.e., when it is called via a job.

You should be able to use it almost anywhere in your orb source code. I’m not sure if it’s documented anywhere in CircleCI documentation, but this is a good general documentation source:

https://mustache.github.io/mustache.5.html

I agree that it should probably be mentioned somewhere in our own documentation, though… Can you please file an issue here?

11

So, I guess I would have expected that since executors are parameterized, that I could set that parameter for all instances of an executor. Let’s say I have an executor named ‘node’ (e.g., https://circleci.com/orbs/registry/orb/honeyscience/node ) – I might want to set the version of node used for all jobs using that executor. I guess this would have been trying to get around the fact that you can’t set top level parameters for orbs themselves.

12

Not really, that’s why defaults exist though. Ideally, you set sensible defaults for your executors’ parameters, and then don’t have to pass them different values particularly often. And you can always use YAML anchors to avoid repeating things.

13

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.