I created 4 group variables in GITLAB. However, when I go into the master branch CI/CD settings and go to variables I don't see the group variables. From my understanding, the branch is suppose to inherit those global variables. Does anyone know what I have done wrong? Is there a setting I missed when creating those global variables?
Thank you in advance!
According to the documentation on Group CI/CD variables here, the variables in subgroups are recursively inherited. I confirm this, we use this capacity at work.
Please, check that you are defining your variables in a subgroup and not in the major/organization group.
In addition, please verify that you are checking the variables in the supposed site. I believe that, in your situation, you are defining the variables in Gitlab itself and not in gitlab-ci.yml. Therefore, those variables should not be dependent on any branch, but on the Gitlab (sub)group and repository - independently from the branch.
Related
I would like to receive some help on how I could create some environment variables to be used in README.md within a locally hosted Gitlab instance.
I need two variables to be replaced in README.md when someone accesses the web interface, variables that define the name of the repo and the name of the branch.
Any idea is welcome.
Thanks!
I don't think you can use these variables inside a GitLab readme. There is a feature request for this but it isn't implemented yet.
A way around this is to use the predefined variables that are present in GitLab. However, these variables are accessible to GitLab's CI pipelines, and not to any readme files. But perhaps you can find a solution in this answer. It suggests that you keep a placeholder in your readme file, then have a job run that switches out the readme's placeholder with the required value using the sed command. Since the job will have access to both the readme file and the variables, this should work.
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 their document, it mentions Group, but after I check, it doesn't work as expect at all.
https://docs.gitlab.com/ee/ci/migration/circleci.html#contexts-and-variables
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:
staging-workflow:
jobs:
- staging-build:
context:
- staging
prod-workflow:
jobs:
- prod-build:
context:
- prod
I think you could achieve something similar by utilising gitlabs schedules.
Simply create two schedules that contain the variables you want to pass.
Update your ci script to reference these variables.
Then each schedule can be owned by the respective parties.
You can also limit variables by group, based on which environment. So if you have a dev env - variables can be limited for that and the same for a prod env. Hope this helps.
Finally I got this problem fixed with Gitlab CI enviroments
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.
update your variables in cicd, default is to all, change it to staging or Production.
Setting -> CICD -> Variables -> Expand
in the screenshot, I set variable AWS_ACCESS_KEY_ID two times, but assigned to different environments.
(Notes: AWS_ACCESS_KEY_ID doesn't need be masked, but AWS_SECRET_ACCESS_KEY should be)
update your pipeline to use the enviroment.
the gitlab ci 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"
I have two repositories A,B in gitlab.
I wanted to access few variables in "repo A" to "repo B" in gitlab to implement CICD. How do I do that.
You cannot share CI variables across projects unless they are under the same group and inherit its variables, please check https://gitlab.com/gitlab-org/gitlab-ce/issues/24143
As users propose on this issue, you can configure ENV variables per runner and make all jobs from different projects run on them with CI tags.
You can share enviornment variables if your repositories are in the same group.
You can find it under:
https://<your-gitlab>/groups/my-group/-/settings/ci_cd
I'd like to know if is it possible change the CI/CD variables assigned in repo settings by request. I know previously i can pass env variables by curl request to trigger the pipeline.
But now i have another situation which an automatic build and a docker image is pushed to a private registry happen when the master or dev branch suffers a merge. To do this, i use the CI/CD variables already setted.
And oftenly i will create a new registry, which it is done automatically in a bash script. After this what i'd like is setup the new keys accesses to the gitlab repo via request or other automatic way.
If someone could help me with some idea, thanks in advance.
If I am not mistaken this it what you are looking for:
Project-level Variables API
https://docs.gitlab.com/ee/api/project_level_variables.html
I can't find out how to access variables in a build-script provided by the gitlab-ci.yml-file.
I have tried to declare variables in two ways:
Private Variables in the Web-Interface of GitLab CI
Variable overrides/apennding in config.toml
I try to access them in my gitlab-ci.yml-files commands like that:
msbuild ci.msbuild [...] /p:Configuration=Release;NuGetOutputDir="$PACKAGE_SOURCE"
where $PACKAGE_SOURCE is the desired variable (PACKAGE_SOURCE) but it does not work (it does not seem to be replaced). Executing the same command manually works just as expected (replacing the variable name with its content)
Is there some other syntax required i am not aware of?
I have tried:
$PACKAGE_SOURCE
$(PACKAGE_SOURCE)
${PACKAGE_SOURCE}
PS: Verifying the runner raises no issues, if this matters.
I presume you are using Windows for your runner? I was having the same issue myself and couldn't even get the following to work:
script:
- echo $MySecret
However, reading the Gitlab documentation it has an entry for the syntax of environment variables in job scripts:
To access environment variables, use the syntax for your Runner’s shell
Which makes sense as most of the examples given are for bash runners. For my windows runner, it uses %variable%.
I changed my script to the following, which worked for me. (Confirmed by watching the build output.)
script:
- echo %MySecret%
If you're using the powershell for your runner, the syntax would be $env:MySecret
In addition to what was said in the answer marked as correct above, you should also check whether your CI variables in the gitlab settings are set as "protected". If so, you may not be able to use them in a branch that's not protected.
"You can protect a project, group or instance CI/CD variable so it is only passed to pipelines running on protected branches or protected tags." -> check it https://docs.gitlab.com/ee/ci/variables/index.html#protect-a-cicd-variable
Be aware that.. in certain cases SOME of the variables Gitlab CI CD offer are not always available..
In my case I wanted to use ${CI_COMMIT_BRANCH} but if you read the doc
https://docs.gitlab.com/ee/ci/variables/predefined_variables.html
The commit branch name. Available in branch pipelines, including pipelines for the default branch. Not available in merge request pipelines or tag pipelines.