How to use variables with an orb?

Deployments
,
1

Hello. I am using the codedeploy orb to deploy my application to AWS and instead of hardcoding the values in there like application-name etc, i am trying to pass variables instead but the orb doesn’t seem to be respecting the variables.

This is my code

 deploy:
    executor: aws-cli/default
    steps: 
      - aws-cli/setup:
          profile-name: my-role
      - checkout
      - run :
          name: "Set stage name"
          command: |
            stage=$(echo "${CIRCLE_USERNAME}" | tr '[:upper:]' '[:lower:]')
      - aws-code-deploy/deploy-bundle:
          application-name: "my-app-$stage-application"
          deployment-group: "my-app-$stage-deployment-group"
          bundle-bucket: "my-app-$stage-bucket"
          bundle-key: "appspec"
          bundle-type: "yaml"
          deployment-config: "CodeDeployDefault.ECSAllAtOnce"

But i am running into the following error :-

An error occurred (ApplicationDoesNotExistException) when calling the CreateDeployment operation: No application found for name: my-app- -application.

So clearly in my-app- -application the variables is not being set. any ideas on how to resolve it? Thank you.

2

The problem you are facing is a common issue.

The run command executes a shell, so any work done within the shell is local to the shell, so any environment variables defined, delete or modified within the shell only affect the shell’s environment and are lost once the shell returns.

This thread from a few years ago covers the issue

Passing variables to other steps - #5 by halfer

There are well-known workarounds for shell-to-shell variable passing, but I’m not sure how you would pass the variable up from the shell to the circleci environment, hopefully, someone else has that answer.

3

Hi @rit1010. Thank you for replying. I tried the following way after going over the link :-

command: |
            stage=$(echo "${CIRCLE_USERNAME}" | tr '[:upper:]' '[:lower:]')
            export $stage >> "$BASH_ENV"
      - aws-code-deploy/deploy-bundle:
          application-name: "my-app-$BASH_ENV-application"
          deployment-group: "my-app-$BASH_ENV-deployment-group"
          bundle-bucket: "my-app-$BASH_ENV-blue-green-bucket"
          bundle-key: "appspec"
          bundle-type: "yaml"
          deployment-config: "CodeDeployDefault.ECSAllAtOnce"

but i’m running into An error occurred (InvalidApplicationNameException) when calling the CreateDeployment operation: Application name contains invalid characters.

4

Try without the quotes as they are likely to be being passed as part of the string, rather than indicating the boundaries of the string.

You can see this in the examples provided for the ORB as no quotes are used for parameter values.

5

Hi @rit1010. Try without the quotes? You mean no quotes in the orb right?

Still getting the same error : No application found for name: my-app- -application.

6

Yes things like

deployment-config: "CodeDeployDefault.ECSAllAtOnce"
7

Removing quotes around deployment-config won’t help if i’m running into this : No application found for name: my-app- -application You can see in this error the ${stage} is still being set as blank. Thanks for looking into it.

8

OK, then we are back to the issue of environment variables not being available to the circleci application if they are created by steps being run by the circleci application.

If you must have the username converted to lowercase, have you considered just copying the code for the deploy-bundle part of the orb and making the change within its run command?

9

One possible option is to use “parameters” of a command to pass into a step, it just means you may need to shoe-horn in a command in your config. Meaning, from your workflow, call a command with a parameter, then in the command, use the parameter to set an environment variable that your step will use?

For example, my team has examples like this:

commands:

  check-security:

    parameters:
      component_name:
        type: string
        description: "A component name to use when searching for security related issues."

    steps:
      - run:
          name: Add security issues as PR comment
          environment:
            COMPONENT_NAME: << parameters.component_name >>
          command: ./scripts/perform-some-steps.sh

And that command is called from another job in a workflow like:

      steps:
        - check-security:
            component_name: "my-component"

This is a bit simplified but hopefully as a pattern that might give some ideas?

1 Like