In my .gitlab-ci.yml i'm trying to deploy on merge request.
My pipeline works, script is executed , everything is ok and running , but i'm not able to read any predefined environment variables. My files looks like :
executeAutomationTests:
stage: check
only:
refs:
- merge_requests
script:
- echo $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME
But $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME is not resolved. I need to know source branch for the merge_request in order to pull the code and make a deployment. I have tried other variables like : $CI_COMMIT_REF_NAME, $CI_JOB_STAGE , but non of them are resolved.
My GitLab version : GitLab Community Edition 13.4.2
The problem was that in the pipeline job monitor the variable wasn't resolved and that's confused me. It was looking like :
So, for anyone who is fighting with such things, keep that in mind and also, keep in mind differences in syntax between powershell , bash and so on ..
Related
I have a gitlab job that does not seem to update the repository before being run. Sometimes it leaves some files in their old states and run the script... Any idea ?
For instance when I have a
packagePython:
stage: package
script:
- .\scripts\PackagePython.ps1
tags:
- myServer
cache:
paths:
- .\python\cache\
only:
changes:
- python/**/*
I finally managed to understand what was happening :
I realised that the gitlab-runner did not use exactly the same path for each run on my server, and my script assumed that it did... So I ended up pointing on a build made on the wrong path.
I guess if you think that it is not updating the repository (like I did) make sure you are not referencing hardcoded path/package in your scripts that could refer to previous versions !
I've been trying to get more familiar with GitLab's CI functionality and find the idea of splitting up a CI pipeline into multiple separate jobs interesting. This would allow me to maintain one project of "known jobs" and include them in other projects.
So far, I have something like this:
$ ls
jobA.yaml jobB.yaml jobC.yaml jobD.yaml
Those 4 are all identical (for now), and have the following:
job-name:
stage: my-stage # Might be needed to differentiate later on
tags: runner-tag # used to figure out where/how the job should be done: directly on a server, in a container, etc
script:
- echo "beep beep"
In the actual .gitlab-ci.yaml I want to use, I would then (I think) put something like this. In this case, I would use the jobs defined in the project for itself:
include:
project: '$CI_PROJECT_PATH'
file: "*.yaml"
stages:
- my-stage
That gives me back a linter error though. Perhaps I'm misreading the documentation, but I think that should be possible somehow....
This should be a comment, but can't put formatted code in there..
We use a main yml, which just include all the others. It is not wildcards like you have.
Have you tried changing "file" to "local"? with the leading "- "?
include:
- template: Code-Quality.gitlab-ci.yml
- local: '/.gitlab/py.yml'
- local: '/.gitlab/static.yml'
- local: '/.gitlab/lint.yml'
- local: '/.gitlab/docs.yml'
- local: '/.gitlab/publish.yml'
According to the docs, wildcard includes are only possible with local. Furthermore you need to move your jobA.yaml to a directory as otherwise you will include your .gitlab-ci.yml as well with a wildcard on the top level.
So the following works with JobA.yaml in config:
include:
- local: 'config/*.yaml'
stages:
- my-stage
I have a problem executing a pipeline in azure devops.
This task is part of my pipeline, as you can see it is an instruction to clone a repository.
- script: |
mkdir FOLDER_PUBLISH_AZURE
git clone https://$(AZURE_DEPLOY_USERNAME):$env:MY_AZURE_DEPLOY_PASSWORD#develroomlabs-events.scm.azurewebsites.net:443/develroomlabs-events.git FOLDER_PUBLISH_AZURE
workingDirectory: '$(System.DefaultWorkingDirectory)'
displayName: 'Download SCM repo for pipeline '
env:
MY_AZURE_DEPLOY_PASSWORD: $(AZURE_DEPLOY_PASSWORD)
The result I get is as follows:
But the pipeline variables are well added, I did a test by directly adding username and password in the YAML file, but the result was the same.
What could be happening? Am I doing something wrong?
I do this same task of cloning a repository from a bitbucket pipeline and I have no problems.
Try doing that in Windows environment with Microsoft-hosted windows agents instead of Micorosft-hosted Linux agents.
I can reproduce same issue when using Linux environment, but it actually works well in windows environment. I think this issue could be related to that Linux has different behavior when treating url format like https://$AppName:xxx#sAppName.scm.azurewebsites.net:443/AppName.git...
(Something looks like this ticket,the behavior should have something to do with Linux server itself)
I have an issue with kubernetes variables not set in Gitlab-CI.
There's another issue, but it talks about the "old" integration, not the latest that works differently.
So here's the thing. I have a free account, and a kubernetes cluster configured. Everything works fine, the cluster is correctly configured, Helm Tiller, Prometheus and Gitlab-CI-Runner have been installed, and the runner is used to execute the jobs.
Since it's a free account, I can add only one cluster with a * scope, and the documentation says that the following variables should be available through any job:
KUBE_URL
KUBE_TOKEN
KUBE_NAMESPACE
KUBE_CA_PEM_FILE
KUBE_CA_PEM
KUBECONFIG
But none of them are set, the following job echoes nothing, except the CI_PROJECT_ID:
build_backend:
stage: build
except: [ tags ]
script:
- echo CI_PROJECT_ID=$CI_PROJECT_ID
- echo KUBE_URL=$KUBE_URL
- echo KUBE_CA_PEM_FILE=$KUBE_CA_PEM_FILE
- echo KUBE_TOKEN=$KUBE_TOKEN
- echo KUBE_NAMESPACE=$KUBE_NAMESPACE
- echo KUBE_CA_PEM=$KUBE_CA_PEM
- echo KUBECONFIG=$KUBECONFIG
I was not able to find any lead (except the obsolete issue referenced above), but as it's quite recente, I could not make the difference between it has not been tested yet or I'm the only one having the issue
Thanks for any help!
Ok, I can confirm this is a duplicate of this and that the provided solution does indeed work.
Add this to your job:
environment: 'production'
production being the name of an environment (you can create it before in the dedicated screen, but it's not necessary).
It's been 2 days since one of my project' build starts failing on Gitlab CI. The main error was E_MISSING_APP_KEY and when I check another variable just by echoing $HOST and $PORT from my .gitlab-ci.yml config, like this
tests:
script:
- echo "${HOST} ${PORT}"
- node -e "console.log(process.env.HOST, process.env.PORT)"
- node_modules/.bin/nyc node ace test -t 0
I got nothing.
The build was failed because it can't read my environment variable that I set on its CI Settings.
Anyone experiencing same issue? & how to solve this?
Update:
I'm trying to create new project with only containing .gitlab-ci.yml file here and it's seems working just fine
But why the world it's still failing on my main project?
For anyone else having a similar problem:
check your variable, if it is protected your branch has to be protected as well or remove the protected option on your variable
The issue is solved by delete all of my variables I've had & set them back from the CI Setting. And the build pipeline is running without any errors. (except the actual testing is still failed, lol)
Honestly, I'm still wondering why this could happened? and hopefully no one will experiencing same kind of issue like me here..