GitLab CI – Configuring Gitlab Runners ”; Previous Next Description GitLab runner is a build instance which is used to run the jobs over multiple machines and send the results to GitLab and which can be placed on separate users, servers, and local machine. You can register the runner as shared or specific after installing it. The installation of runner is explained in the GitLab Installation chapter. You can serve your jobs by using either specific or shared runners. Shared Runners These runners are useful for jobs multiple projects which have similar requirements. Instead of using multiple runners for many projects, you can use a single or a small number of Runners to handle multiple projects which will be easy to maintain and update. Specific Runners These runners are useful to deploy a certain project, if jobs have certain requirements or specific demand for the projects. Specific runners use FIFO (First In First Out) process for organizing the data with first-come first-served basis. You can register a specific runner by using project registration token. The registering a specific runner is explained in the GitLab Installation chapter from step 1 to 12 under the Installation of GitLab on Windows section. Locking a specific Runner You can lock a specific runner from being enabled for other projects. To do this, you need to register a runner which is explained in the GitLab Installation chapter from step 1 to 12 under the Installation of GitLab on Windows section. To lock runner, execute the below steps − Step 1 − Login to your GitLab account and go to your project − Step 2 − Click on the CI/CD option under Settings tab and expand the Runners Settings option. − Step 3 − Under Runners Settings section, you will see the activated Runners for the project − Step 4 − Now click on the pencil button − Step 5 − Next it will open the Runner screen and check the Lock to current projects option − Click on the Save changes button to take the changes effect. Step 6 − After saving the changes, it will update the Runner successfully. Protected Runners The runners can be protected to save the important information. You can protect the runner by using below steps − Step 1 − Follow the same steps (from step 1 to 4) which are explained in the previous section (Locking a specific Runner). Step 2 − After clicking on the pencil button, it will open the Runner screen and then check the Protected option − Click on the Save changes button to take the changes effect. Run untagged Jobs You can prevent runners from picking jobs with tags when there are no tags assigned to runners. Runner can pick tagged/untagged jobs by using below steps − Step 1 − Follow the same steps (from step 1 to 4) which are explained in the Locking a specific Runner section. Step 2 − After clicking on the pencil button, it will open the Runner screen and then check the Run untagged jobs option − Click on the Save changes button to take the changes effect. Print Page Previous Next Advertisements ”;
Category: gitlab
GitLab – Adding Users
GitLab – Adding Users ”; Previous Next In this chapter, we will discuss about how to add users to your project in the GitLab. Steps for Adding User Step 1 − Login to your GitLab account and go to your project under Projects section. Step 2 − Next, click on the Members option under Settings tab − Step 3 − It will open the below screen to add the member to your project − Step 4 − Now enter the user name, role permission, expiration date(optional) and click on Add to project button to add the user to project − Step 5 − Next, you will get a successful message after adding user to the project. The highlighted box in the above image indicates, a new user has been added to the project − Step 6 − You can also add user to the project by clicking on the Import button − Step 7 − Now select the project from which you want to add the user to your project and click on the Import project members button − Step 8 − You will get a success message after importing user to the project − Print Page Previous Next Advertisements ”;
GitLab CI – Permissions
GitLab CI – Permissions ”; Previous Next User Permissions The following table shows available user permissions levels for different types of users in a project − S.N. Guest Reporter Developer Master Owner 1 Creates a new issue Creates a new issue Creates a new issue Creates a new issue Creates a new issue 2 Can leave comments Can leave comments Can leave comments Can leave comments Can leave comments 3 Able to write on project wall Able to write on project wall Able to write on project wall Able to write on project wall Able to write on project wall 4 – Able to pull project code Able to pull project code Able to pull project code Able to pull project code 5 – Can download project Can download project Can download project Can download project 6 – Able to write code snippets Able to write code snippets Able to write code snippets Able to write code snippets 7 – – Create new merge request Create new merge request Create new merge request 8 – – Create new branch Create new branch Create new branch 9 – – Push and remove non protected branches Push and remove non protected branches Push and remove non protected branches 10 – – Includes tags Includes tags Includes tags 11 – – Can create, edit, delete project milestones Can create, edit, delete project milestones Can create, edit, delete project milestones 12 – – Can create or update commit status Can create or update commit status Can create or update commit status 13 – – Write a wiki Write a wiki Write a wiki 14 – – Create new environments Create new environments Create new environments 15 – – Cancel and retry the jobs Cancel and retry the jobs Cancel and retry the jobs 16 – – Updates and removes the registry image Updates and removes the registry image Updates and removes the registry image 17 – – – Can add new team members Can add new team members 18 – – – Push and remove protected branches – 19 – – – Can edit the project Can edit the project 20 – – – Can manage runners, job triggers and variables Can manage runners, job triggers and variables 21 – – – Add deploy keys to project Add deploy keys to project 22 – – – Able to manage clusters Able to manage clusters 23 – – – Configure project hooks Configure project hooks 24 – – – Can enable/disable the branch protection Can enable/disable the branch protection 25 – – – Able to rewrite or remove Git tags Able to rewrite or remove Git tags The following table shows available group members permissions levels in a group − S.N. Guest Reporter Developer Master Owner 1 Browse group Browse group Browse group Browse group Browse group 2 – – – – Edit group 3 – – – – Create subgroup 4 – – – Create project in group Create project in group 5 – – – – Manage group members 6 – – – – Remove group 7 – Manage group labels Manage group labels Manage group labels Manage group labels 8 – – Create/edit/delete group milestones Create/edit/delete group milestones Create/edit/delete group milestones 9 – View private group epic View private group epic View private group epic View private group epic 10 – – – – – 11 View internal group epic View internal group epic View internal group epic View internal group epic View internal group epic 12 View public group epic View public group epic View public group epic View public group epic View public group epic 13 – Create/edit group epic Create/edit group epic Create/edit group epic Create/edit group epic 14 – – – – Delete group epic 15 – – – – View group Audit Events The following table shows available GitLab CI/CD permissions in the GitLab − S.N. Guest/Reporter Developer Master Admin 1 Can see commits and jobs Can see commits and jobs Can see commits and jobs Can see commits and jobs 2 Retry or cancel job Retry or cancel job Retry or cancel job 3 – Deletes job artifacts and trace Deletes job artifacts and trace Deletes job artifacts and trace 4 – – Remove project Remove project 5 – – Create project Create project 6 – – Change project configuration Change project configuration 7 – – Add specific runners Add specific runners 8 – – – Add shared runners 9 – – – Can able to see events in the system 10 – – – Admin interface Job Permissions The following table shows job permissions in the GitLab − S.N. Guest/Reporter Developer Master Admin 1 – Run CI job Run CI job Run CI job 2 – Clone source and LFS from current project Clone source and LFS from current project Clone source and LFS from current project 3 – Clone source and LFS from public projects Clone source and LFS from public projects Clone source and LFS from public projects 4 – Clone source and LFS from internal projects Clone source and LFS from internal projects Clone source and LFS from internal projects 5 – Clone source and LFS from private projects Clone source and LFS from private projects Clone source and LFS from private projects 6 – Push source and LFS Push source and LFS Push source and LFS 7 – Pull container images from current project Pull container images from current project Pull container images from current project 8 – Pull container images from public projects Pull container images from public projects Pull container images from public projects 9 – Pull container images from internal projects Pull container images from internal projects Pull container images from internal projects 10 – Pull container images from private projects Pull container images from private projects Pull container images from private projects 11 – Push container images to current project Push container images to current project Push container images to current project 12
GitLab – Introduction
GitLab – Introduction ”; Previous Next What is Gitlab? Before we dive into definition for Gitlab, first we need to understand few terminologies. We often come across these terms like Git, Gitlab, GitHub, and Bitbucket. Let”s see definiton of all these as below − Git – It is a source code versioning system that lets you locally track changes and push or pull changes from remote resources. GitLab, GitHub, and Bitbucket – Are services that provides remote access to Git repositories. In addition to hosting your code, the services provide additional features designed to help manage the software development lifecycle. These additional features include managing the sharing of code between different people, bug tracking, wiki space and other tools for ”social coding”. GitHub is a publicly available, free service which requires all code (unless you have a paid account) be made open. Anyone can see code you push to GitHub and offer suggestions for improvement. GitHub currently hosts the source code for tens of thousands of open source projects. GitLab is a github like service that organizations can use to provide internal management of git repositories. It is a self hosted Git-repository management system that keeps the user code private and can easily deploy the changes of the code. History GitLab was found by Dmitriy Zaporozhets and Valery Sizov in October 2011. It was distributed under MIT license and the stable version of GitLab is 10.4 released in January 22, 2018. Why to use GitLab? GitLab is great way to manage git repositories on centralized server. GitLab gives you complete control over your repositories or projects and allows you to decide whether they are public or private for free. Features GitLab hosts your (private) software projects for free. GitLab is a platform for managing Git repositories. GitLab offers free public and private repositories, issue-tracking and wikis. GitLab is a user friendly web interface layer on top of Git, which increases the speed of working with Git. GitLab provides its own Continuous Integration (CI) system for managing the projects and provides user interface along with other features of GitLab. Advantages GitLab provides GitLab Community Edition version for users to locate, on which servers their code is present. GitLab provides unlimited number of private and public repositories for free. The Snippet section can share small amount of code from a project, instead of sharing whole project. Disadvantages While pushing and pulling repositories, it is not as fast as GitHub. GitLab interface will take time while switching from one to another page. Print Page Previous Next Advertisements ”;
GitLab – Fork a Project
GitLab – Fork a Project ”; Previous Next Description Fork is a duplicate of your original repository in which you can make the changes without affecting the original project. Forking a Project Step 1 − To fork a project, click on the Fork button as shown below − Step 2 − After forking the project, you need to add the forked project to a fork group by clicking on it − Step 3 − Next it will start processing of forking a project for sometime as shown below − Step 4 − It will display the success message after completion of forking the project process − Print Page Previous Next Advertisements ”;
GitLab – Create Issue
GitLab – Create Issue ”; Previous Next In this chapter, we will discuss about how to create an issue in a project − Step 1 − Login to your GitLab account and go to your project under Projects section − Step 2 − Go to Issues tab and click on the New issue button to create a new issue as shown below − Step 3 − Now, fill the information such as title, description and if you want, you can select a user to assign an issue, milestone(refer this chapter for more information), labels upon operation or could be choose by developers themselves later. Step 4 − Click on the Submit issue button and you will get an overview of an issue along with title and description as shown below − Print Page Previous Next Advertisements ”;
GitLab CI – Container Registry ”; Previous Next Description Container registry is a storage and content delivery system, which stores their Docker (it is database of predefined images used to run applications.) images. Deploying the Registry You can deploy the registry by using the below commands − Step 1 − First, login to your GitLab server using SSH (Secure Shell). Step 2 − Now start the registry container by using below command − $ docker run -d -p 5000:5000 –restart = always –name registry registry:2 The -p 5000:5000 specifies first part as host port and second part as port within the container. The –restart = always flag restarts the registry automatically when Docker restarts. The registry:2 is defined as an image. Step 3 − Now, pull the image from Docker hub to your registry − $ docker pull ubuntu:16.04 The above command pulls the ubuntu:16.04 image from Docker Hub. Step 4 − Next, tag the image to point your registry − $ docker tag ubuntu:16.04 localhost:5000/my-ubuntu Here, we are tagging the localhost:5000/my-ubuntu image for an existing ubuntu:16.04 image. Step 5 − Push the image to local registry which is executing at localhost:5000. $ docker push localhost:5000/my-ubuntu Step 6 − Now remove the cached (ubuntu:16.04 and localhost:5000/my-ubuntu) images from the registry − $ docker image remove ubuntu:16.04 $ docker image remove localhost:5000/my-ubuntu Step 7 − Pull back the localhost:5000/my-ubuntu image from local registry − $ docker pull localhost:5000/my-ubuntu Step 8 − Now stop the registry and remove the data − $ docker container stop registry && docker container rm -v registry Print Page Previous Next Advertisements ”;
GitLab – CI/CD Variables
GitLab – CI/CD Variables ”; Previous Next The following table shows list of GitLab CI/CD variables. S.No. Variable GitLab Runner Description 1 CI all 0.4 Specifies that job is accomplished in CI environment. 2 CI_COMMIT_REF_NAME 9.0 all Defines the branch or tag name for project build. 3 CI_COMMIT_REF_SLUG 9.0 all It uses the lowercased $CI_COMMIT_REF_NAME variable which is reduced to 63 bytes, and only 0-9 and a-z replaced with -. 4 CI_COMMIT_SHA 9.0 all Specifies the commit revision for built project. 5 CI_COMMIT_TAG 9.0 0.5 It commits the tag name 6 CI_CONFIG_PATH 9.4 0.5 Specifies the path to CI config file. (The default path is .gitlab-ci.yml). 7 CI_DEBUG_TRACE all 1.7 It enables the debug tracing. 8 CI_ENVIRONMENT_NAME 8.15 all Defines the environment name for the job. 9 CI_ENVIRONMENT_SLUG 8.15 all It is a environment name, suitable for DNS, URLs, Kubernetes labels, etc. 10 CI_ENVIRONMENT_URL 9.3 all Defines the environment URL for the job. 11 CI_JOB_ID 9.0 all Represents the unique id of the current job for GitLab CI. 12 CI_JOB_MANUAL 8.12 all It specifies that job has been started manually. 13 CI_JOB_NAME 9.0 0.5 The job name is defined in the .gitlab-ci.yml file. 14 CI_JOB_STAGE 9.0 0.5 The stage name is defined in the .gitlab-ci.yml file. 15 CI_JOB_TOKEN 9.0 1.2 This token is used for authenticating with the GitLab Container Registry and multi-project pipelines when triggers are involved. 16 CI_REPOSITORY_URL 9.0 all It specifies the URL to clone the Git repository. 17 CI_RUNNER_DESCRIPTION 8.10 0.5 It specifies the description for the runner. 18 CI_RUNNER_ID 8.10 0.5 It provides the unique id for runner being used. 19 CI_RUNNER_TAGS 8.10 0.5 It defines the runner tags. 20 CI_RUNNER_VERSION all 10.6 It specifies the GitLab runner version of the current job. 21 CI_RUNNER_REVISION all 10.6 It specifies the GitLab revision of the current job. 22 CI_PIPELINE_ID 8.10 0.5 It provides the unique id of the current pipeline. 23 CI_PIPELINE_SOURCE 9.3 all It specifies how the pipeline was triggered by using some options such as push, web, trigger, schedule, api, pipeline. 24 CI_PIPELINE_TRIGGERED all all It specifies that job was triggered. 25 CI_PIPELINE_SOURCE 10.0 all It specifies source of the pipeline such as push, web, trigger, schedule, api, external. 26 CI_PROJECT_DIR all all It defines the full path of the cloned repository, where the job is run. 27 CI_PROJECT_ID all all It provides the unique id of the current project. 28 CI_PROJECT_NAME 8.10 0.5 It provides the name of the current project. 29 CI_PROJECT_PATH 8.10 0.5 It provides the name of the project along with namespace. 30 CI_PROJECT_URL 8.10 0.5 It gives the http address to retrieve the project. 31 CI_PROJECT_VISIBILITY 10.3 all It specifies the project visibility whether it is internal, private or public. 32 CI_REGISTRY 8.10 0.5 It returns the address of GitLab”s Container Registry, only if the Container Registry is enabled. 33 CI_REGISTRY_IMAGE 8.10 0.5 It returns the address of GitLab”s Container Registry which is tied to specific project, only if the Container Registry is enabled. 34 CI_REGISTRY_PASSWORD 9.0 all The password can be used to push the containers to the GitLab Container Registry. 35 CI_REGISTRY_USER 9.0 all The username can be used to push the containers to the GitLab Container Registry. 36 CI_SERVER all all It specifies that job is executed in CI environment. 37 CI_SERVER_NAME all all It gives the CI server name to coordinate the jobs. 38 CI_SERVER_REVISION all all It is used to schedule the jobs by using GitLab revision. 39 CI_SERVER_VERSION all all It is used to schedule the jobs by using GitLab version. 40 CI_SHARED_ENVIRONMENT all 10.1 It indicates that job is executed in a shared environment and it is set to true, if the environment is shared. 41 ARTIFACT_DOWNLOAD_ATTEMPTS 8.15 1.9 It specifies the number of attempts to download artifacts running a job. 42 GET_SOURCES_ATTEMPTS 8.15 1.9 It specifies the number of attempts to get the sources running a job. 43 GITLAB_CI all all It specifies that job is accomplished in GitLab CI environment. 44 GITLAB_USER_ID 8.12 all It specifies the id of GitLab user who is running a job. 45 GITLAB_USER_EMAIL 8.12 all It specifies the email of GitLab user who is running a job. 46 GITLAB_USER_LOGIN 10.0 all It specifies the login username of GitLab user who is running a job. 47 GITLAB_USER_NAME 10.0 all It specifies the real name of GitLab user who is running a job. 48 GITLAB_FEATURES 10.6 all It provides list of the licensed features for the GitLab instance and plan. 49 RESTORE_CACHE_ATTEMPTS 8.15 1.9 It defines number of cache attempts to restore the running a job. 50 CI_DISPOSABLE_ENVIRONMENT all 10.1 It indicates that job is executed in a disposable environment and it is set to true, if the environment is disposable. The following table shows list of new variables which can be used with GitLab 9.0 release − S.No. 9.0+ name 1 CI_JOB_ID 2 CI_COMMIT_SHA 3 CI_COMMIT_TAG 4 CI_COMMIT_REF_NAME 5 CI_COMMIT_REF_SLUG 6 CI_JOB_NAME 7 CI_JOB_STAGE 8 CI_REPOSITORY_URL 9 CI_PIPELINE_TRIGGERED 10 CI_JOB_MANUAL 11 CI_JOB_TOKEN Print Page Previous Next Advertisements ”;
GitLab – Home
GitLab Tutorial Gitlab is a service that provides remote access to Git repositories. In addition to hosting your code, the services provide additional features designed to help manage the software development lifecycle. These additional features include managing the sharing of code between different people, bug tracking, wiki space and other tools for ”social coding”. Audience This tutorial will help beginners learn the basic functionality of Gitlab service. After completing this tutorial, you will find yourself at a moderate level of expertise in using Gitlab from where you can take yourself to the next levels. Prerequisites We assume that you are going to use Gitlab to handle all levels of Java and Non-Java projects. So it will be good if you have some amount of exposure to software development life cycle and working knowledge of developing web-based and non web-based applications, alongwith usage of command prompts on Windows or Linux environments. Print Page Previous Next Advertisements ”;
GitLab CI – Cycle Analytics
GitLab CI – Cycle Analytics ”; Previous Next Description Cycle Analytics specifies how much time taken by the team to complete the each stage in their workflow and allows GitLab to store data of development efforts in one central data store. The cycle analytics page can be found under the Overview section. Step 1 − Login to your GitLab account and go to your project − Step 2 − Click on the Cycle Analytics option under Overview tab which will open the screen as shown below − The cycle analytics contains following stages − Issue − It specifies how much time taken to solve an issue. Plan − It specifies the time between pushing first commit to branch and action took for previous stage. Code − It specifies the time between pushing first commit to branch and created merge request for that commit. Test − It specifies how much time need to GitLab CI/CD to test the code. Review − It specifies time taken to review the merge request. Staging − It defines the time spent between merging and deploying to production. Production − It specifies the time taken to complete the entire process, from creating an issue to deploying code to production. Print Page Previous Next Advertisements ”;