Category: gitlab

GitLab – Wiki Pages ”; Previous Next Description Wiki is a system for maintaining documentation for a project in the GitLab. It is like a Wikipedia which can be editable and given permissions to manage the wiki pages. A Guest can view a wiki page and Developer can create and edit a wiki page. Steps for Creating Wiki Page Step 1 − Login to your GitLab account, go to your project and click on the Wiki tab − Step 2 − Now enter the title, format, fill the content section, add a commit message and then click on the Create page button − Step 3 − You will get newly created wiki page as shown in the below image − Print Page Previous Next Advertisements ”;

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 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 ”; 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 ”;

GitLab – Create Backup ”; Previous Next GitLab allows to take backup copy of your repository by using simple command. In this chapter, we will discuss about how to take backup copy in the GitLab − Step 1 − First, login to your GitLab server using SSH (Secure Shell). Step 2 − Create the backup of GitLab by using the below command − sudo gitlab-rake gitlab:backup:create Step 3 − You can exclude some directories from the backup by adding environment variable SKIP as shown below − sudo gitlab-rake gitlab:backup:create SKIP = db,uploads Step 4 − The backup tar file will get created in the default /var/opt/gitlab/backups directory. Navigate to this path and type ls -l to see the created backup file − Print Page Previous Next Advertisements ”;

GitLab – Remove Users ”; Previous Next In this chapter, we will discuss about how to remove users from a project in the GitLab. Steps for Removing User Step 1 − Login to your GitLab account and go to your project under Projects section − Step 2 − Now, click on the Members option under Settings tab − Step 3 − You will see the list of users under Existing members and groups section and click on the delete option at right side to remove the user from project − Step 4 − After clicking remove button, it will display a pop-up window saying whether to remove the selected user from the project or not. Click on Ok button to remove the user. Step 5 − Now, it will display the success message after removing the user from the project as shown in the image below − Print Page Previous Next Advertisements ”;

GitLab CI – Introduction ”; Previous Next Description GitLab CI (Continuous Integration) service is a part of GitLab which manages the project and user interface and allows unit tests on every commit and indicates with warning message when there is an unsuccessful of build. Features It is integrated in GitLab interface. It has earned more popularity in the past few years due to its simple usage, faster results etc. It allows the project team members to integrate their work daily. The integration errors can be identified easily by an automated build. It can be executed on multiple platforms such as Windows, Unix, OSX and other platforms which support Go programming language. Advantages It is easy to learn, use and scalable. It displays the faster results as it divides the each build into multiple jobs that run on multiple machines. It is free and open source software which is added in both GitLab Community Edition and the proprietary GitLab Enterprise Edition. Print Page Previous Next Advertisements ”;

GitLab – Merge Requests ”; Previous Next Description Merge request can be used to interchange the code between other people that you have made to a project and discuss the changes with them easily. Steps for Merging Request Step 1 − Before creating new merging request, there should be a created branch in the GitLab. You can refer this chapter for creating the branch − Step 2 − Login to your GitLab account and go to your project under Projects section − Step 3 − Click on the Merge Requests tab and then click on the New merge request button − Step 4 − To merge the request, select the source branch and target branch from the dropdown and then click on the Compare branches and continue button as shown below − Step 5 − You will see the title, description and other fields such as assigning user, setting milestone, labels, source branch name and target branch name and click on the Submit merge request button − Step 6 − After submitting the merge request, you will get a new merge request screen as shown below − Print Page Previous Next Advertisements ”;

GitLab – Referencing Issues ”; Previous Next GitLab can be able to refer the specific issue from the commit message to solve a specific problem. In this chapter, we will discuss about how to reference a issue in the GitLab − Step 1 − To reference a issue, you need to have an issue number of a created issue. To create an issue, refer the creating issue chapter. Step 2 − To see the created issue, click on the List option under Issues tab − Step 3 − Before making the changes in your local repository, check whether it is up to date or not by using the below command − git checkout master && git pull The git pull command downloads the latest changes from the remote server and integrates directly into current working files. Step 4 − Now, create a new branch with the name issue-fix by using the git checkout command − git checkout -b issue-fix Step 5 − Now, add some content to the README.md file to fix the bug − echo “fix this bug” >> README.md Step 6 − Enter the commit message for the above change with the below command − git commit -a This command opens the below screen and press Insert key on the keyboard to add a commit message for the issue-fix branch. Now press the Esc key, then colon(:) and type wq to save and exit from the screen. Step 7 − Now push the branch to remote repository by using the below command − git push origin issue-fix Step 8 − Login to your GitLab account and create a new merge request. You can refer the merge request chapter for the creation of merge request. Step 9 − Once you create the merge request, you will be redirected to the merge request page. When you click on the Close merge request button (refer the screenshot in the step (6) of merge request chapter), you will see the Closed option after closing merge request. Print Page Previous Next Advertisements ”;

GitLab – Rebase Operation ”; Previous Next Description Rebase is a way of merging master to your branch when you are working with long running branch. Steps for Rebase Operation Step 1 − Go to your project directory and create a new branch with the name rebase-example by using the git checkout command − The flag -b indicates new branch name. Step 2 − Now, create a new file and add some content to that file as shown below − The content ”Welcome to Tutorialspoint” will be added to the rebase_file.md file. Step 3 − Add the new file to working directory and store the changes to the repository along with the message (by using the git commit command) as shown below − The flag -m is used for adding a message on the commit. Step 4 − Now, switch to the ”master” branch. You can fetch the remote branch(master is a branch name) by using the git checkout command − Step 5 − Next, create an another new file, add some content to that file and commit it in the master branch. Step 6 − Switch to the rebase-branch to have the commit of master branch. Step 7 − Now, you can combine the commit of master branch to rebase-branch by using the git rebase command − Print Page Previous Next Advertisements ”;