can't use dedicated envVars for singular garden command within workflow

[jrnxf]

Bug

Current Behavior

As far as I can tell, there doesn't seem to be a way to pass a single environment variable to one specific workflow command. In other words, I don't want the variable for the entire workflow, just one command. Which means I can't use command and have to use script

  - description: Generate environment file using `garden generate-env-file ${environment.name}`
    script: POCUS_GARDEN_ENVIRONMENT=setup garden generate-env-file "${environment.name}"### Expected behavior<!-- A clear and concise description of what you expected to happen. -->

  - description: Generate environment file using `garden generate-env-file ${environment.name}`
    envVars: 
      - POCUS_GARDEN_ENVIRONMENT: setup
    command: [generate-env-file, "${environment.name}"]^^ maybe something like this?### Workaround

I think I just have to use script for now or break it out into it's own workflow which seems messy

Your environment

• OS: MacOS Monterey 12.6 (2021 M1 Pro)
• How I'm running Kubernetes: Docker Desktop

garden version 0.12.44

[vvagaytsev]

Thanks for reporting this @thatvegandev! We'll take a look.

Actually, this looks more like a feature request, not a bug. The envVars are already supported, but only with the scripts, not with commands. The envVars description says:

A map of environment variables to use when running script steps. Ignored for command steps.
Note: Environment variables provided here take precedence over any environment variables configured at the workflow level.

So, something like this should work fine:

- description: Generate environment file using `garden generate-env-file ${environment.name}`
  envVars: 
      - POCUS_GARDEN_ENVIRONMENT: setup
  script: garden generate-env-file "${environment.name}"

I'm wondering why command ignores the envVars. @thsig do you know why we did it in such a way?
Maybe we should propagate envVars to command too.

[jrnxf]

@vvagaytsev could you speak to any underlying differences between command and script? I know command is only meant for garden commands, but is there any reason I should use

command: [run, task, xyz]

vs

script: garden run task xyz

The reason I ask is because my team and I have seen really really slow execution times when running garden commands via script. I think it might be a logging issue. I can try to get you more information on this if this sounds new to you.

Also, one final question. In the docs it says "Not all Garden commands can be run in workflows, and some option flags are not available. Please see the command reference to see which commands are supported in workflows.", but then the command reference doesn't say which ones are supported. Are all of the commands listed supported?

[vvagaytsev]

@thatvegandev thanks for the question, I'll check it with the teammates.

@thsig @edvald what's the main diff between using command and script with Garden commands? Does script always spawn a new OS process to run another instance of Garden? That can explain the slowness.

We definitely need to update the documentation, I'll try to figure out which Garden commands are not supported in the workflows.

How about passing envVars to command in the workflows? That looks like a valid case.

[edvald]

Using script does indeed spawn a full new process, which is generally slower. There are cases where that's necessary though. Overriding environment variables essentially does necessitate that, since you'll anyway need to re-evaluate configuration. We had done a cursory look into further optimization but that would take some doing, so we hadn't dug into it further.

[stale]

This issue has been automatically marked as stale because it hasn't had any activity in 90 days. It will be closed in 14 days if no further activity occurs (e.g. changing labels, comments, commits, etc.). Please feel free to tag a maintainer and ask them to remove the label if you think it doesn't apply. Thank you for submitting this issue and helping make Garden a better product!

[vvagaytsev]

Closing this as stale. Feel free to re-open if it's still a blocker.