Looking for Gitlab feature as Circle CI context

Replace this template with your information

In Circle CI, context can allow me to set different values for same variables.

For example, I set two environments, such as dev and prod, in each of them, I set several variables

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_DEFAULT_REGION

Since my environments are in different aws accounts, I can provide the different values to them.

Second, I can set permission that developers can only access dev context, support team can only access prod context.

But I don’t get the same feature in Gitlab CI.

In one of gitlab document, it mentions Group, but after I check, it doesn’t work as expect at all.

Contexts and variables
CircleCI provides Contexts to securely pass environment variables across project pipelines. In GitLab, a Group can be created to assemble related projects together. At the group level, CI/CD variables can be stored outside the individual projects, and securely passed into pipelines across multiple projects.

Are there any way I can do that in Gitlab CI?

Sample usage of context in Circli CI for your reference

version: 2.1

workflows:
  dev-workflow:
    jobs:
      - dev-build:
          context:
            - dev

  prod-workflow:
    jobs:
      - prod-build:
          context:
            - prod

Hi @ozbillwang

There is a variety of ways to do this. Sometimes you might want parallel:matrix but much of the time you will probably want to just use inheritance or just YAML anchors.

thanks, went through the feature of inheritance, but it can’t help a lot the inheritance is for some default variable and values, but mine are some screts, or credentials, I don’t want to set as plain text.

I’m not sure I follow you. You can add CI variables from the Settings → CI/CD section of your project. Just mark the variables that are secret as Masked and they won’t appear in pipeline logs.

so I need set two groups of below variables , one group for dev and the other for prod

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_DEFAULT_REGION

how to reference in pipeline?

Just add the variables to your project, set them as Masked, you can restrict them to different environments if you have separate variables for staging and production. Then in your .gitlab-ci.yml file you just refer to the variable by name, like any other Bash variable: e.g. $AWS_ACCESS_KEY_ID, etc.

1 Like

“different environments”? let me check. Maybe that’s what I am looking for

Finally I got this problem fixed with Gitlab CI enviroments

  1. set environments Staging and Produciton
    when it asks for url, ignore the issue, put any url you like, I just put http://example.com .

still not sure the proper url I need put in.

  1. update your variables in cicd, default is to all, change it to staging or Prod.

Setting → CICD → Variables → Expand

enter image description here

in the screenshot, I set variable AWS_ACCESS_KEY_ID two times, but assigned to different environment.

  1. update your pipeline to use the enviroment.

the environment document above confuse me again. you don’t have to provide the url, just add the environment name is enough.

staging_deploy:
  stage: deploy
  environment:
    name: staging
  when: manual
  script:
    - echo "staging deployment"
1 Like

The URL only matters if you are deploying to an environment which is accessible via a URL (for example, deploying a website). If your deployment does something else (e.g. deploys a new package to a package registry) then it doesn’t really matter. If you go to your environments page, you can access a deployment via its URL (I think), so it’s a convenience for things like that, but otherwise not important.

thanks for the confirmation.

It’s my first time to create the environment, the url is a must-set value, without put something in it, it doesn’t allow me to save the setting, I have to read and google a lot, takes me 2 hours to figure it out, any values can be accepted :laughing:

then, gitlab ci document and other pipeline I googled from public, always follow with a url when use environment in its pipeline file.

  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_ENVIRONMENT_SLUG.example.com

It makes a big trouble to me again to start using this feature. But finally I just figure out, it is a optional value, not a must-have