I am using gitlab in my local environment. Now I am trying to implement CI for autodeployment process. I followed the tutorial but that tutorial only works on gitlab.com my gitlab addrr is something like this http://192.168.-.-:---/root/test-project.
When I follow the tutorial step by step it works on gitlab.com that means when I add .gitlab-ci.yml file to my root project it triggers the pipeline. But when I add .gitlab-ci.yml file on my local git it doesn't trigger the pipeline as pipeline page shows everytime getting started with pipeline and it seems like i am not pushing it right.
How can I add .yml into my root directory?
the first step is to make pipelines work. I am confused
This should be easier with GitLab 13.12 (May 2021), which does now include a tutorial:
Useful GitLab CI/CD information in the pipeline editor
Creating your first GitLab CI/CD pipeline can be difficult, especially for those new to CI/CD.
You might spend time switching back and forth between documentation and GitLab to get your first pipeline configured.
In this release we’ve added a drawer with useful information to the pipeline editor to help guide you through the steps of writing your first pipeline.
See Documentation and Issue.
Related
I was trying to schedule a ci/cd pipeline in gitlab using .gitlab-ci.yaml file. I did't find a right documentation to implement the schedule using the ci/cd yaml file.
Is it possible to configure a pipeline run schedule (say everyday 08:00 AM) in .gitlab-ci.yaml file?
Thanks
Arun
Unfortunately, Scheduled pipeline is realized through GUI rather than .gitlab-ci.yml file in GitLab
You may find this document useful if you want to use GUI for schedule pipeline. Configuring in GUI is simpler than yaml coding.
If you really want it to be configured in yaml file, you may create an issue in GitLab repo. Actually, there's already an issue on this topic. It should not be a very difficult technically since it is only about keywords and parsing. Whether GitLab will do it or not is another story; so you'd better prepare a good scenario to persuade the GitLab team why you want this to be done.
The scheduled pipelines are configured via the GitLab CI/CD UI.
Read More about scheduled pipelines
I am planning to experiment building a pipeline using Azure DevOps. One thing that I noticed early on is, after azure-pipelines.yml created, I have to commit this first before being able to run it. But I want to experiment on it which revolves around trial and error. Doing multiple commit just to test things out are not feasible.
In Jenkins I can just define my steps and try to run it without committing the file.
Is this also possible to do in Azure DevOps?
But I want to experiment on it which revolves around trial and error. Doing multiple commit just to test things out are not feasible.
Yes it is - you just use a different code branch. That will allow you the freedom to make as many changes as you need, while putting the pipeline together and trying it out, without committing to the master branch.
Then when you're happy with the way the pipeline is running, you can merge your branch into the master branch which the pipeline normally uses.
You cannot run YAML pipelines without committing them, but you can create classic pipelines and run them without committing anything pipeline-related to the repository (except for the source code you want to build). Classic pipelines can later be turned (or copy-pasted, to be exact) into yaml pipelines with view YAML -option.
https://learn.microsoft.com/en-us/azure/devops/pipelines/get-started/pipelines-get-started?view=azure-devops#define-pipelines-using-the-classic-interface
If you're on your own branch, or in a repository without any other developers making changes then you can
Make a change
use git commit --amend to overwrite your previous commit with the new file
use git push --force-with-lease to push that up to Azure DevOps
That will hide your commit history while experimenting
I have a great experience of pipeline creating automation (in case of huge amount of repos).
For example, a project has 20 similar repos with Java app (like a microservice) and a pipeline for each of them is differing only by repo url (and a few more minor attributes). The CI/CD process for each of them is the same.
So, we can create a separated devops-repo with declaration configuration for our services. Also we can create a single pipeline which will pull the devops repo and create all needed pipelines for each repo in the configuration (this operation is going to be executed only once in the beginning and in case if we want to change the devops-configuration)
I have implemented that using Jenkins. Now, I am going to do so using GitLab CI. But I can't get how is it possible.
Is it possible to create a pipeline from another one (dynamically)?
Any suggestions?
You can use include and put the generic pipeline in your devops repo.
In your java repos you can include the devops pipeline and set the variables which are specific for the respective java repo.
So the pipeline for your java repos can be as short as this:
include:
- project: 'your-group/devops-repository'
file: '.generic-ci.yml'
variables:
FOO: bar
We are trying to get a clean YAML build going, and ran into a quirk: The build has an extra "Get Sources" step at the end, which is not in our YAML file, and can't be removed using the UI.
I created an azure-pipelines.yml file in the root of a new Azure Git (not GitHub) repo. A build definition was automatically created under OurRepo/OurRepo CI in the Builds pane on Azure DevOps.
The build works, but note the extra step at the end:
When I edit the job in Azure's UI via Pipeline Settings, I notice a "Get Sources" task that cannot be removed:
While this non-removable step makes sense for GUI-defined builds, I'm trying to go "pure YAML". The extra pull doesn't take long, so it's not a big deal, just annoying.
Apparently other users have this extra step in YAML builds as well: try googling "Post-job: Get sources".
Am I doing something wrong, or is this just a quirk with Azure Git repos using YAML builds? (The MS Docs tutorial uses a regular GitHub repo, I noticed).
Edit: I have also tried creating a build definition from YAML via New Build Definition > Azure Git Repo > YAML. The resulting page fails to detect the azure-pipeilnes.yml file (whether that file is empty or has a known working build definition when I committed it--tried both), so I ended up in the same place.
I doubt you can since it appears built-in to the pipeline. Is the output of that task have similar to my post task. Although it is labeled "Post-job Checkout". It looks like a clean-up step to me.
2019-01-30T21:39:38.1940431Z ##[section]Starting: Checkout
2019-01-30T21:39:38.2032443Z ==============================================================================
2019-01-30T21:39:38.2032500Z Task : Get sources
2019-01-30T21:39:38.2032550Z Description : Get sources from a repository. Supports Git, TfsVC, and SVN repositories.
2019-01-30T21:39:38.2032583Z Version : 1.0.0
2019-01-30T21:39:38.2032794Z Author : Microsoft
2019-01-30T21:39:38.2032822Z Help : [More Information](https://go.microsoft.com/fwlink/?LinkId=798199)
2019-01-30T21:39:38.2032852Z ==============================================================================
2019-01-30T21:39:38.5783539Z Cleaning any cached credential from repository: Sandbox (Git)
2019-01-30T21:39:38.5854582Z ##[section]Finishing: Checkout
The post job step is to wipe out the downloaded source content from the hosted agent machine. There is no way that the user has control over it and it is a built-in feature.
We have two servers in our organisation.
1) server with gitlab
2) Build server
I would like to create an automate build happen in the second machine(Build server ) for the source code in the gitlab server.
How can I achieve this using gitlab ?
Thanks,
siva
If you are moving from an "pull" continuous integration system (e.g. using a kind of crontab that regularly checks if the source code on the versioning system has changed and start the configure/build/test/deploy stages if it has), then know that gitlab has a much better way of doing this.
gitlab approach is to configure a "pull" system: every time the code is updated (in any branch) on the git repository then the script defined in your .gitlab-ci.yml is read to see if continuous integration jobs have to be launched. jobs are send to your configured gitlab runners. gitlab runners are defined on your build server(s) and takes the job when they are coming.
Definition of what to do is also describes in the .gitlab-ci.yml.
Here is a list of documentation to start learning about gitlab CI:
the official documentation can be helpful
A general introduction to gitlab ci using docker can be found in this blog article (the first slides are great). If your build server or your intended build is on Linux, I would recommend using the "docker executor" (e.g. gitlab runners are executed inside a docker machine inside your build server). It is easy and quick to setup.
Hope this helps you starting...