Deploy Pull Request

[Mhm0ud]

We have an app with two branches (develop, main), and we created two env for the application (test, production).

Now, we have a lot of works and many developers contribute to this project, each one of them creates multiple PR (on develop branch), so we need to deploy each PR on a different env to let the tester test each PR before merging it on the develop branch.

I tried to create a new env for each PR and then deploy the svc into it through the GitHub actions (triggered on PR open or update), but it does not make sense because maybe each PR has a different environment variable or a new one, in this case, I can't merge the PR into the develop branch because it could have an unwanted environment variable in the manifest file.

1- What is the best practice to do that (deploy each PR on a different env with different environment variables)?
2- how to manage the environment variables between different envs (can I import from env file and change the value in the deploy step?)

[Lou1415926]

Hello @Mhm0ud !

I tried to create a new env for each PR and then deploy the svc into it through the GitHub actions (triggered on PR open or update)

To help me better understand your use case - is this because you want isolate the testing environments for each PR? I wonder if it works for you if you deploy each PR to a different service inside the same environment (say, the test environment that you've set up)?

2- how to manage the environment variables between different envs (can I import from env file and change the value in the deploy step?)

If you need your service's environment variables to be versioned by different environments (for example, for a service "my-service", you need the environment variable ENVIRONMENT_NAME to be test in the test environment, and prod in the prod environment), you can do so using manifest's environment override

For example,

variables:
  LOG_LEVEL: info

# You can override any of the values defined above by environment.
environments:
  test:
    variables:
      LOG_LEVEL: error
  production:
    variables:
      LOG_LEVEL: warning

Please let me know if this doesn't answer your second question!

[Mhm0ud]

Thanks @Lou1415926 for your response.

To help me better understand your use case - is this because you want isolate the testing environments for each PR? I wonder if it works
for you if you deploy each PR to a different service inside the same environment (say, the test environment that you've set up)?

Yes, I need to isolate the test environments for each PR.
If I create a new service for each PR and deployed it for the test env, then how can I change the environment variable for this deployment without changing the environment variable for the whole test env?

If you need your service's environment variables to be versioned by different environments (for example, for a service "my-service", you > need the environment variable ENVIRONMENT_NAME to be test in the test environment, and prod in the prod environment), you can
do so using manifest's environment override

Can I do that with dynamic variables values, for example:

environments:
  test:
    variables:
      LOG_LEVEL: $LOG_LEVEL_TEST_ENV
  production:
    variables:
      LOG_LEVEL: $LOG_LEVEL_TEST_PROD

and store the value of $LOG_LEVEL_TEST_PROD in somewhere in AWS?

[Lou1415926]

If I create a new service for each PR and deployed it for the test env, then how can I change the environment variable for this deployment without changing the environment variable for the whole test env?

Is the "environment variable" here referring to the variables you would specify through variables field in manifest?

The concept of Copilot environment is different than the "environment" in "environment variables". You usually need to create a different Copilot environment if you need to isolate the infrastructure, for example, when you need a different VPC, a different ECS cluster, etc.

The variables field maps to environment variables in container definition, and are thus isolated by containers. For example, if you have a service A and a service B, where service A has the manifest:

...
variables: 
   MY_SERVICE_NAME: A
...

and service B has the manifest:

...
variables:
  MY_SERVICE_NAME: B
...

and you deploy both service A and service B to the same "test" environment - it will work just fine. If you echo $MY_SERVICE_NAME in service A, you will get "A"; and "B" if you do the same in service B. This is because they are two different ECS services (and hence different containers).

Apologies if this is tangent to your question! Please let me know in that case 🙏🏼

Can I do that with dynamic variables values:

Right now, environment variables isn't integrated with other AWS services and need exact values as inputs. However, what you described could be achieved by the secrets field in manifeset, which maps to the secret field in ECS container definition. You can create an ssm resource, and use the resource's ARN as value for a secret. More information can be found here: https://aws.github.io/copilot-cli/docs/developing/secrets/!