I am currently trying to deploy to multiple countries with Gitlab.
My current .gitlab-ci.yml
action-deploy:
stage: deploy
script:
- ls $PROJECT_URL
environment:
name: DE/$CI_COMMIT_BRANCH
url: https://$PROJECT_URL
General problem:
Here the DE (Germany) is a single country. How Do I gather all available XXXXXXX/$CI_COMMIT_BRANCH environments from the gitlab project settings and deploy to all of them?
Main question:
Is there a way in Gitlab CI to get all available environments?
Related
I am trying to build GitLab CI/CD for the first time. I have two stages build and deploy The job in the build stage produce artifacts. And then the job in deploy stage wants to upload those artifacts to AWS S3. Both the jobs are using same runner but different docker image.
default:
tags:
- dev-runner
stages:
- build
- deploy
build-job:
image: node:14
stage: build
script:
- npm install
- npm run build:prod
artifacts:
paths:
- deploy/build.zip
deploy-job:
image: docker.xx/xx/gitlab-templates/awscli
stage: deploy
script:
- aws s3 cp deploy/build.zip s3://mys3bucket
The build-job is successfully creating the artifacts. GitLab documentation says artifacts will be automatically downloaded and available in the next stage, however it does not specify where & how these artifacts will be available to consume in the next stage.
Question
In the deploy-job will the artifacts available at the same location? like deploy/build.zip
The artifacts should be available to the second job in the same location, where the first job saved them using the 'artifacts' directive.
I think this question already has an answer on the gitlab forum:
https://forum.gitlab.com/t/access-artifact-in-next-task-to-deploy/9295
Maybe you need to make sure the jobs run in the correct order using the dependencies directive, which is also mentioned in the forum discussion accesible via the link above.
All my environments (Deployments > Environments) appear 'Stopped', in GitLab Community Edition 15.1.5.
The Docs state that one needs at least 'Reporter' role; I don't know if I have that, or how to check, but assume I have it.
Edit: Deployments happen as part of the build, in the Deployment stage of the gitlab ci.
what follows is potentially a red herring, further tests are required
I was directed by a colleague, as follows:
(The snippet of gitlab ci yaml that I included was irrelevant, so I'll remove it from the question.
I will include the yaml from our dev environment, it has the same symptom.) The offending part was as follows:
Before - (environment stopped on gitlab)
###################### - DEV - Azure Deployment
DEV_deploy_to_azure:
environment:
name: DEV_AZURE
url: https://app-xxxxxx-dev.azurewebsites.net/api/health
<<: *azure_deployment
variables:
DOCKER_TAG: DEV
when: manual
After
###################### - DEV - Azure Deployment
DEV_deploy_to_azure:
<<: *azure_deployment
environment:
name: DEV_AZURE
url: https://app-xxxxxx-dev.azurewebsites.net/api/health
variables:
DOCKER_TAG: DEV
when: manual
Here are my colleague's words:
Solution: change the order of the environment-key in the pipeline:
Now all my deployments appear as expected.
I have a spring boot web app project on gitlab, which is needed to be deployed on two remote instances of Tomcat servers using CI/CD. After quick research I have found this article. According to the article all necessary components are installed and the following gitlab-ci.yml file was created:
stages:
- build
- deploy
maven-build:
stage: build
script: "mvn package -B"
artifacts:
paths:
- target/*.war
Deploy:
stage: deploy
script:
- cp /home/gitlab-runner/builds/76XAQ_K8/0/l.furkat/testservice/target/testservice.war /var/lib/tomcat9/webapps
But in the script above one can deploy the app on one instance.
How can I deploy the project on two instances?
Any hint or navigation is appreciated.
I have a GitLab CI pipeline which builds a few artifacts. For example:
train:job:
stage: train
script: python script.py
artifacts:
paths:
- artifact.csv
expire_in: 1 week
Now I deploy the repository to OpenShift using the following step in my GitLab pipeline. This will pull my GitLab repo inside OpenShift. It does not include the artifacts from the 'testing'.
deploy:app:
stage: deploy
image: ayufan/openshift-cli
before_script:
- oc login $OPENSHIFT_DOMAIN --token=$OPENSHIFT_TOKEN
script:
- oc start-build my_app
How can I let OpenShift use this repository, plus the artifacts created in my pipeline?
In general OpenShift build pipelines rely on the s2i build process to build applications.
The best practice for reusing artifacts between s2i builds would either be through using incremental builds or chaining multiple BuildConfig definitions (the output image of one BuildConfig being fed as source image into another BuildConfig) together via the spec.source.images or spec.source.git configuration in the BuildConfig definition.
In your case since you are using a Jenkins pipeline to generate your artifacts instead of the OpenShift build process you really only need to combine your artifacts with your source code and the runtime container image.
To do this you might create a builder container image that pulls those artifacts down from an external source during the assemble phase (via curl, wget, etc) of the s2i workflow. You could then configure your BuildConfig to point at your source repository. At build time the BuildConfig will pull down your source code and the assemble script will pull down your artifacts.
I use Gitlab runner and works fine for a single server. The gitlab-ci.yml is simple:
stages:
- test
- deploy
test:
stage: test
image: php
tags:
- docker
script:
- echo "Run tests..."
deploy:
stage: deploy
tags:
- shell
script:
- sh deploy.sh
As i said this is fine for a single server but to deploy same app on another server? I tried with same gitlab-runner config (same conf.toml) but then it was only updating one of them randomly.
Is there somehow gitlab Ci to be triggered by more than 1 runner and deploy all of them according gitlab-ci.yml?
You can register several runners (e.g. tagged serverA and serverB) from different servers and have multiple deployment jobs, each of them performed by a different runner. This is because you can set more than one tag in a job and only a runner having all the tags will be used.
stages:
- test
- deploy
test:
stage: test
image: php
tags:
- docker
script:
- echo "Run tests..."
deployA:
stage: deploy
tags:
- shell
- serverA
script:
- sh deploy.sh
deployB:
stage: deploy
tags:
- shell
- serverB
script:
- sh deploy.sh
However, take into account a situation when one of the deployment jobs fails - this would end up in you having two different versions of the code on the servers. Depending on your situation this might or might not be a problem.
Yes there is, just set up two jobs for the same stage:
stages:
- deploy
deploy:one:
stage: deploy
script:
- echo "Hello CI one"
deploy:two:
stage: deploy
script:
- echo "Hello CI two"
If necessary you can use tags on your runners to choose which one to use.
Since 2016, you now have Environments and deployments
Environments describe where code is deployed.
Each time GitLab CI/CD deploys a version of code to an environment, a deployment is created.
GitLab:
Provides a full history of deployments to each environment.
Tracks your deployments, so you always know what is deployed on your servers.
It does integrates well with Prometheis, and, with GitLab 13.11 (April 2021), you even have:
Update a deploy freeze period in the UI
In GitLab 13.2, we added the ability to create a deploy freeze period in the project’s CI/CD settings.
This capability helps teams avoid unintentional deployments, reduce uncertainty, and mitigate deployment risks.
However, it was not possible to update deploy freezes.
In GitLab 13.11, we are adding the ability to edit an existing deploy freeze. This way, you can update the freeze period to match your business needs.
See Documentation and Issue.
As shown in "gitlab-ci.yml deployment on multiple hosts", you can use YAML anchors to trigger parallel deployment on multiple environments, which means "multiple servers".