This tutorial series introduces the core features of GitLab, beginning with understanding GitLab and Git basics and navigating the GitLab interface. It then progresses to GitLab Flow, demonstrating its application through practical exercises like modifying a project readme and managing merge requests. The series further explores GitLab CI/CD, detailing pipeline creation, job configuration, artifact management, and caching. Finally, it covers migrating from Jenkins to GitLab CI/CD and utilizing GitLab for packaging and releasing software, including interaction with the package, container, and infrastructure registries.

GitLab Core Features Study Guide

Quiz

1. What is GitLab, and what is its primary function? GitLab is an open-source software development platform that, at its core, is a source code management system. However, it extends beyond this by offering additional functionalities like CI/CD and project collaboration tools. GitLab describes itself as a DevOps platform.
2. Explain the difference between Git and GitLab in 2-3 sentences. Git is a distributed version control system used to track changes to source code files within a codebase. GitLab, on the other hand, is a source code management system that provides a platform to host Git repositories, enabling collaboration among software development teams. Think of Git as the engine for version control, and GitLab as the online service to manage and share Git-controlled projects.
3. Describe the basic GitLab workflow, also known as the GitLab flow, in brief. The GitLab flow generally involves creating feature branches off the main branch for specific development tasks. Once development is complete, a merge request is created to propose merging the feature branch back into the main branch after review and testing. Depending on the GitLab flow variation, changes may then be merged into environment branches (like staging or production) or managed through release branches.
4. What are merge requests in GitLab, and what is their purpose? A merge request in GitLab is a request to merge changes from one branch into another, typically from a feature branch into the main branch. It serves as a central place for team members to discuss, review, and verify the changes on a branch before they are integrated into the main codebase, often triggering automated testing.
5. What are GitLab issues used for, and how should a software development workflow ideally begin with them? GitLab issues are used to track work related to a GitLab project, such as reporting bugs, tracking tasks, and requesting new features. Ideally, a software development workflow should begin with the creation of an issue to clearly define the scope and objectives of the work that needs to be done before any code changes are made.
6. Explain the concept of a branching strategy in the context of Git. A branching strategy is a defined workflow that a development team follows when using Git (or another version control system) to manage concurrent development. It outlines how branches are created, how collaboration occurs on these branches, and how changes are eventually merged back into the main codebase, aiming to maintain code stability and facilitate feature development.
7. Describe the key difference between the GitHub flow and the Git flow branching strategies. The GitHub flow is a simpler strategy primarily using feature branches off the main branch, which are merged back in after review and testing. The Git flow is more complex, utilizing long-lived develop and main branches, as well as supporting branches for features, releases, and hotfixes, making it suitable for more structured release cycles.
8. What are GitLab pipelines, and what are their basic components? GitLab pipelines are a top-level component used to define the CI/CD (Continuous Integration/Continuous Delivery or Deployment) process for a GitLab project. Their basic components include stages, which define the chronological order of jobs, and jobs, which are associated with stages and define the specific steps (scripts) to be executed by GitLab runners.
9. What is the purpose of GitLab runners in the CI/CD process? GitLab runners are open-source applications that execute the instructions defined within the jobs of a GitLab pipeline. They pick up and run the scripts specified in the .gitlab-ci.yml file, performing tasks such as compiling code, running tests, and deploying applications, either on shared GitLab infrastructure or on self-hosted machines.
10. What is the GitLab Package Registry, and what types of packages does it support? The GitLab Package Registry allows users to use GitLab as a private or public repository for various software packages. It supports a number of package managers and formats, including Maven packages, container images (via the Container Registry), and Terraform modules (via the Infrastructure Registry), enabling teams to manage their dependencies and releases directly within GitLab.

Essay Format Questions

1. Compare and contrast the three main Git branching strategies discussed (GitHub flow, Git flow, and GitLab flow). Discuss the advantages and disadvantages of each and in what scenarios each strategy might be most appropriate.
2. Explain in detail the environment branches variation of the GitLab flow. Describe the typical branch structure, the process of developing and deploying features, and how hotfixes are managed within this workflow.
3. Discuss the role and importance of merge requests in a collaborative software development environment using GitLab. Explain the key features of a merge request and how they facilitate code review, discussion, and integration.
4. Describe the fundamental concepts and benefits of Continuous Integration and Continuous Delivery/Deployment (CI/CD) as implemented in GitLab pipelines. Explain the relationship between pipelines, stages, jobs, and GitLab runners in automating the software development lifecycle.
5. Discuss the various registries offered by GitLab (Package Registry, Container Registry, and Infrastructure Registry). Explain the purpose of each registry and how they contribute to the overall DevOps lifecycle within the GitLab platform.

Glossary of Key Terms

• Branch: An independent line of development within a Git repository. Branches allow for isolated work on features or bug fixes without affecting the main codebase.
• Commit: A snapshot of the changes made to files in a Git repository at a specific point in time, along with metadata like author and commit message.
• CI/CD (Continuous Integration/Continuous Delivery or Deployment): A set of practices that automate the building, testing, and deployment of software, enabling faster and more frequent releases.
• Git: A distributed version control system used for tracking changes in source code during software development.
• GitLab: A web-based DevOps platform that provides source code management (Git repositories), CI/CD pipelines, issue tracking, and other collaborative features.
• GitLab Flow: A streamlined branching strategy that offers a balance between simplicity and structure, with variations for environment and release branches.
• GitLab Group: A way to organize multiple projects and users, allowing for centralized management of settings and permissions.
• GitLab Issue: A tool within GitLab used to track tasks, bugs, feature requests, and other work items related to a project.
• GitLab Pipeline: A configurable automated process defined in a .gitlab-ci.yml file that describes the steps for building, testing, and deploying code.
• GitLab Project: A container in GitLab for a single codebase (Git repository) along with its associated issues, merge requests, CI/CD configuration, and other features.
• GitLab Runner: An agent that executes the jobs defined in a GitLab pipeline. Runners can be shared, group-specific, or project-specific.
• Merge Request: A request to merge changes from one branch into another in GitLab, facilitating code review and discussion.
• Package Registry: A feature in GitLab that allows you to store and manage software packages (e.g., Maven, npm, NuGet) within your projects or groups.
• Release: A specific version of a software project that is made available to users, often marked with a Git tag and potentially including release notes and assets.
• Repository (Repo): A directory where your project’s files and their history are stored, managed by a version control system like Git.
• Stage (in CI/CD): A phase in a GitLab pipeline that contains one or more jobs. Stages are executed in a defined order.
• Tag (Git Tag): A static marker in a Git repository that typically points to a specific commit, often used to denote releases.

GitLab Tutorial Series Briefing Document

Date: October 26, 2023 Prepared For: Review of GitLab Tutorial Series Sources Prepared By: Gemini AI

This document provides a detailed review of the main themes, important ideas, and facts presented in the provided excerpts from the GitLab tutorial series. Quotes from the original sources are included where appropriate to illustrate key points.

Main Themes

1. Introduction to GitLab: The series begins by defining GitLab as an open-source software development platform, emphasizing its core as a source code management (SCM) system with added DevOps functionalities like CI/CD. It differentiates GitLab from Git, highlighting GitLab as a platform for hosting and collaborating on Git repositories.
2. Core GitLab Features: The tutorials cover several core features of GitLab, including the user interface, Git integration, the GitLab Flow, CI/CD pipelines, package and release management, and integration with external testing platforms like LambdaTest.
3. Fundamentals of Git: A significant portion of the early tutorials focuses on introducing and explaining fundamental Git commands and concepts, such as git init, git status, git add, git commit, branching (git branch, git checkout), merging (git merge), and stashing (git stash). Best practices for using Git, like developing on feature branches and not committing directly to the main branch, are also emphasized.
4. GitLab Flow as a Development Workflow: The series introduces the GitLab Flow as GitLab’s primary branching strategy, contrasting it with other common Git workflows like GitHub Flow and Git Flow. It details the two variations of GitLab Flow: one using environment branches and the other using release branches. The tutorials then demonstrate the environment branches variation in practice.
5. Continuous Integration and Continuous Delivery/Deployment (CI/CD) in GitLab: A key focus of the later tutorials is GitLab’s CI/CD capabilities. The series explains the core components of GitLab CI/CD, including pipelines, jobs, stages, and runners. It then guides the user through creating and implementing GitLab CI/CD pipelines, including defining jobs, stages, specifying Docker images, using variables, caching dependencies, and generating artifacts.
6. GitLab Package and Release Management: The series introduces GitLab’s features for managing software packages and releases. It explains the GitLab Package Registry, Container Registry, and Infrastructure Registry, detailing how to publish and consume packages and container images from within GitLab pipelines. The concept of GitLab Releases, including associated release notes and evidence, is also introduced.
7. Integration with LambdaTest: The series explicitly covers the integration of the LambdaTest platform with GitLab CI for performing cross-browser testing, indicating GitLab’s interoperability with other developer tools.

Most Important Ideas and Facts

Tutorial Series Overview:

• The tutorial series aims to teach users how to utilize the core features of GitLab.
• Topics to be covered include: What is GitLab, basics of Git, GitLab interface, GitLab Flow, hands-on activities using GitLab Flow, CI/CD in GitLab, migrating Jenkins pipelines to GitLab CI, GitLab’s packaging and releasing features, and integrating LambdaTest with GitLab CI.
• Learning objectives include understanding GitLab CI, fundamental Git commands, working with GitLab Flow, performing CI/CD in GitLab, migrating from Jenkins, and deploying software using GitLab’s packaging and releasing features.
• The course is intended for DevOps engineers, software teams migrating from Jenkins to GitLab, and developers whose team uses GitLab.
• Prerequisites include access to a GitLab instance and a recent version of Git installed.

What is GitLab and Basics of Git:

• GitLab is an “open source software development platform” and a “DevOps platform.”
• At its core, GitLab is a “source code management system” built on top of Git.
• Git is a “version control system” used to track changes to source code files.
• GitLab is used to “host Git repositories so that they can be shared with other people on your team,” similar to file sharing platforms but specifically for source code.
• Benefits of using GitLab include enabling collaboration, built-in CI/CD functionality, and high interoperability with other tools.
• Basic Git commands covered include:
• git –version: To verify Git installation.
• git init <repository_name>: To initialize a new Git repository in a specified directory.
• git config –global init.defaultBranch main: To set the default branch name to main.
• cd <repository_name>: To navigate into the newly created repository.
• git branch -m main: To rename the current branch to main.
• .git directory: A hidden folder that makes a directory a Git repository.
• git status: To check the current state of the Git repository, including untracked files and staged changes.
• Main branch (or pristine/stable branch): Supposed to contain bug-free, deployable code. Developers should avoid committing directly to this branch for feature development.
• Feature branch: An isolated copy of the codebase for developing new features without impacting the main branch.
• git add <file_name>: To move changes from the working directory to the staging area. Git employs a “two-stage commit” process.
• git commit -m “<commit_message>”: To create a commit object, recording changes from the staging area to the Git history. Commit messages should be concise descriptions of the changes.
• git log: To view the history of commits in the repository, including commit hash, author information, date, and commit message.
• git branch <branch_name>: To create a new branch.
• git checkout <branch_name>: To switch to an existing branch. git checkout -b <new_branch_name> creates and switches to a new branch.
• git merge <source_branch>: To merge changes from the specified source branch into the currently checked-out branch.
• git branch -d <branch_name>: To delete a branch.
• git stash or git stash push: To save uncommitted changes temporarily without creating a commit.
• git stash list: To view a list of stashed changes.
• git stash apply: To reapply stashed changes to the working directory, keeping the changes in the stash.
• git stash pop: To reapply stashed changes and remove them from the stash.
• git stash clear: To remove all entries from the stash.
• git clone <repository_url>: To download a Git repository from a remote source to the local machine.

GitLab Interface:

• Key GitLab terminology includes:
• Group: Manages settings across multiple projects, enables logical categorization of users and projects, and provides cross-project views of issues and merge requests.
• Project: A container for a Git repository with built-in CI/CD functionality, issue tracking, and collaboration tools like merge requests. There is a one-to-one mapping between a GitLab project and a Git repository.
• Members: GitLab users or groups with access to a project, assigned roles with specific permissions.
• Merge Request: A request to merge one branch into another, providing a space for discussion, review, and verification of changes.
• Issue: A way to track work related to a project, used for bug reports, tasks, feature requests, and more. Software development workflow should ideally begin with the creation of an issue.
• The GitLab interface includes a projects dashboard, navigation bar with profile and help menus, to-do list, merge request and issues pages, a top-level search, and a “+” menu for creating new items.
• Account settings allow users to manage profile information, access tokens, notifications, and more.
• Project creation allows starting from a blank project, a template, or importing from other systems.
• Project home page displays commits, branches, tags, file structure, and the rendered README. It also provides options for creating new files, uploading, creating directories, branching, tagging, using a web IDE, downloading the source code, and cloning the repository.
• Project features include issue tracking with agile boards, merge request management, CI/CD configuration, package and container registries, infrastructure registry for Terraform modules, project wiki for documentation, and code snippets.
• Project settings allow configuration of general information, merge request behavior (merge methods, squash options, merge checks), repository settings (default branch, protected branches), and monitoring settings (GitLab Pages).

GitLab Flow:

• A branching strategy is a software development workflow within Git that describes how teams create, collaborate on, and merge branches.
• Choosing a branching strategy depends on team requirements, SCM system, deployment environments, deployment management, and code base structure.
• Common Git branching strategies include GitHub Flow, Git Flow, and GitLab Flow.
• GitHub Flow: Simple workflow with feature branches created off main, changes pushed to GitHub, pull requests opened, automated testing, review and verification, and merging into main.
• Git Flow: More complex, uses a long-lived develop branch, feature branches off develop, release branches off develop for testing and bug fixes before merging into main (tagged with release version), and hotfix branches off main for production issues, merged back into both main and develop.
• GitLab Flow: Simpler than Git Flow, more structured than GitHub Flow, with two variations:
• Environment Branches: Long-lived production branch. Feature branches off main, merged into environment branches (e.g., staging) and then into production. Upstream first policy for hotfixes (created off main, merged back into main and pre-production branches before production).
• Release Branches: Used for releasing software to the outside world (e.g., open source). Similar to environment branches but uses release branches (created as late as possible, only major bug fixes, upstream first policy for bug fixes). Release branches are long-lived until a release is no longer supported.
• GitLab Flow with environment branches uses main as an integration branch and promotes changes through pre-production environments to production.

Practicing GitLab Flow:

• The GitLab Flow practice demonstrates the environment branches variation.
• The process begins with an issue defining the work scope. Issues can contain subtasks using Markdown checkboxes.
• A production branch is created from main to represent the production environment.
• Protecting the production branch in project settings restricts who can merge into and push to it (e.g., only Maintainers). Force pushing should generally be disabled on protected branches.
• git clone is used to download the remote GitLab project (Git repository) to the local machine.
• A feature branch (readme-introduction) is created off main using git checkout -b.
• Local changes are made to the README.md file, staged with git add, and committed with git commit -m.
• git push -u origin <feature_branch_name> is used to push the local branch and its commits to the remote GitLab repository, setting up tracking.
• A Merge Request is created from the feature branch to the main branch. The title is often automatically populated from the latest commit message.
• Merge Requests provide a platform for discussion, assigning reviewers, and automated testing (though not explicitly set up in this initial demonstration).
• Reviewers can add comments to specific lines of code in the “Changes” tab (diff view).
• Requested changes are made locally, committed, and pushed. These new commits automatically update the existing Merge Request.
• Threads on code comments can be resolved once the requested changes are made.
• Merge Requests are approved by reviewers and then merged into the target branch (main). The source branch can be automatically deleted upon merge.
• Since the environment branches variation is used, a second Merge Request is created to merge the main branch into the production branch.
• A Git tag (e.g., v1.0) is created on the production branch to mark a release. Tags can have messages and release notes.
• Creating a tag can also generate a release in the “Deployments” section of the GitLab project.
• git pull is used to sync the local repository with the remote repository after merges and tag creation.
• git branch -d <local_branch_name> deletes a local branch that has been merged remotely.
• git branch –all shows both local and remote branches.
• git pull –prune removes remote branches from the local repository’s tracking information if they have been deleted on the remote.
• The original issue related to the changes should be closed and marked as done after the changes are merged and the tag is created.

CI/CD in GitLab:

• A GitLab pipeline is defined in a YAML file named .gitlab-ci.yml at the root of the project.
• The pipeline editor in GitLab provides syntax validation and visualization of the pipeline.
• A pipeline consists of:
• Pipelines: Top-level component defining the CI/CD process.
• Jobs: Associated with stages, define the actual steps (shell scripts) to be executed. script is the only required property of a job.
• Stages: Define the chronological order of jobs. Multiple jobs within a stage can run in parallel by default.
• GitLab Runners: Open-source application that executes the instructions defined in jobs. Can be local, cloud, or on-prem. GitLab hosts shared runners.
• The image keyword at the top of .gitlab-ci.yml specifies the Docker image to be used for the pipeline’s jobs, providing necessary dependencies.
• variables keyword allows defining pipeline-level variables that can be referenced in job scripts. GitLab also has predefined environment variables (e.g., CI_PROJECT_DIRECTORY).
• cache keyword is used to cache directories (specified by paths) between pipeline runs to speed up execution (e.g., caching Maven dependencies in .m2/repository).
• stages keyword defines the names and order of pipeline stages (e.g., build, test, deploy).
• Each job is associated with a stage using the stage keyword.
• artifacts keyword in a job definition specifies files or directories to be persisted after the job completes.
• when: always specifies that artifacts should always be generated.
• reports: junit: <path> specifies the path to JUnit test report XML files, which GitLab can then render in the UI.
• environment keyword in a job definition associates the job with a specific environment (e.g., staging), creating deployments visible in the Environments page.
• workflow: rules: can control when a pipeline runs based on conditions (e.g., only run when a Git tag is created using if: $CI_COMMIT_TAG).

Migrating Jenkins Pipelines to GitLab CI:

• The example uses a Maven project with TestNG for testing and aims to migrate a Jenkins pipeline to GitLab CI.
• The Jenkins pipeline has a single “test” stage, defines environment variables, uses the Maven Integration Plugin, authenticates with LambdaTest using Jenkins credentials, and runs Maven tests.
• The GitLab CI pipeline for the migration would need to:
• Define stages (potentially build, test).
• Specify a Docker image with necessary dependencies (e.g., Maven, Java).
• Set environment variables, potentially including LambdaTest credentials.
• Define jobs to execute Maven commands for building and testing (mvn clean install).
• Integrate with LambdaTest by setting up the desired capabilities and running tests against the LambdaTest hub URL, likely using environment variables for LambdaTest username and access key.
• Configure JUnit or TestNG report generation as artifacts for visualization in GitLab.
• The GitLab CI example provided focuses on deploying a Maven package, but the principles for running tests against LambdaTest would involve similar steps within a test job.

GitLab Packaging and Releasing Features:

• A software release in GitLab can include:
• Generic software packages (artifacts).
• Release notes.
• Release evidence (issues, milestones, test reports).
• A snapshot of the project’s source code.
• GitLab Package Registry: Allows using GitLab as a public or private software package registry, supporting various package managers (e.g., Maven). Packages are associated with projects and groups. Can be used from within CI/CD pipelines.
• GitLab Container Registry: Private container registry for Docker images, associated with projects and groups. Container images can be used in and published from GitLab pipelines.
• GitLab Infrastructure Registry: Supports publishing and sharing Terraform modules, with a registry per project. Terraform modules can be built and published from pipelines.
• To deploy a Maven package to the GitLab Package Registry:
• Configure the settings.xml (e.g., ci_settings.xml) with server credentials using the predefined CI_JOB_TOKEN for authentication within a GitLab pipeline. For external authentication, a personal access token or deploy token would be needed.
• Modify the pom.xml to:
• Reference a GitLab environment variable (CI_COMMIT_TAG) for the <version> tag to version snapshots based on Git tags.
• Add a <repositories> tag specifying the GitLab Maven Package Registry URL, constructed using predefined environment variables (CI_API_V4_URL, CI_PROJECT_ID).
• Add a <distributionManagement> section to define the deployment repository as the GitLab Maven Package Registry.
• Create a GitLab CI pipeline (.gitlab-ci.yml) that:
• Uses a Maven Docker image.
• Defines a maven_options variable for the local Maven repository.
• Uses workflow: rules: to trigger the pipeline only on Git tag creation (if: $CI_COMMIT_TAG).
• Caches the Maven repository.
• Has a deploy job that runs mvn deploy -s ci_settings.xml to publish the package.
• Successfully deploying a Maven package to the GitLab Package Registry makes it available for download and use as a dependency in other Maven projects.

This detailed briefing document summarizes the key aspects of the GitLab tutorial series excerpts, providing a comprehensive overview of the topics covered, important concepts, and practical applications of GitLab’s features.

Understanding GitLab: Core Concepts and Workflow

What is GitLab and how does it differ from Git?

GitLab is an open-source software development platform that, at its core, is a source code management system. However, it offers additional functionality such as CI/CD (Continuous Integration and Continuous Delivery/Deployment) capabilities. GitLab describes itself as a DevOps platform, providing tools for the entire software development lifecycle.

Git, on the other hand, is a version control system used to track changes made to source code files within a codebase. GitLab is a source code management system that you would use to host Git repositories so that they can be shared and collaborated on with a team, similar to how you might share files using services like Dropbox or Google Drive. GitLab enables collaboration, has built-in CI/CD, and is highly interoperable with other tools.

What is the basic GitLab workflow, also known as the GitLab Flow?

The GitLab Flow is a branching strategy and software development workflow within the context of Git and GitLab. It describes how a development team will create, collaborate on, and merge branches of source code.

There are two main variations of the GitLab Flow:

1. Environment Branches: This workflow uses long-lived environment branches such as production. Feature branches are created off of the main branch and are then merged into environment branches in a specific order (e.g., main $\rightarrow$ staging $\rightarrow$ production). Hotfixes are created off main and merged back into main and pre-production branches before production.
2. Release Branches: This variation is used when releasing software to the outside world. Similar to the first, feature branches are created off main and merged back. Release branches are created as late as possible, and only major bug fixes are applied to them. Bug fixes follow an upstream-first policy.

The GitLab Flow aims to be simpler than Gitflow but more structured than GitHub Flow.

What are some key components of the GitLab interface that a user should be familiar with?

Key components of the GitLab interface include:

• Dashboard: Provides an overview of projects, starred projects, and the ability to create new projects.
• Navigation Bar: Located at the top, it includes access to profile settings, support/help, to-do lists, merge requests, issues, and a top-level search function. It also has a “+” icon to create new projects, groups, or snippets.
• Left-hand Side Menu: Offers access to various dashboards such as Projects, Groups, Security, and Environments.
• Project Home Page: Displays the code repository, commits, branches, tags, and provides options to create/upload files, create branches/tags, use the Web IDE, download the repository, and clone it.
• Issues: A system for tracking work, reporting bugs, requesting features, and managing tasks related to a project.
• Merge Requests: A place to propose changes, have discussions about branch changes, perform code reviews, and merge branches.
• CI/CD: Section for configuring and managing Continuous Integration and Continuous Delivery/Deployment pipelines, including pipelines, jobs, and schedules.
• Packages & Registries: Where software packages, container images (Docker), and infrastructure modules (Terraform) can be published and managed.
• Settings: Project and group settings allow configuration of various aspects like visibility, permissions, merge request behavior, and protected branches.

How can you initiate a new project and manage access for team members in GitLab?

To initiate a new project in GitLab, you can click the “New project” button on your dashboard or by using the “+” icon in the navigation bar. You can choose to create a blank project, create from a template, or import a project from another source. When creating a blank project, you’ll need to provide a project name (or slug), choose a visibility level (private, internal, or public), and can initialize it with a README.

To manage access for team members, you can add members to a GitLab project or a group. Navigate to the project’s or group’s “Members” section in the left-hand menu under “Manage”. From there, you can invite users by their email or GitLab username and assign them a role (e.g., Guest, Reporter, Developer, Maintainer, Owner) which determines their permissions within the project or group.

What are merge requests in GitLab and why are they important for collaboration?

A merge request in GitLab is a request to merge one branch into another. It serves as a central place for team members to discuss, review, and verify the changes proposed on a feature branch before they are integrated into the main codebase.

Merge requests are crucial for collaboration because they:

• Provide a dedicated space for code review and feedback through inline comments on the diff.
• Allow for automated testing to be triggered to ensure the changes do not introduce regressions.
• Keep a record of the discussions and decisions made regarding the proposed changes.
• Enable the use of approvals to enforce that changes are reviewed by authorized team members before merging.
• Facilitate continuous integration practices by ensuring that changes are reviewed and tested frequently.

How can you create and utilize GitLab CI/CD pipelines for your projects?

To create a GitLab CI/CD pipeline, you need to define a YAML file named .gitlab-ci.yml at the root of your project’s repository. This file outlines the pipeline’s structure, including stages (e.g., build, test, deploy) and jobs within those stages.

You can use the Pipeline Editor in GitLab (under CI/CD $\rightarrow$ Editor) to create or modify this file. The editor provides syntax validation and visualization of the pipeline.

In the .gitlab-ci.yml file, you can specify:

• image: The Docker image to be used for the pipeline’s jobs, providing the necessary environment and dependencies.
• stages: An array defining the different stages of your pipeline, which will be executed in order.
• Jobs: Under each stage, you define jobs with scripts to be executed by GitLab Runners. Jobs can include commands to compile code, run tests, build artifacts, and deploy applications.
• variables: Custom environment variables that can be used throughout the pipeline.
• cache: Defines directories to be cached between pipeline runs to speed up execution (e.g., dependencies).
• artifacts: Specifies files or directories produced by a job that should be stored and can be downloaded or used by subsequent jobs.
• reports: Configures specific reports, such as JUnit test reports, to be collected and displayed in the GitLab UI.
• environment: Associates a deploy job with a specific environment (e.g., staging, production), which is tracked by GitLab.
• workflow: Controls when a pipeline should run based on rules (e.g., only on tag creation).

Once the .gitlab-ci.yml file is committed to your repository, GitLab will automatically trigger pipelines based on the defined rules (e.g., on every push or merge request). You can monitor the status of your pipelines under the CI/CD $\rightarrow$ Pipelines section of your project.

What is the GitLab Package Registry and how can you use it to manage software packages?

The GitLab Package Registry is a feature that allows you to use GitLab as a private or public registry for various software package formats (e.g., Maven, npm, PyPI, NuGet, Conan, Go modules). It enables you to publish, share, and consume packages directly within your GitLab projects and groups.

To use the Package Registry:

1. Configure your project: Ensure your project’s build configuration (e.g., pom.xml for Maven, package.json for npm) is set up to interact with the GitLab Package Registry. This typically involves specifying the registry URL as a repository and configuring authentication.
2. Authenticate: You’ll need to authenticate to publish and consume packages. This can be done using:

• A GitLab personal access token with the api scope.
• A deploy token created within the project.
• The CI_JOB_TOKEN within a GitLab CI/CD pipeline for automated publishing.

1. Publish packages: You can publish packages from your local machine using the respective package manager’s commands (e.g., mvn deploy for Maven, npm publish for npm) or as part of a GitLab CI/CD pipeline.
2. Consume packages: To use packages from the registry in another project, you need to configure that project’s package manager to point to the GitLab Package Registry and provide the necessary authentication.

Packages in the registry are associated with a specific GitLab project and can be private or public depending on the project’s visibility. The Package Registry provides a centralized place to manage and depend on your project’s or organization’s software packages.

What are GitLab Releases and how do they relate to tags and other project components?

GitLab Releases provide a way to formalize and track specific versions of your software. A release in GitLab can include:

• Software packages published to the Package Registry.
• Release notes describing the changes in the release.
• Release evidence, which can include links to associated issues, merge requests, milestones, and test reports.
• A snapshot of the project’s source code at the time of the release.

GitLab Releases are closely related to Git tags. Typically, you create a Git tag to mark a specific point in your repository’s history that corresponds to a release. When you create a release in GitLab (either manually or through a CI/CD pipeline), it is associated with an existing Git tag.

Releases can be created from the Repository $\rightarrow$ Tags page by creating a new tag and optionally adding release notes. They can also be automated as part of your CI/CD pipeline when a specific tag is created (e.g., a version tag). The release page (Deployments $\rightarrow$ Releases) provides an overview of all releases for a project, allowing users to download assets, view release notes, and track the history of your software.

GitLab Tutorial Series Overview

The GitLab Tutorial Series, hosted by Moss, aims to teach users how to utilize the core features of GitLab. The series covers a range of topics, starting with the fundamentals and progressing to more advanced functionalities.

Here’s a breakdown of the key aspects of the tutorial series as discussed in the sources:

Topics Covered:

• Introduction to GitLab: Defining what GitLab is as an open-source DevOps platform and a source code management system with built-in CI/CD. The series differentiates between Git (version control) and GitLab (hosting Git repositories).
• Basics of Git: Covering fundamental Git commands, including verifying installation (git –version), initializing a repository (git init), configuring the default branch name (git config –global init.defaultBranch main), changing directory (cd), and renaming a branch (git branch -m).
• GitLab Interface: Familiarizing users with the major components of the GitLab interface, including the login page, projects dashboard, navigation bar (profile, support, to-do list, merge requests, issues), top-level search, and left-hand side menu (dashboards for projects, groups, security, environments).
• GitLab Terminology: Introducing important GitLab terms such as Group, Project, Members, Merge Request (the equivalent of a pull request in GitHub), and Issue.
• GitLab Flow: Presenting GitLab’s primary branching strategy, contrasting it with GitHub Flow (simpler) and Git Flow (more complex). The series discusses two variations of GitLab Flow: one using environment branches (production, pre-production) and the other using release branches. The concept of an “upstream first policy” for hotfixes and bug fixes is also explained.
• Applying GitLab Flow: Demonstrating the environment branches variation of GitLab Flow through a practical exercise involving creating a feature branch, modifying a file, creating merge requests (merging into main then production), protecting branches, tagging releases, and syncing local and remote repositories.
• CI/CD in GitLab: Showing how to implement Continuous Integration and Continuous Delivery/Deployment (CI/CD) pipelines in GitLab. This includes defining pipelines using .gitlab-ci.yml files, understanding stages and jobs, and utilizing GitLab Runners. The series covers writing pipelines that produce artifacts, cache dependencies, and use variables. The Pipeline Editor with its validation and visualization features is also introduced.
• Migrating Jenkins Pipelines to GitLab CI/CD: Explaining the key differences between Jenkins Pipelines and GitLab CI/CD and guiding users through the migration process. This involves mapping Jenkins terminology (agent, stages, steps, environment, tools) to GitLab equivalents (runner, stages, script, variables, Docker images). The series also demonstrates using GitLab pipelines to run tests on the LambdaTest Selenium automation grid.
• GitLab Packaging and Releasing Features: Introducing GitLab’s package registry (for various software packages like Maven), container registry (for Docker images), and infrastructure registry (for Terraform modules). The series demonstrates deploying artifacts to the GitLab package registry from a CI/CD pipeline and describes GitLab releases.
• Integrating LambdaTest Platform with GitLab CI: While listed in the roadmap, the practical steps for this integration are shown within the “Migrating Jenkins Pipelines to GitLab CI/CD” module, where LambdaTest is used as the test execution platform.

Learning Objectives:

Upon completing the tutorial series, learners should be able to:

• Understand and implement GitLab CI.
• Know the fundamental commands of Git.
• Work in GitLab using the GitLab flow.
• Understand and perform CI/CD in GitLab.
• Migrate Jenkins pipelines to GitLab.
• Deploy software using GitLab’s packaging and releasing features.
• Sync changes between local and remote Git repositories.
• Create merge requests and understand their components.
• Implement GitLab pipelines in their own projects.
• Write GitLab pipelines that produce artifacts, cache dependencies, and use variables.
• Describe the anatomy of a GitLab pipeline.
• Explain the differences between Jenkins Pipelines and GitLab CI/CD.
• Use GitLab pipelines to run tests on the LambdaTest Selenium automation grid.
• Deploy artifacts from a GitLab pipeline to the GitLab package registry.
• Describe GitLab releases and its registries (package, container, infrastructure).

Target Audience:

The course is designed for:

• DevOps engineers.
• Software teams looking to migrate from Jenkins to GitLab.
• Developers whose teams use GitLab.

Prerequisites:

To follow along with the tutorials, users need:

• Access to a GitLab instance (either gitlab.com or a private instance) with a user account.
• A recent version of Git installed on their machine.

Key Concepts and Features Highlighted:

• Open-Source DevOps Platform: GitLab is presented as a comprehensive platform beyond just source code management.
• Collaboration: GitLab facilitates collaboration among software teams.
• Built-in CI/CD: GitLab offers integrated continuous integration and continuous delivery/deployment capabilities.
• Interoperability: GitLab can integrate with other tools.
• GitLab Flow: A structured yet simpler branching strategy compared to Git Flow.
• Merge Requests: Central to the GitLab workflow for code review and discussion.
• GitLab Issues: Used for tracking work, reporting bugs, and requesting features.
• GitLab Pipelines: Defined in YAML (.gitlab-ci.yml), they automate the software development lifecycle.
• GitLab Runners: Execute the instructions defined in pipeline jobs.
• Pipeline Editor: Provides a user-friendly interface for creating and validating GitLab CI/CD pipelines.
• Artifacts and Caching: Mechanisms for managing build outputs and improving pipeline performance.
• Pipeline Variables: For configuring pipeline behavior and storing sensitive information securely (protected and masked variables).
• GitLab Registries: For managing software packages, container images, and infrastructure modules.
• Releases: GitLab provides features for creating and managing software releases.
• SSH Key Authentication: A secure method for authenticating with GitLab, especially for command-line interactions.

The GitLab Tutorial Series appears to be a comprehensive guide for individuals and teams looking to leverage GitLab’s core functionalities, from basic version control with Git to advanced CI/CD and release management practices.

GitLab Core Features: Development and DevOps Platform

Drawing on the GitLab Tutorial Series and our previous discussion, the core features of GitLab revolve around its identity as an open source software development platform and a DevOps platform. At its core, GitLab is a source code management system that hosts Git repositories, enabling collaboration among software teams. However, its core functionality extends significantly beyond this.

Here’s a breakdown of the core GitLab features discussed in the sources:

• Source Code Management with Git: GitLab allows users to host Git repositories, similar to how files are shared on platforms like Dropbox or Google Drive, but specifically for source code. It supports fundamental Git commands such as initializing repositories (git init), managing branches (git branch, git checkout), adding files to the staging area (git add), committing changes (git commit), and syncing local and remote repositories (git push, git pull).
• Branching Strategies and GitLab Flow: GitLab emphasizes the use of branching for feature development, advocating against committing directly to the main branch. The tutorial series introduces the GitLab Flow, a structured branching strategy that is simpler than Git Flow but more organized than GitHub Flow. It includes variations using environment branches (like production) and release branches. The core principle involves creating feature branches off the main branch, merging into pre-production branches, and finally into production.
• Merge Requests: Merge requests are a central collaboration feature in GitLab, serving as requests to merge one branch into another. They provide a space for discussion, code review, and verification of changes. Opening a merge request can trigger automated testing.
• Issue Tracking: GitLab Issues are used to track work related to a project, including bug reports, tasks, and feature requests. The software development workflow is suggested to begin with the creation of an issue. Issues can have subtasks defined using markdown checkboxes.
• Continuous Integration and Continuous Delivery/Deployment (CI/CD): GitLab has built-in CI/CD functionality. This core feature allows users to automate the building, testing, and deployment of their software through GitLab Pipelines defined in .gitlab-ci.yml files. Pipelines consist of stages (defining the order of execution) and jobs (defining the actual tasks) that are executed by GitLab Runners. Pipelines can produce artifacts and utilize caching to optimize performance. Pipeline variables can be defined for configuration.
• GitLab Interface: The GitLab interface provides dashboards for projects and groups, navigation for key features like merge requests and issues, and tools for creating new projects, groups, and snippets. The Pipeline Editor offers a user-friendly way to create and validate CI/CD configurations.
• Groups and Projects: GitLab uses groups to manage settings across multiple projects and categorize users, while projects serve as containers for Git repositories and also include built-in CI/CD and issue tracking.
• Members and Roles: Access to GitLab projects and groups is managed through members who are assigned specific roles with defined permissions.
• Registries: GitLab provides several registries as core features:
• Package Registry: For publishing and sharing software packages (e.g., Maven packages).
• Container Registry: A private registry for Docker images.
• Infrastructure Registry: For publishing and sharing Terraform modules.
• Releases: GitLab offers features for managing software releases, including associating tags, release notes, and assets with specific versions of the code.

These features collectively make GitLab a comprehensive platform supporting the entire software development lifecycle, from planning and coding to building, testing, and deploying applications.

GitLab CI/CD: Core Concepts and Pipeline Automation

Drawing on the GitLab Tutorial Series and our previous discussion [Your previous turn], GitLab CI/CD is a core feature of the GitLab platform that provides built-in Continuous Integration and Continuous Delivery/Deployment capabilities. It allows users to automate the software development lifecycle, from building and testing to deploying applications.

Here’s a detailed discussion of GitLab CI/CD based on the sources:

• GitLab Pipelines: At the heart of GitLab CI/CD are pipelines, which are top-level components used to define the entire CI/CD process for a GitLab project. Pipelines are configured using a YAML file named .gitlab-ci.yml located at the root directory of the project. This file defines the stages and jobs that will be executed. Pipelines are triggered by various events, such as code commits and pushes, merge requests, and the creation of Git tags.
• Stages: Within a pipeline, stages define the chronological order in which jobs are executed. You can define multiple stages (e.g., build, test, deploy) to structure your CI/CD process. Jobs within the same stage are executed in parallel by default.
• Jobs: Jobs are associated with specific stages in a pipeline and define the actual steps to be executed. These steps typically involve running shell scripts to compile code, execute tests, and deploy applications. The script keyword is the only required property of a job and contains the shell commands.
• GitLab Runners: GitLab Runners are open-source applications that execute the instructions defined within the jobs in a pipeline. Runners can be installed on various infrastructure, including local machines, cloud servers, or on-premises environments. GitLab also offers shared runners hosted by GitLab. You can also register your own runners if you prefer to manage the execution environment.
• .gitlab-ci.yml Configuration: The .gitlab-ci.yml file is where you define your pipeline’s structure and behavior. Key keywords used in this file include:
• stages: To define the different stages in the pipeline.
• image: To specify a Docker image that the GitLab Runner should use to execute the job, providing a consistent and reproducible environment with necessary dependencies. You can define a default image for the entire pipeline or specific images for individual jobs. For example, the tutorial uses the maven image for a Maven project.
• variables: To define environment variables that can be used during pipeline runtime. Variables can be defined at the pipeline level or job level. GitLab also provides predefined environment variables like CI_PROJECT_DIRECTORY, CI_JOB_TOKEN, and CI_COMMIT_TAG. Variables can be marked as protected (available only to protected branches or tags) and masked (hidden in job logs) for sensitive information like passwords.
• cache: To specify directories that should be cached between pipeline runs to improve performance by avoiding the need to re-download dependencies (e.g., Maven dependencies in .m2/repository).
• artifacts: To define files or directories that should be persisted after a job completes and can be downloaded or used by subsequent jobs in the pipeline. You can specify when artifacts should be generated using the when condition (e.g., always). For test reports, you can use the reports keyword (e.g., junit) to have GitLab render them in the UI.
• workflow: To control when a pipeline will run using rules. For example, you can configure a pipeline to run only when a Git tag is created.
• environment: To associate a deploy job with a specific environment (e.g., staging), which can be tracked in GitLab’s Environments dashboard.
• Pipeline Editor: GitLab provides a Pipeline Editor within the GitLab interface, which helps users create and validate their .gitlab-ci.yml files. The editor offers syntax highlighting, validation to ensure the configuration is valid, and visualization of the pipeline structure. It also provides linting information and the ability to view the merged YAML configuration. GitLab also offers a library of CI/CD templates for various technologies and frameworks.
• Testing and Reporting: GitLab CI/CD integrates with testing frameworks. By specifying JUnit test reports as artifacts, GitLab can parse these reports and display a summary of the test results within the pipeline view, including the number of tests passed, failed, and the duration.
• Deployment: GitLab CI/CD can be used to automate the deployment of applications to various environments. The environment keyword allows you to track deployments in GitLab. While the tutorial demonstrates a basic deployment step using Maven, in real-world scenarios, this could involve deploying to cloud platforms, servers, or container orchestration systems.
• Comparison with Jenkins: As discussed previously [Your previous turn] and highlighted in the tutorial, there are key differences between GitLab CI/CD and Jenkins. GitLab CI/CD configuration is done through a single YAML file in the repository, while Jenkins pipelines can be defined in Groovy. GitLab recommends using Docker images for environment consistency, whereas Jenkins relies on agents with pre-installed tools or the tools directive (which has no direct GitLab equivalent). GitLab emphasizes a fresh environment for each job (requiring explicit artifact sharing), while Jenkins uses a shared workspace by default.

In summary, GitLab CI/CD is a powerful and integrated toolset within GitLab that enables teams to automate their software development processes, ensuring faster feedback loops, consistent builds and tests, and streamlined deployments. The declarative YAML configuration, the flexibility of using Docker images, and the integrated UI for pipeline management and reporting make it a central component of the GitLab DevOps platform.

Git Basics: Core Concepts and Commands

Drawing on the GitLab Tutorial Series and our conversation history, here’s a discussion of Git basics:

At its core, Git is a distributed version control system. You use Git to track changes made to source code files within a codebase.

Here are some fundamental Git concepts and commands covered in the tutorial:

• Verifying Git Installation: You can check if Git is installed on your machine and see its version by opening your terminal and running the command git –version.
• Initializing a Git Repository (git init): The git init command is used to initialize a new Git repository.
• If you run git init without any parameters, it will initialize the current directory as a Git repository. This is useful for adding version control to an existing codebase.
• To create a new Git repository in a subdirectory, you can pass the desired name of the repository as an argument to git init, for example, git init test-project. This creates a subdirectory with the specified name and initializes a Git repository inside it.
• Default Branch Name: When initializing a new Git repository, Git might create a default branch with a name other than main. The tutorial shows how to rename the default branch to main using the following commands:
• git config –global init.defaultBranch main (to set the default name for all new repositories)
• cd test-project (to navigate into the newly created repository)
• git branch -m main (to rename the current branch to main)
• The .git Directory: After initializing a Git repository, a hidden folder called .git is created within the repository’s directory. This .git directory is what makes the folder a Git repository; without it, it’s just a regular folder. The .git directory tracks all the changes and the history of the repository. You can verify if a directory is a Git repository by checking for the existence of the .git folder or by running git status inside the directory.
• Checking Repository Status (git status): The git status command tells you the current state of your Git repository. It shows information about the current branch, whether there are any uncommitted changes, files in the staging area, or untracked files. You’ll find yourself running git status very frequently when working with Git.
• Branching: Branching is one of Git’s most powerful features. The main branch (or sometimes called pristine or stable branch) is intended to contain code that is bug-free and deployable.
• Developers should never commit changes directly to the main branch when working on new features. Doing so risks breaking the codebase for everyone.
• Instead, you should create a dedicated branch for each new feature. A branch in Git can be thought of as an entirely separate copy of the codebase where you can work and experiment without affecting the main branch.
• Creating a Branch (git branch <branch_name>): You can create a new branch using the git branch command followed by the desired name of the branch. For example, git branch my-feature creates a branch named my-feature.
• Switching Between Branches (git checkout <branch_name>): To work on a specific branch, you need to check out to that branch using the git checkout command followed by the branch name. For example, git checkout my-feature switches your working directory to the my-feature branch.
• The Two-Stage Commit Process: Git uses a two-stage commit process.
• Working Directory: This is where you make changes to your files.
• Staging Area: Before committing your changes to the repository’s history, you need to add those changes to the staging area. The staging area allows you to group logically related changes together before creating a commit. Changes in the working directory appear in red in the git status output.
• Commit History: A commit object tracks a specific set of changes to the repository.
• Adding Files to the Staging Area (git add <file_name>): To move changes from the working directory to the staging area, you use the git add command followed by the name of the file or directory you want to add. For example, git add hello.txt stages the hello.txt file. Changes in the staging area appear in green in the git status output.
• Committing Changes (git commit -m “commit message”): To create a commit object and save the staged changes to the repository’s history, you use the git commit command.
• You should provide a concise commit message that describes the changes you’re making. This metadata helps in reviewing the history later.
• You can use git commit by itself, which will open a text editor to write your commit message.
• Alternatively, you can use the -m option followed by your commit message in quotes, for example, git commit -m “Adding initial hello.txt file”.
• The first time you use git commit on a machine, Git might prompt you to configure your username and email address using git config –global user.name “Your Name” and git config –global user.email “your.email@example.com”. This information is associated with your commits.
• Viewing Commit History (git log): The git log command displays a list of all the commits that have been made in the repository. It shows the commit hash (a unique identifier), the author, the date, and the commit message. The HEAD pointer indicates the current commit you’re checked out to. git log –all –oneline provides a concise one-line summary of the commit history for all branches.
• Modifying Files: After creating a branch and making changes to files, git status will show the modified files in the working directory. You need to use git add to stage these changes and then git commit to save them to the current branch.
• Merging Branches (git merge <branch_name>): Once you have completed a feature on a dedicated branch and are confident in your changes, you can merge that branch into another branch (e.g., main).
• To merge a branch, you first need to check out to the target branch (the branch you want to merge into).
• Then, you use the git merge command followed by the name of the source branch (the branch containing the changes you want to merge). For example, if you’re on the main branch and want to merge the my-feature branch, you would run git merge my-feature.
• The tutorial mentions a fast-forward merge, which occurs when the target branch has not diverged from the source branch since the creation of the source branch. In this case, Git simply moves the target branch pointer to the latest commit of the source branch.
• Deleting a Branch (git branch -d <branch_name>): After a feature branch has been successfully merged into the main branch, it is often no longer needed and can be deleted using the git branch -d command followed by the branch name. For example, git branch -d my-feature would delete the my-feature branch.
• Stashing Changes (git stash): The git stash command allows you to temporarily save changes you’ve made in your working directory without committing them. This is useful when you need to switch to another branch quickly or want to experiment without affecting your current working state.
• git stash or git stash push will stash your uncommitted changes.
• git stash list shows a list of your stashed changes.
• git stash apply reapplies the stashed changes to your working directory but keeps the stash entry.
• git stash pop reapplies the stashed changes and removes the stash entry from the list.
• git stash clear removes all entries in the stash.

These basic Git commands and concepts are fundamental for using GitLab as a source code management system and for participating in collaborative software development workflows. The tutorial series builds upon these basics to introduce more advanced features within the GitLab platform.

GitLab Interface: Components and Navigation

Based on the GitLab Tutorial Series provided in the sources, here’s a discussion of the GitLab interface:

The GitLab interface offers a wide array of features for software development, making it a comprehensive DevOps platform. Navigating this interface is a key skill for utilizing GitLab effectively.

Key Components and Navigation:

• Top Navigation Bar: After logging into your GitLab account, you’ll typically land on a projects dashboard. The top navigation bar provides access to several important areas:
• Profile Menu (Far Right): Allows you to access your GitLab profile, set a status, upgrade your subscription, edit your profile, view account preferences (including access tokens and SSH keys), and sign out.
• Support/Help Menu: Provides access to GitLab documentation and support resources.
• To-Do List: Shows a list of items requiring your attention, such as assigned issues or merge requests.
• Merge Requests Dropdown: Allows you to access merge requests assigned to you or where you are a reviewer. A merge request is a request to merge one branch into another and is a central place for code review and discussion.
• Issues Page: Enables you to query issues across projects based on various parameters, such as issues assigned to you or where you were mentioned. A GitLab issue is a way to track work related to a GitLab project, including bug reports, tasks, and feature requests. Your software development workflow should often begin with the creation of an issue.
• New Item Creation: A “+” icon allows you to create new projects, repositories, groups, and snippets. A snippet is a small piece of code that can be shared.
• Top-Level Search Bar: Enables searching across GitLab.
• Left-Hand Side Menu: This menu provides access to various dashboards and project/group-specific sections:
• Projects Dashboard: Lists all your GitLab projects, starred projects, and allows you to explore public projects. A GitLab project is essentially a container for a Git repository with built-in CI/CD functionality and issue tracking. It has a one-to-one mapping to a Git repository. As we discussed previously, Git is a version control system, while GitLab is a source code management system that hosts Git repositories.
• Groups Dashboard: Shows the GitLab groups you are a member of and allows you to create new groups. A group allows you to manage settings across multiple projects and provides logical categorization of users or projects.
• Security Dashboard: Provides security-related information.
• Environments Dashboard: Shows information about project environments.
• Within a project, the left-hand menu provides access to sections like:
• Overview: Displays commits, branches, tags, and the project’s code. You can switch between branches (separate lines of development) using the branch specifier. The main branch is often the default branch.
• Issues: For managing and creating issues related to the project. Projects also have agile boards for issue tracking.
• Merge Requests: For managing and viewing merge requests related to the project.
• CI/CD: For configuring continuous integration and continuous delivery/deployment pipelines. A GitLab pipeline is a top-level component defining the CI/CD process for a project.
• Packages & Registries: For publishing and managing software packages, container images (Docker), and Terraform modules. The GitLab Package Registry allows GitLab to act as a public or private software package registry. The GitLab Container Registry is a private registry for Docker images. The Infrastructure Registry supports Terraform modules.
• Deployments: For viewing releases and environments. A release in GitLab can include packages, release notes, evidence, and a snapshot of the source code.
• Analytics: Provides project analytics.
• Wiki: For publishing project documentation.
• Snippets: For creating and managing code snippets within the project.
• Settings: Allows you to configure various project settings, similar to group settings but at the project level. This includes settings for merge requests (e.g., merge methods, merge checks), repository (e.g., default branch, protected branches), and CI/CD. Protected branches, like main and often production, restrict who can push changes to them.
• Within a group, the left-hand menu provides access to:
• Group Information: Includes activity, labels, and members. Members are GitLab users or groups with access to the group or its projects. Members are assigned roles with specific permissions.
• Issues: Shows all issues associated with projects in the group.
• Boards: Provides a lightweight agile board for group-level issue management.
• Merge Requests: Shows merge requests across all projects within the group.
• Settings: Allows you to manage general settings (name, ID, visibility), integrations with external tools, group-level CI/CD, and runners (processes that execute CI/CD jobs).

Key Terminology:

• Group: Manages settings across multiple projects, enables logical categorization of users or projects.
• Project: A container for a Git repository with built-in CI/CD and issue tracking.
• Member: A GitLab user or group with access to a project or group, assigned a role with permissions.
• Merge Request: A request to merge one branch into another, facilitating code review and discussion.
• Issue: A way to track work related to a GitLab project (bugs, tasks, features).
• Snippet: A small, shareable piece of code.

Account Settings:

You can access your account settings from the profile dropdown menu by selecting “Edit profile”. This area allows you to manage:

• General Information: Your name, email, etc..
• Access Tokens: For authenticating with GitLab via the command line or APIs. Similar to uploading files to Dropbox or Google Drive, GitLab hosts Git repositories for sharing, and access tokens can be used instead of passwords for command-line interactions.
• SSH Keys: Another method for command-line authentication. You generate an SSH key pair and add the public key to your GitLab profile. This allows your Git client to communicate securely with your GitLab account. The tutorial demonstrates how to generate an SSH key pair using ssh-keygen and add the public key to GitLab.

Project Homepage:

The project homepage provides a quick overview of the project’s activity and code. Key elements include:

• Codebase View: Displays the files and directories in the repository, with the README file often rendered at the bottom.
• Branch Specifier: Shows the currently checked-out branch and allows you to switch between branches or tags.
• New File/Upload: Options to create new files or upload existing ones directly through the web interface.
• Web IDE: A browser-based integrated development environment for modifying the codebase.
• Clone Repository: Provides the SSH or HTTPS URL to clone the repository to your local machine using the git clone command. Cloning downloads the project as a Git repository to your local machine, allowing you to make commits and push them back to GitLab.
• Quick access to create new branches or tags.

Understanding these components and how to navigate them is crucial for effectively using GitLab for source code management, collaboration, and CI/CD workflows.

The Original Text

Hey what’s up everybody my name is Moss and  Welcome to this tutorial series on GitLab in   this tutorial series I’m going to teach you how  to utilize some of the core features of GitLab   in this video I’m going to walk you through the  road map of topics that we’re going to cover   in the tutorial series as well as the learning  objectives and who this course is made for   I’ll also cover the first and  second topics of this course   in this video as well so without  further delay let’s dive right in   so for the first topic of this video we are going  to be answering the question what is GitLab and   then I’ll walk you through the basics of git but  before i do that let me introduce myself my name   is moss and I’m an experienced devOps engineer  with over six years of experience in industry   now let’s take a look at the roadmap of topics  that we’ll be covering in this tutorial series   as I already mentioned our first topic will  be answering the question What is GitLab then   I’m going to walk you through the basics of Git  and after that I’ll introduce you to the major   components of the GitLab interface once you’re  comfortable with the GitLab interface I’m going   to introduce you to the basic workflow in GitLab  called the git lab flow and once I’ve given a high   level overview of the GitLab flow we’ll perform  hands-on activities that utilize the GitLab flow   we’ll then dive into more advanced  topics starting with how to do CI/CD   in GitLab I’ll then show you how to  migrate your Jenkins pipelines to GitLab CI after that we’ll explore get lab’s packaging  and releasing features and finally I’ll show   you how to integrate the lambda test platform  with GitLab ci to perform cross browser testing   now let’s quickly go over our learning  objectives the first learning objective   is to give you an introduction to GitLab CI you  will also learn the fundamental commands of Git   you will know how to work in GitLab using the  GitLab flow you will also understand and be   able to perform CI/CD in GitLab you will know  how to migrate your Jenkins pipelines to GitLab   and you’ll learn how to deploy software using  GitLab’s packaging and releasing features   so who is this course for this  course is made for devOps engineers   software teams who want to migrate from Jenkins  to GitLab and developers whose team uses GitLab the prerequisite to this course  is that you have access to GitLab   or a private instance of GitLab so you  should have a user account on whatever GitLab   instance that you’re using you will also need a  recent version of git installed on your machine now let’s get into the first topic what is git lab   get lab is an open source software development  platform and at its core it is a source code   management system but it also offers additional  functionality like CI/CD on top of being a source   code management system and as you can see on the  right GitLab describes itself as a DevOps platform   so what’s the difference between Git and  GitLab Git is a version control system   you use Git to keep track of changes  made to source code files in a codebase in contrast GitLab is a source code management  system so you would use GitLab to host Git   repositories so that they can be shared with  other people on your team similar to how you might   upload and share files to dropbox or google  drive you’re doing the same with GitLab   but for source code so why use GitLab GitLab  enables collaboration among software teams with   the GitLab flow git lab also has built-in CI CD  functionality GitLab is highly interoperable and   it can integrate with other tools these are just  some of the features that gitlab offers but there   are plethora of other features now that we have  a high level understanding of What GitLab is ?  let’s dive into our next topic okay let’s get  ourselves up to speed with some basic git commands   this might be a refresher if you’re already  familiar with git but if you’re not let’s go   ahead and verify that you have git installed on  your machine i currently have my terminal open   and to verify my installation of git i’m going to  invoke git and i’m going to pass in the dash dash   version option and this will return the version  of git that is installed on my machine if it’s   installed and as you can see i have get version  2.33.0 installed so the first git command that   we should cover is the git init command and if you  don’t pass any parameters to the get init command   it will initialize the current directory as a git  repository so if i were to execute the get init   command as it is right now it would initialize  the lambda test folder as a new git repository   and it makes sense to use git init like  that if you have a pre-existing code base   that you want to check into version control and  initialize as a new git repository however if   you didn’t have a pre-existing code base that  you wanted to initialize as a git repository   then what you would do is you would pass  the desired name of the git repository   that you want to initialize as an argument to the  get init command and that’s the option that we’re   going to use and let’s call our git repository  test hyphen project okay and what this is   going to do is it will create a subdirectory  under the lambda test directory and uh that   directory will be called test hyphen project and  that will be our git repository so i’m going to go   ahead and execute the get init command and you can  see at the bottom here it says initialize empty   git repository in and then it specifies the path  of the git repository and then directly above that   it gives us an informational message about the  name of the default branch in our git repositories   and it gives us a couple of commands to rename  the default branch in our repositories so let’s   go ahead and do that let’s execute the first  command here which is git config dash dash global init dot default branch and then let’s set the  the default name to the default branch of our   Git repositories as main and then to execute the  second command we need to change directories into   the Git repository that we just created so I’ll  go ahead and cd into the test project directory   and then to rename the branch  of our current git repository   to main we will execute git branch dash  m and then the target name which is main   so if we take a look at the test project directory  it should be empty let me clear the terminal real   quick and if I do an ls there’s nothing in the  test project directory if I do an ls-al to see   the hidden folders in the directory you’ll see  a hidden folder called dot git and the dot get   directory is what makes the test project directory  a Git repository without the dot git directory the   test project folder is just a folder it is not  a Git repository it’s not tracking changes to   any of the files within the test project folder  so if i wanted to verify that the test project   directory is a git repository i can look for  the dot get folder and i can also do a git   status inside of the directory and this will also  tell me whether or not i’m in a git repository   and as you can see from the output of the git  status command we are currently on branch main   which is the default branch that was created  when we use the get init command and then   it says that there are no commits yet so  we haven’t generated any new git commits   uh in this repository so this repository  is essentially a blank slate it has zero   git history uh yet and then in the last line of  the output it says that there’s nothing to commit   so the git status command essentially  uh tells us what the current state   of our git repository is so if we’ve added any  new files to the test project directory or changed   existing files within the test project directory  when we perform a git status git status will show   all of those changes in the output git status is  a very useful command and you’ll find yourself   running git status very frequently when you’re  using git and working inside of a Git repository   now this git repository isn’t very useful to us  if there aren’t any files in the project that   we want to version control so what we can do  is add new files to the test project directory   and commit those new files on the main branch but  if we do that then we’re not taking advantage of   of git’s one of git’s most powerful features  which is branching so what’s important to know   is that the main branch in a git repository and  it’s not always called the main branch sometimes   it’s called the pristine branch or the stable  branch is a branch that is supposed to be code   that has no bugs in it it’s supposed to be  deployable code that can go to the customer and   because of that if you’re a developer who wants to  work on a new feature working on the main branch   is dangerous because while you’re working on that  feature you might commit some changes that cause   other parts of the code base to break and if the  main branch breaks that breaks the code base for   everyone not just for you so it’s really important  to understand as a developer you should never be   committing changes directly to the main branch  of your git repository so if you’re developing a   new feature in a git repository you always want to  make sure that you’re not developing that feature   on the main branch you should be developing it  on its own dedicated branch and you can think of   a branch in git as an entirely separate copy of  the code base it’s a copy of the code base that   you can work on and experiment in and develop your  feature in without having any impact on the main   branch of the code base so you would develop your  feature in this branch or this copy of the code   base and once you’ve completed your feature and  you’re confident you’ve ran tests on the feature   and you’re confident it can be merged into the  primary version of the code base you can actually   use git to merge your branch and your feature  into the main version of the code base   so we are going to follow the best practice  of creating a branch in order to make changes   in our repository but before we can actually  create a branch we do have to generate some   history so right now in our git repository  we have no commits made in the repository   so we have to make at least one commit in the  repository so that we can create a new branch   and use that branch to develop a feature so what  I’m going to do is create a new file in this git   repository I’m going to create it using vim so  I’m going to invoke vim and feel free to use a   different uh editor if you prefer a different  editor but I’ll call the file hello dot text okay and inside of this file  we’ll simply say hello okay so if I do an ls you can see that we now have  the hello text file in our Git repository   and how does adding the hello.txt file change  the state of our git repository well we can   check the state of our repository using the get  status command so I’m going to do git status   and you can see now we have a little bit  different output in the git status command   it says that we’re on branch main there have been  no commits made to this repository and then there   is one untracked file and that is the hello.txt  file and git is really useful in that it suggests   commands to use to progress through the the  workflow and it says use Git add and then the   file name to include in what will be committed  so what is the get ad command and what does it   mean to add a file to a git repository and to  answer that question I’m going to pull up uh the   get documentation in my browser and I’m already  at the target page and just for reference I’m at   get hyphen sem.com so in git there is a concept  of a two-stage commit and what that means is that   in order to commit changes to git repositories  history which means make a commit object a commit   object is what tracks a particular set of changes  to a git repository we have to use this two-stage   commit and it this two-stage commit process and  it begins with adding changes from what’s called   the working directory into the staging area and if  you’re wondering well how do i know whether or not   my changes are in the working directory or if  they’re in the staging area it’s pretty easy to   check where your change is at using the get status  command if I take a look back at my terminal   from the get status output we can tell whether  or not a change is in the working directory or if   it’s in the staging area if it’s in the working  directory those changes will show up in red as   they do here so this change is currently in the  working directory and we want to move it to the   staging area and what the staging area allows you  to do is commit changes that are logically related   to each other so in the working directory you can  make changes to whatever files and you can make   unrelated changes within files but you don’t have  to commit all of those changes at once what you   can do is you can stage those changes the changes  that are logically related to each other before   actually creating a commit object and creating  well-formed commits is actually very important   to do so in order to move changes from the working  directory to the staging area we have to use the   get add command followed by uh the the argument of  the get add command are the name of the files or   the directories that we want to add to the staging  area and then from the staging area in order to   to create a commit object we would use the git  commit command so let’s go back to our terminal   and add our hello.txt file to the staging area so  to do that i’m going to say git add hello dot text   okay and it doesn’t provide any  output from that command but it did   execute successfully and we can confirm  that by running the git status command again   so now our hello.txt file is in the staging area  and how do we know it’s in the staging area well   any changes that are currently staged will show up  in green and you can see here that git recognizes   that it’s a new file that has just been added to  the repository and in order to commit this file   to git’s history we would use the git commit  command and we can also unstage this file as   well and move it back to the working directory  and git tells us how to do that we can use Git   rm dash dash cache and then the file name  to unstage this file but we won’t unstage   this file we are going to follow through with  the two stage commit process and to do so we will   invoke git commit okay and if we invoke git commit  by itself what it will do is it will bring up the   default uh git editor and prompt us for a commit  message and a git commit message is essentially   a description a very concise description of  the change that we’re making so it’s metadata   on uh the changes that we’re making to the git  repository so that later on if someone wants to   review the changes made to the repository they  have concise summaries of all the changes that   have been that have been made within a single  commit so we can use git commit without any   arguments or options and if so it’ll invoke your  default editor and in my case it should pull up   vim and it does and it prompts me to enter a  commit message but the other option without   using without pulling up the default  editor so if I exit vim and do git commit   I can use the dash m option and this way I can  actually pass my commit message in inline with the   invocation of the git commit command so if I wrap  it in quotes I can then pass in my commit message   directly at the command line and this is the  option that I’m going to use and in my commit   message I’m simply going to say adding hello dot  text okay and end quotes and then I hit enter   and in my case it does give me a confirmation  message that a commit object was created   but if this is the first time that you’re  using this git installation on your machine   then when you invoke the git commit  command it will probably ask you to   enter a username and email address for your  git configuration so that when it creates the   commit object the metadata related to who  committed uh those changes and who was the   author of those changes will show up with your  information in my case I already have those   configurations set but if you want to set those  configurations now you would simply say Git config   and pass pass in the dash dash global option and  then we’ll say user.name and then you can pass in   your name so in my case I would just say moss and  then we can also say Git config dash dash global   user dot email and then you would  pass in your email same as the   username I won’t reset my email since I have it  uh already configured so I’m gonna do a control c   and now that we have a commit generated  in the repository we might want to review   the history of the repository at a later  date so how would we do that how would we   take a look at the commit that we just created  well to do that we can use the get log command   so if I invoke git log just like this it will show  a list of all of the commits that have been made   in the git repository so I’m going to go ahead  go ahead and hit enter and in the output of the   git log command we can see all of the metadata  related to a commit so in our case we only have   a single commit and on the first line here you can  see the hash of the commit object and the hash is   the unique identifier of that commit object  and directly next to the hash of the commit   is this head and then the arrow pointing to  main what this is saying is that the main branch   is um pointing to this commit so essentially the  main branch is up to date with the latest version   of the repository and then head and the arrow  here pointing to main this simply means that   we’re currently checked out to the main branch if  we made changes to the repository if we made new   commits on the repository it would be associated  with the main branch and then below that line we   have information on the author and this is  information that would have been configured   using these commands so I have the author name and  the author email address and then below that is   the uh creation date of the commit okay and then  directly below that is the actual commit message   that uh we provided in line when invoking the git  commit command okay so now that we’ve created our   first commit in the Git repository when I perform  a Git status we shouldn’t see the no commits   message in the output of the Git status command  and as you can see we don’t see it all we see   is that we’re currently on branch main and that  there is nothing to commit and the working tree   is clean meaning there’s no changes in the working  directory that could be added to the staging area   now if we want to make any additional changes  to the Git repository what we should do first   is create a branch so that we can work on those  changes on a separate branch that isn’t the main   branch so let’s say I want to modify the hello.txt  file and I also want to add a new file to the Git   repository so the first thing that I want to  do is create a branch and to create a branch   I can use the get branch command and then as an  argument to the get branch command I can pass   in the name of the the desired name of the branch  that I want to create so let’s call this branch   my hyphen feature and then I’ll hit enter so  that just created the branch and I can confirm   that it created the branch uh by just invoking  git branch without any arguments and you can   see that two branches are listed in the output the  main branch and then the my hyphen feature branch   but notice something is that the main branch is  highlighted green with this asterisk and what   uh that means is that we’re still working on the  main branch if we were to make any changes right   now add any new files those changes would be added  to the main branch if we were to commit them so   what we need to do is we need to check out to the  my feature branch so in git we call it checking   out to a branch and before we check out the my  feature branch let’s run uh git log one time   and you can see in the git log output  now uh not only is the main branch listed   in the output but also the my feature branch and  both of the branches are pointing to the same   commit right now but also notice that the head  pointer is currently pointing to main which means   that we’re uh that we’re working on the main  branch and any changes that we make would be   committed to the main branch and they would not  be applied to the my feature branch so let’s go   ahead and check out to the my feature branch and  to do that we can use git checkout and then the   name of the branch that we want to check out to so  I’m going to say git check out my hyphen feature   and it says in the output that we switch to branch  whoops that we switch to branch my hyphen feature   and if I run a git status you can see that  we’re currently on branch my hyphen feature   and that there is no changes to commit  and also if we run git log again   not much has changed but notice uh that  the head pointer is now pointing to the   my feature branch and it’s no longer pointing  to the main branch which further confirms that   we’re checked out to the my feature branch  and any changes that we make at this point   and commits that we create will be associated  with the my feature branch and they will not be   applied to the main branch so let’s add  some new changes to our git repository   and practice the two-stage commit process so the  first change that I’m going to make is to the   hello.txt file so I’m going to open it in vim but  feel free to use whatever editor editor you prefer and I will simply add world so be hello world   and we’ll save it and I’ll do a git status  and you can see in the working directory Git   prompts me it says changes not staged for  commit and then it shows here instead of new   file it shows that the hello.txt file was  modified and we can either use git add to   add those changes uh to the staging area or we  can use git restore and then the name of the file   to discard the changes in this case it would  remove the word world from the hello.txt file that   we just added if I were to run git restore and  then the file name git restore and then hello.txt   and then for the next change I’m going to create  a new file and I’m going to call it tess.txt and I’m going to say unrelated change and I’ll save it and then I’ll do git status again so the test.txt file is a new file which means  it’s going to be listed under untracked files   Git currently is not tracking the test.txt file in  order to track this file we have to add it to this   Git repository’s history and to add it to the the  history we have to make a new commit now remember   that I mentioned that we can stage logically  related changes together so that we can create   well-formed commits and it might be the case that  the change that I made to the hello.txt file is   unrelated to the addition of the test.txt file so  I might want to commit these changes separately so   let’s exercise the staging area and commit just  the changes made to the hello.txt file and then   we’ll create a separate commit for the addition of  the tests.txt file so to add the changes made to   the hello.txt file to the staging area I would say  git add and then hello dot text and then if I do   a git status we can see that the changes made to  the hello.txt file are in are now in the staging   area and then when we invoke git commit it will  only commit the changes that have been staged   to get’s history so if I say git commit dash  m and then we’ll say modifying hello.txt   I’ll hit enter so it created a new  commit and then if I do git status   the change where we added the test.txt file to  the repository is still in the working directory   and if I perform a Git log we should see  two commits in this git repository’s history   and we do and notice now that the branches are  not pointing to the same commit anymore the   main branch is pointing to our first commit in  the repository and the my feature branch is now   pointing to the latest commit uh made in  the repository where we’re modifying the   hello.txt file so now let’s add and commit the  test.txt file so I will say Git add test.text   and then git commit dash m and  we’ll say adding the test.txt file okay so that created a second commit so now  we have two commits on the my feature branch so if   we list the files in the test project directory we  can see the hello.txt file and the test.txt file   and if I were to cat the hello.txt file we can see  the contents of the file and it says hello world   so this is the latest version of the hello.txt  file on the my hyphen feature branch if we were to   check out back to the main branch you’ll notice  that the directory structure gets updated   as well as the hello.txt file so let’s  go ahead and check out to the main branch   so I’m going to use Git checkout and then main   and it says that we’ve switched to the the main  branch and I’ll confirm with Git status as well   and it says that we’re on the main  branch here as well so if I do an ls   you can see that the test.txt file is no longer  listed in the directory because on the main   branch the test.txt file hasn’t been created  yet and similarly if we can’t the hello.txt file   you can see that it’s the older version of  the hello hello.txt file that doesn’t say   hello world so while we made changes on  the my hyphen feature branch the history of   the main branch has remained intact nothing  has changed on the main branch we’ve only made   changes on a separate branch which remember we can  kind of consider almost like an entirely separate   copy of the code base it’s an isolated uh space  where we can make changes and experiment without   impacting um the main version of the of the git  repository but if we’re satisfied with the changes   that we’ve made on that branch then what we can do  is we can merge those uh changes and those commits   into the main branch and to merge a branch in  git we want to be checked out to the target   branch and then we’ll specify the source branch  that contains changes that we want to merge   so currently we’re checked out to the main  branch if I do a git status we can see that   we’re checked out to the main branch and the main  branch is the branch that we want to merge changes   into so now that we’re checked out to the main  branch we can use the git merge command to merge   the changes from the my hyphen feature branch  into the main branch and the only argument   that we need to pass to the git merge command is  the name of the source branch which in our case   is the my hyphen feature branch and real  quickly before we execute the command I want to   do a git log and I’m actually going to pass in  the dash dash all option in the dash dash one line   and dash dash all will show us the history  of all branches in the git repository and   dash dash one line will give us a nice uh one line  summary for each uh each commit in the repository   okay so there’s three commits in total  and you can see that the my feature branch   is pointing to this commit and then the main  branch is uh kind of behind it’s pointing to   the first commit that was made in the repository  so when we perform a get log after executing   the merge we should expect to see the  main branch pointing to this commit so   let’s go ahead and execute the merge  I’m going to say git merge my feature   and it gives us kind of a confirmation message  saying that it performed a fast forward merge   and we have a new file test.text and a couple  of lines were changed in the hello.txt file   and we can also confirm this by performing an ls  and we can see that the test.txt file now exists   in the test project directory and if i cat  hello.txt we can see it’s the latest version   of hello.txt which includes hello world and  finally let’s check the history using git log   actually i meant to use git log with the  one line option in dash dash all okay   so now we can see in the output here that the  main branch is pointing to the same commit   that the my feature branch is pointing  to so it includes the changes contained   in both of these commits and since the changes  that were made on the my hyphen feature branch   are now merged into the main branch there’s really  no need for the my hyphen feature branch so i’m   going to delete that branch and i can do so using  git branch dash d and then my hyphen feature now   there is one more very useful git command that  i’d like to show you so i’m going to go ahead and   clear the terminal and the command is git stash  the git stash command allows you to experiment   with various changes and save those changes  without actually committing them to the get   the git repositories history as a  commit so to show you what I mean   I’m going to make a modification uh to the  hello.txt file so I’m going to open it up   I’m going to add a word here I’m just going to  say hello world testing and I will save the file   so I’m going to run git status and we can  see in the output that the hello.txt file   has been modified and we can stage that change  to be committed or we can actually stash   that change where we added the word testing  to the hello.txt file when I use the git   stash command I’m taking all the changes that  are in my working directory and I’m stashing   stashing them away in a reserved location that’s  outside of git’s history and to stash our changes   to the hello.txt file i can either say git  stash or git stash push and that will stash   the changes made to the hello.txt file away so  I hit enter and it says saved working directory   and index state work in progress on the main  branch and if I perform a git status you’ll notice   that I have a clean working  directory that change no longer   no longer exists in the working  directory and if I cat the hello.txt file   the testing word is not included in the hello.txt  file that change that I made still exists but it’s   been stashed away and to see that change I can use  Git stash list and it will list all of the changes   that have been stashed by Git so i can see my  change in the stash at position zero and if i   want to reapply that change to the working  directory i can either use get stash apply   or i can use git stash pop and there is a  difference between these two commands when i   use git stash apply it will reapply the changes  to the working directory and you can see here that   now hello.txt is modified if I cat hello.txt i can  see the word testing in the file now but it will   not remove this change from the stash so if I do  get stash list again I can still see that change   listed in position 0. the only difference between  Git stash apply and get stash pop is that Git   stash pop will actually pop this uh change off of  the stash so that it is no longer listed in the   stash so if i perform a git stash clear it will  clear all of the entries in the stash i still   have my change applied in the working directory  i’ll stash this change again but i’m going to use   pop instead of apply so get stash push and then  get stash list okay and then i’ll do git stash pop   okay and it shows that the hello.txt file  has been uh modified and if i do git stash   list you can see that that stash entry has  been removed in later videos we’ll explore   a few more git commands but at this point  you’re ready to start working with git lab   and in the next video we’ll introduce you to some  of the major components of the gitlab interface hey what’s up everybody my name is moss and  welcome back to this tutorial series on gitlab   in this video we are going to focus on  getting you familiar with the gitlab interface   with the overwhelming number of features  that gitlab offers it’s easy to get lost in   the interface so we’re going to complete  some basic tasks so that you feel more   comfortable working in gitlab and prepare  you for the activities in upcoming videos   let’s take a closer look at  what we’re going to cover our first objective is to provide an  introduction to get lab terminology   our next objective is to become  familiar with the gitlab interface first let’s explain some important git  lab terms starting with group a group   will allow you to manage settings across  multiple projects at the same time a group   enables logical categorization of  multiple users or gitlab projects   a gitlab group can also provide a cross-project  view of things like issues and merge requests   the next important term is project a GitLab  project is essentially a container for a git   repository similar to GitHub repositories there  is a one-to-one mapping from a GitLab project   to a git repository a GitLab project  also has built-in ci cd functionality   you can also perform issue tracking inside of  a GitLab project in addition GitLab projects   provide collaboration tools like merge requests  these are just some of the features that a GitLab   project offers but they are the features  that we will primarily focus on in this   series another important term to be familiar  with are members members are GitLab users or   groups that have access to a GitLab project  in addition members are assigned to roles   and these roles include permissions to  perform actions on GitLab projects or groups one of the most important concepts  to be familiar with in GitLab   are merge requests a merge request  is a request to merge one branch   into another merge requests provide a space  to have a conversation with the team about the   changes on a branch and it is the central place  through which changes are reviewed and verified and finally we have git lab issues a GitLab issue  is a way to track work related to a GitLab project   and we can use GitLab issues to report bugs  track tasks request new features and much   more your software development workflow  should begin with the creation of an issue   a quick note as I said in the previous video  GitLab has a plethora of features so for the sake   of time I will only be covering the most relevant  features in the GitLab interface for this series   if I skip over a particular feature in the  interface it doesn’t necessarily mean that   the feature isn’t useful or important it  is only to keep our conversation focused on   the topics that will most likely be covered  in this series now that we’re familiar with   some of the key terms and concepts in GitLab we  can begin our activities in the GitLab interface okay so the first thing that we  want to do is navigate to gitlab.com and from here we’ll navigate to the login page so go ahead and log in to your GitLab  account and if you don’t have a GitLab   account already then you can create one by  just coming down here to the register now link   and you can follow the steps on this page  to create a new GitLab account and so if   that is the case then just pause the video  and create an account and then we will   log into our GitLab account after after the  account has been created so I’m going to sign in and the home page once we sign in is like  a projects dashboard it lists all of our   git lab projects and then we can also see  starred projects which are like favorited   projects and then we can explore other projects  on gitlab.com and from this page we can also   create a new project as well which we will do  shortly if we take a look at the navigation bar   on the far right we have our profile and we can  access our GitLab profile from this drop-down menu   we can set a status associated with our profile um  and then it allows us to upgrade to a higher tier   GitLab subscription then we can also edit the  profile and we can view our account preferences   and then we can also sign out from here and  next to our profile menu we have a support slash   help menu and next to the help menu we also have  this to-do list page which will basically show us   a list of items in gitlab that we’re um you know  that we need to be aware of like if there’s issues   assigned to us or merge requests assigned to  our account then those will show up on this page next to the to-do list page we have a merge  request drop down menu and this is where we can   access merge requests that have been assigned to  our account or merge requests where we have been   listed as a reviewer for that merge request  and then we have an issues page where we can   query issues across projects based on query  parameters and the default query here is where   my account is the assignee on the issue but we  could have any other query parameter in here like   where my account was at mentioned  for instance in an issue comment and next to the top level search we can  create new items in GitLab so some of   those items we can create new project  a new project slash reposito repository   we can create a new group and  we can create a new snippet   which is like a code snippet it’s just a small  snippet of code it’s not a full code base   and then in the left hand side menu we can access  various dashboards so for instance we’re in   the projects dashboard right now but we could  also access the group’s dashboard or security   dashboard or the environments dashboard and that  will show related information to those features   now before we create a new project i do want to  review the account settings of uh of a GitLab   account so you can get familiar with those and  we will update some information inside of the   account settings so from the get lab profile drop  down menu we will select edit profile and that   will take us to the top level of the account user  settings and then under chat we have access tokens   so there’s a few ways that you can  authenticate with your GitLab account   the first way is the most obvious is where  you go to the sign in page and you enter your   username and password but if you’re authenticating  via the command line you’ll likely use one of two   ways you’ll either authenticate using a personal  access token or you’ll you’ll authenticate using   an SSH key pair and this page allows you to  create new tokens or delete personal access   tokens for your account and when you created  a personal access token similar to how the   applications page was set up you can select scopes  for that personal access token which will define   the level of authorization that that token has to  your account so we can give it right permission   to repositories read permission the ability to  interact with the GitLab api below notifications   are where we can manage SSH keys for our account  and this is the method that we’re going to use to   authenticate with our account we won’t be using  the personal access tokens we will create an SSH   key pair and then on this page is where we would  add the public key of our of our SSH key pair to   this page so we would create a new public key for  GitLab account so that we can authenticate with it   and our Git client can communicate with uh our  GitLab account so now that we’ve gone over the   user settings I would like to prepare our git  client to authenticate with our GitLab account   and remember that i said that we were going to  use SSH keys to authenticate with our account   so what we’re going to do now is create an SSH key  pair and then add the public key of that key pair   to our GitLab profile so I’m going to navigate to  my terminal and open up a new terminal session and   in my terminal I’m going to invoke the SSH keygen  command so that’s going to be SSH hyphen keygen   and then we’re going to use dash t option and  we’re going to specify the kind of encryption that   we want to use and we’re not going to use RSA  GitLab it advises to use this type of encryption   and suggests that it’s more  secure than RSA so ed25519 and then we will add a comment to this key  and we’ll say that it’s our get lab key pair   okay and after you’ve typed that in go ahead and  hit enter and it prompts us to enter a file name   in which to save the key in this case we’re going  to accept the default file name and notice where   this key is being saved it’s being saved in  the hidden .ssh folder and that’s going to be   the name of our key pair so the name of the  private key and the public key and only the   file extensions will be different between  the public key and the private key   so I’m going to hit enter and then it prompts  us to enter a passphrase for the key pair and   I’m going to leave it empty for no passphrase  I’ll hit enter again and then that generated the   the key pair for us in this directory in  the data ssh directory now what we’re going   to do is add the public key of that key pair  that we just generated to our GitLab profile   and to do that we’ll first cat the  public key so I’m going to cat dot ssh ed id underscore ed dot pub okay for the  public key pair or for the public key rather   and then I’m going to copy the output to my clipboard and then I’m going to  navigate back to the GitLab interface   and we’ll navigate to SSH keys  and then I’m going to paste in   in the key field I’m going to paste in the  value of the public key in the key field okay   and then the title is the comment that we added  when we generated the key so get lab key pair   and we can set an expiration date if we want to  I’m going to leave that blank so that does it   doesn’t have an expiration date and then I’m going  to select add key so now that we’ve added that   public SSH key to our account we should be  able to authenticate with our GitLab account   from the command line and to verify that we can  authenticate I’ll open up the terminal and then I   can invoke my SSH client I’ll use the dash capital  t option and then we’re going to say get at get   lab.com okay and I’m using gitlab.com uh because  my account is on gitlab.com if you’re using   uh like a private instance of GitLab then you  would want to specify uh that private instance URL   okay so if I hit enter it says welcome to GitLab  and then it specifies my username which means that   it did successfully authenticate with my account  okay so now that we know our SSH key pair is   working let’s navigate back to get lab and I want  to take a look at the groups dashboard so from the   left hand side menu I’m going to select groups and  let’s navigate to the your groups page and on the   groups dashboard you can see that I’ve already  created a group called tech with moss group but   let’s go ahead and create a new group so up in  the top right here I’m going to select new group and then I’ll select um create group and then  I can give the group a name so feel free to   to enter whatever name you prefer here I’m gonna  say moss test group okay and then I can specify a   unique group URL and then under the group URL we  can specify the visibility level of the group uh   whether it’s private or public if it’s public then  the group can be viewed without any authentication   and then they have some personalization options  for this group so I can specify what my role is   and I’m going to leave it as software developer  but you can see here that they have other roles   that you can select and then it says who will be  using this group and I’m going to specify just me   instead of my company or team but if I do select  my company or team I have this drop down where   I can specify what the group will be used for and  then I can also invite members to the group using   their email address so I’m going to select just  me and then i’m going to select create group and on the group homepage i can see subgroups  and projects that are associated with this group   so a group can have a subgroup and from this page  i can also create new subgroups or new projects   that are associated with this group this moss  test group and in the left-hand menu of the   group i can access the group information which  will include the group activity labels and then   members and from the members page we can control  the membership that people have to this group so   you can see here there’s one member and it’s  my account and i am the owner so my role is   the owner for uh this moss test group but i can  add additional members uh using their uh email   address and then i can specify the role that  that member would have when they’re added to   this group and below group information i can  select issues and if i select issues it will show   me all issues that are associated with this group  which there might be issues created in multiple   projects so this view inside of the group will  actually show issues across projects and in the   board section i can also utilize a lightweight  agile board you can see here that has issues   that have a status of open will show up  here issues that have a status of close   will show in this column and then you can also add  additional columns to match you know your desired   issue workflow and below issues we can also view  merge requests so if i select merge requests   we would get a view of merge requests that again  are across projects so it would be all projects   that this group is a member of so you can add  groups as members to gitlab projects right   so any merge requests that show up  here would be across all the projects   that this gitlab group is a member of and  then finally we have the group settings   and under the group settings we have general  settings where we can control things like the   group name the group id the description of the  group we can upload a group avatar kind of like   how we can upload an avatar for our profile and  we can also control the visibility level we can   control permissions and enable large file storage  or disable large file storage and that’s Git lfs   we can enable default branch protection which  allows us to protect certain branches so that   developers cannot push new commits to to  specific branches under the general settings   we have integrations and this is where we can set  up new integrations uh with external tools uh like   atlassian bamboo for ci cd we could integrate uh  get this GitLab group with a confluence workspace   also with JIRA we can also specify group  level ci cd and here we can define group   level variables which can be referenced  from within a GitLab ci cd pipeline   and we can also configure runners  which i won’t get into too much detail   about right now I’ll leave that for a later video  but essentially if you’re familiar with Jenkins   agents runners are are kind of a similar  concept runners are processes that pick up   and execute ci cd jobs uh for git lab so now  that we’ve explored the interface for groups   let’s navigate back to the home page and from the  home page let’s go ahead and create a new project   so I’m going to navigate up to the top  right and I’m going to select new project and on this page we can create a blank project so  we start a project from scratch or we can create a   project from a project template if we’ve created a  project template and we can also import a project   so for migrating uh you know our source code  from another source code management system uh   like GitHub we can use this import project feature  and then the last option here if we want to use   GitLab purely like as if we were uh using it like  Jenkins where it’s just performing ci cd for us   we can still utilize a external source code  management system like GitHub and then we’ll   just use the ci cd feature that GitLab offers  to facilitate CI/CD for our project but in our   case we are going to create a blank project so  I’m going to select the create blank project   and then it takes us to a page where we can  fill out uh some details on our project now   you can use the project name field to provide  a name for your project but if you leave   this field blank and you provide a  project slug which will be essentially the   the URL or part of the URL of the project  then it will automatically fill in the project   name field for you so I’m going to use that  option and I’m going to call the project moss   hyphen test hyphen project okay and notice  that the project name field automatically   gets filled in as I enter the project slug I  can also specify where this project should live   by using this drop drop down I can specify a group  or a specific user right now it’s under my account   tech with moss so I’m going to leave it under  tech with moss and then I can provide a project   description if that is applicable and under the  description i can specify a visibility level so   whether or not the project is going to be private  or public and then if it’s a public uh project the   project can be accessed without authentication to  get lab if the visibility is set to private then i   have to explicitly grant access to each user or to  a group by adding them as members to the project   and then the last setting allows us to  initialize the repository with a readme file   which we would do if we didn’t have an existing  code base locally that we would want to push   up to this gitlab project and we don’t in our  case so i’m going to leave this setting checked   and then i’m going to select create project so here we have the home page of the project and  we can access the commits the branches uh the   git tags that have been created and then it tells  us a little bit of information about the storage   that this project is utilizing and  if i exit out of these messages   we can see the actual code base and  all of the files in the code base   and right now there’s just the readme file  but you’ll notice that below the directory   the readme file is automatically rendered at the  bottom of the page and the readme file was also   automatically filled out with some resources to  help us get started with our project and above the   root directory we can also see a couple of other  things the first is the branch specifier so right   now we’re checked out to the main branch so the  version of the code base that we’re viewing here   is the version on the main branch and if we wanted  to switch branches and view a different branch   we could just select the drop down and either  search for a branch or a git tag and then check   out to that branch in our case we don’t have any  other branches in this repository so we only have   the main branch as the only option and then next  to the branch specifier we have the option to   create new files upload files we can also create  a new directory and this is all within the current   directory that we’re that we’re in  and we’re in the top level directory   right now but we can also create a new branch  or we can create a new tag a new git tag   and another really cool feature is we can use a  web ide to modify the code base in our browser   without having to download it locally and modify  it in our local ide and next to web ide we also   have the option to download the source code as a  compressed file and then finally we can clone the   repository using either ssh or https and we didn’t  cover the git clone command in the last video   but we will cover it in an upcoming video but  essentially cloning means that we are downloading   this project as a git repository to our local  machine so that we can make commits to the   repository and then push those commits back up  to git lab so the key difference between cloning   and downloading as a compressed file is that if we  were to download it as a compressed file it’s not   technically a git repository so we wouldn’t be  able to make commits inside of that compressed   file after we’ve extracted the project and then in  the issues section we can manage and create issues   related to this project and we also have agile  boards similar to what we saw in the groups   settings page as well below the issues section  we have merge requests and this is where we can   manage and view all of the merge requests related  to this project and right now there are none but   we can create a new merge request from this page  i think we can also create a merge request from   the home page of the project as well under merge  requests we can configure cicd for the project   so we can create new pipelines and we will  explore this feature in later videos but we can   create new gitlab pipelines and pipeline jobs  and we can set schedules for those pipelines   in the packages and registries section  we can publish software packages to the   package registry and then we can also utilize  the container registry to publish docker images   and in the infrastructure registry we can publish  terraform modules if we have any terraform modules   and under analytics is the project wiki and the  wiki is where you could publish documentation   related to the project so for instance  if you had architectural documentation   describing the architecture of your application  you could publish it to the project wiki and the   gitlab project can have snippets of code so you  can create a snippet of code which essentially is   a small piece of code it might not be an entire  code base or an entire file from a code base   it could be just a single function from a file  that might be useful to others so maybe you   could share that function with others and you can  use snippets to do that a snippet can be shared   with other users it can be version controlled  and downloaded now for the project settings i   won’t go into too much detail because what you’ll  notice is that a lot of the settings are similar   to group settings but they are at the project  level so if i go into settings and then general   you’ll see very similar fields to the group  settings fields with the exception of merge   requests so this is a big one you can configure  various settings related to merge requests   in your gitlab project so for instance you can  specify what kind of merge method you would   like merge requests to take so down here under the  merge method we can specify whether or not we want   a merge commit a merge commit with a semi  linear history or a fast forward merge   you can also specify the default behavior for  squashing commits when merging a merge request and   then you can enable merge checks as well so for  instance we can enforce that all pipelines must   succeed before the merge request can be merged in  the repository section we can configure various   settings related to branches in the gitlab project  so for instance we can set the default branch of   the project which means that any time we were to  open a new merge request the target branch would   automatically be selected as the default branch  another important setting are protected branches   it’s typically a best practice to protect the main  branch or your stable branch or your production   branch since protecting the branch means that only  certain people can actually push commits to it   and also you can disable force pushing to that  branch so nobody can override the history of uh   of a protected branch and under the monitoring  settings we can also control settings related to   gitlab pages which is a pretty cool feature pages  essentially allows you to host a static website   off of this gitlab project so now that we’re  familiar with the project’s features and settings   i’d like us to go ahead and create a new issue  in this project so i’m going to select the issues   section and in the issues section i’m going to  scroll down and i’m going to select new issue so for the title of the issue i’m  going to say modify the project readme and for the issue type i’m going to leave it  as issue but if we select this drop down we   can also select a different issue type in this  case we have the incident issue type as well   in the description of the issue i’m going  to say modify the project readme file to practice the get lab flow and what’s cool  about the description field is that we can utilize   markdown syntax in this field and then we can  preview that syntax in the preview field so   right now we’re not using any markdown but i can  modify this and i’ll add a hashtag and a single   hashtag will give me a header so if i preview  that i now have um a markdown header i’m going   to change this hashtag to a bullet and then i’ll  scroll down and i’ll leave the remaining fields   empty but we can assign the issue to a specific  user in the project right now i’m the only user   in the project we can also add a due date for the  issue and we can associate it with a milestone   in the project and we can also add labels to the  issue as well and now i’ll select create issue so now that we have the issue created you may  remember at the beginning of the video when i   was discussing the definition of issues i  mentioned that your software development   workflow should always begin with the creation of  an issue and in the upcoming videos i’m going to   introduce you to the gitlab flow which is  the primary workflow that you would utilize   uh in gitlab and we’re going to  practice the gitlab flow by modifying   the readme file so thanks for watching  and i will see you in the next video hey what’s up everybody my name is moss and  welcome back to this tutorial series on gitlab   after watching the previous video you should be  comfortable navigating the gitlab interface and   this means we can start practicing our development  workflow inside of gitlab to do this i’m going   to introduce you to gitlab’s primary branching  strategy so if you haven’t already go ahead and   grab a coffee and let’s get started in this video  i’m going to introduce you to the get lab flow by the end of this video you  should be able to do the following   describe the concept of a branching  strategy describe the gitlab flow   and explain the differences between the  gitlab flow and other branching strategies what is a branching strategy a branching strategy  is a software development workflow within the   context of git or another version control  system and it describes how a development   team will create collaborate on emerge  branches of source code in a codebase   we practiced a very basic branching strategy  in the first video using a feature branch   a branching strategy takes advantage of the  branching system in a version control system   to enable concurrent development in  the code base but how do you choose   a branching strategy unfortunately  this is not a straightforward question   as it depends on multiple factors these factors  include but are not limited to team requirements   the source code management system that you’re  using the environments to which code is deployed   and how you want to manage deployment to those  environments and the structure of your code base some of the most common branching strategies  in git include the following the GitHub flow   the git flow and the git lab flow let’s take  a look at each of these branching strategies we’ll start with a GitHub flow the GitHub flow  is the simplest workflow of the three each of the   white circles in the graph represent git commits  the GitHub flow begins by creating a feature   branch off of the main branch while checked out  to the feature branch we would make some number of   changes until we feel like our feature is ready  to be reviewed by others and undergo automated   testing we would then upload our changes to  GitHub by using the get push command this action   is commonly known as pushing our commits after  pushing our changes we would open what’s known   as a pull request a pull request is the equivalent  of a merge request in git lab the opening of the   pull request should trigger automated testing  of the changes located on the feature branch   once the changes have been reviewed and verified  the feature branch is merged into the main branch now let’s take a look at the git flow the git  flow is the most complex of the three workflows   the git flow utilizes a long-lived develop branch  as the default branch from which developers create   feature branches the git flow also utilizes  release branches which are created off of   the develop branch if a bug is found during  testing on the release branch a bug fix can be   applied to the release branch and then merged  back into the develop branch release branches   are then merged into the main branch and main  is tagged with the release version using a git   tag in a perfect world the changes merge from the  release branch into the main branch are bug free   since it is unrealistic to expect that this is the  case every time a release branch is merged the git   flow includes hotfix branches the hotfix branch  is created directly off of the main branch to   quickly address issues introduced by the changes  that are now in production in addition to merging   the hotfix branch back into the main branch  it is also very important to merge the hotfix   branch into the develop branch to ensure that  any new development work incorporates the hotfix now let’s explore the GitLab flow and its  variations the GitLab flow is simpler than the   Git flow but more structured than the GitHub flow  there are two variations of the GitLab flow the   first as seen here utilizes environment branches  in this workflow we have a long-lived production   branch which represents the production environment  in which the software application is deployed   the code on the production branch should always  be deployable like the GitHub flow this workflow   utilizes feature branches off of the main branch  but main is merged into some number of environment   branches and then to the production branch you  can think of merging a feature branch into the   main branch as deploying your changes to a  staging environment once changes have been   verified in the staging environment they can be  promoted to the production branch you can have   multiple pre-production environment branches  representing various environments in which the   changes must be tested in before merging  those changes into the production branch   unlike the git flow the GitLab flow has an  upstream first policy when it comes to hot fixes   this means that if issues are found in the  production environment after a change has been   deployed the hotfix branch must be created off  of the main branch and merge back into main and   any other pre-production branches before being  merged into the production branch the feature   branching workflow is similar to the github flow  but instead of creating a pull request we create a   merge request like the github flow the opening of  a merge request should trigger automated testing the second variation of the gitlab flow utilizes  release branches instead of environment branches   you should use this variation of the workflow only  if you’re releasing software to the outside world   for instance if you are developing an open source  project this variation is similar to the first   in that you branch off of the main branch into  feature branches and then merge back into main   in this workflow you will want to wait as

long as  possible to create a release branch after creating   the release branch apply only major bug fixes to  the release branch incrementing the versioning as   needed bug fixes are merged with the upstream  first policy release branches are long-lived   until a specific release of software is no longer  supported or maintained by the development team let’s quickly recap the GitLab flow there  are two variations of the GitLab flow   the first variation utilizes long-lived  environment branches in this workflow changes   are promoted through one or more pre-production  branches before being merged into the production   branch the second variation utilizes release  branches this variation should only be used   when releasing software to the outside world  such as an open source project the GitLab flow   is simpler than the git flow however the git lab  flow provides more structure than the GitHub flow hey what’s up everybody my name is moss and  welcome back to this tutorial series on GitLab   in the last video I introduced you  to the concept of the GitLab flow   and in this video we are going to apply the GitLab  flow to the project that we previously created I   talked about two variations of the GitLab flow  in the last video and in this demonstration   we’re going to be utilizing the environment  branches variation before we get started   let’s quickly review the learning objectives  for this module on practicing the GitLab flow after completing this video you should be able  to do the following sync changes between local   and remote git repositories create merge  requests demonstrate familiarity with   the components of a merge request and apply  the GitLab flow in your own GitLab projects   now that we’ve covered the learning  objectives let’s get started   okay so I’m on the homepage of my GitLab account  and if you haven’t already go ahead and sign into   your GitLab account and once you’ve done that  we’re going to navigate to the GitLab project   that we created in a prior video I called  when I created that project I called mine   moss test project and I’m  going to open that project up now you might remember from the previous  video when we created this project   after creating the project  we also created an issue   within the project and let’s navigate back to that  issue it’s under the issues section and then list and then we only have this  single issue in the project   called modify the project readme  so let’s open that issue up I mentioned earlier that the get lab flow  should begin with the creation of an issue   an issue helps define the scope of work  that needs to be completed and the scope of   this issue is not well defined right now it  just says modify the project readme without   any additional information to specify what what  should be modified in the readme or how it should   be modified so let’s edit this issue and update  it to be more specific on what updates should   be made to the project readme file so to edit  I’ll select the pencil and i’m going to use some   markdown syntax that we haven’t seen yet so if you  want to uh create a check box that you can check   with markdown you can use hyphen open  bracket space close bracket and then text so   temporarily i’ll just put hi and then if i  preview i can see that next to hi is rendered   a checkbox that i can select now i can’t select  it right now because i haven’t saved the changes   but you can use this in issues to create like  tasks that you can check off within the issue   and for this task i’m going to say  that we should introduce ourselves   in the project readme and i’ll select save changes  and get lab recognizes these check boxes as   subtasks within the issue and to confirm that you  can see up here it says zero of one task completed   and the single subtask that we have in this issue  is just to introduce ourselves and project readme   so GitLab will actually track uh how many subtasks  have been completed within an issue using these   markdown checkboxes now since I’ll be working  on this issue I’m going to assign it to myself   and I can just go up here select edit  and then I can search for a user but   I’m the only user in this project so  I’m going to select myself and now that   we’ve further defined the issue let’s  navigate back to the project homepage and from the home page we’re  going to create a new branch   remember at the beginning of the video  I said that we’re going to be using   the environment branches variation of the GitLab  flow so to create a new branch I’m going to   come down to this drop down here and I’m going  to select new branch and this branch is being   created from the main branch and we will call  it production okay so this will represent   uh pushing changes to this branch will represent  pushing changes to the production environment for   for our code base even though this isn’t really  a code base right now it’s just the readme file   so i’ll select create branch and you’ll notice that after creating the  branch we’re automatically checked out to the   production branch or the branch that we created  so i’m going to switch back to the main branch let’s take a look at the branches  that we have in the repository now   so i’m going to navigate to  this subsection here branches   and we have two active branches we have the main  branch which is listed as the default branch   and the production branch in addition to being the  default branch the main branch is also protected   which means that only people in the project with  certain permissions can push changes to that   branch and since we’re utilizing the environment  branches variation of the GitLab flow I think it’s   a good idea to also protect the production branch  since that represents our production environment   and I don’t think people should be able to push  changes to the production branch unless they   are a specific role in the project and as it  says up here we can control protected branches   in the project settings so I’m going to click  on that and navigate to the project settings   and then scroll down to the protected  branches section and we’ll expand that and says by default protected branches restrict  who can modify the branch so under the branch   selection I’m going to select the production  branch and then we’ll select who is allowed to   merge into the production branch and we’ll say  only people with the maintainers role can merge   into the production branch and uh we’ll also set  the same for people who are allowed to push to the   production branch only maintainers can do so  and the last setting lets us allow or disable   force pushing to this branch and it is a best  practice to not enable force pushing on shared   branches the only time it’s it might be okay  to force push as if you’re on an isolated   branch and you know that you’re the only person  working on that branch so now let’s click protect and now that branch is a protected branch should  be listed under here yep we can see it listed   along with the main branch as a protected branch  so let’s navigate back to the project homepage although we can modify the readme file in get  lab what we’re going to do is modify it locally   on our machine so we have to get the the project  onto our machine and to do that we have to clone   uh the project so even though it’s called  a project uh behind the scenes it is a git   repository and when you want to um begin working  on a git repository locally on your machine   you have to clone the repository which will  essentially download the code base to your   local machine so you can work on it and we can  clone a repository by copying the clone command   specified in this drop-down and we have two  selections or two options we can clone with ssh   or we can clone with https and if you  remember from an earlier video we set up   ssh keys for our gitlab account so we won’t  be using the clone with https method we’ll   be using the clone with ssh method instead  so i’m going to select this copy url button   and now that it’s copied to my clipboard  i’m going to open up my terminal and in my terminal i’m going to paste the command  or rather the ssh url of the repository or of the   gitlab project and then i’m going to preface  it with the command git clone so the git clone   command is what we use to copy a git repository  from the remote source down to our local machine   okay so after git clone we just specify uh  the remote repository so i’m gonna hit enter okay and it looks like it successfully  downloaded the project and it created a   directory called moss test project so if i do an  ls i have moss test project and if i cd into it   and i list uh all the files i have the dot  get folder so that tells us that we are   inside of a git repository and we have the  single readme file that’s in the repository   if I do a git status I’m checked out to the  main branch the reason I’m checked out to the   main branch after cloning is because it’s  the default branch so whatever the default   branch is when you clone that git repository  you will be checked out to that branch so to   begin the GitLab flow I have to branch off  of the main branch into a feature branch   so that’s what I’m going to do now and I’m going  to use the git checkout command to create a branch   I can use git branch to create the branch or I can  use git checkout with the dash b option which will   create the branch and check me out to that branch  in one command and we’ll call the branch readme hyphen introduction okay and you can see in the output it says switch to  a new branch read me hyphen introduction and if   I do a git status I can see that I’m on the readme  hyphen introduction branch and now that we’re on a   feature branch we can begin making modifications  uh to the code base and in this case we’re not   modifying code we’re just modifying the readme  file and to modify the readme file I’m going to   open it up in vim but feel free to use whatever  editor you prefer to to modify the file in   so i’ll say vim and then readme and under  the first header i’m going to put a subheader   okay so a markdown subheader using two  hashtags and i’m going to call it introduction and under the introduction section  feel free to put whatever you like   for me i’m going to put my  name so i’m going to say name moss and then uh activities i like to do and i like to mountain bike and play tennis okay and i’m gonna put  a new line uh between the subsection   and the bulleted list okay so now let’s save and  quit the file okay and i’m gonna do a git status   and we can see our modifications are currently  in the working directory for the readme file and   I’m going to add and commit the changes to the  readme file so I’m going to say git add readme okay so now the changes are uh staged and let’s  commit the changes so I’m going to say git commit   dash m so that I can pass in the commit message   directly at the command line I’m going to  say updating project readme with introduction   okay so now in our local copy of the repository  we have created a new feature branch and we made   a change and committed that change on the feature  branch but neither the branch or the change that   we made on that branch is currently represented  in the remote repository so if we were to navigate   to get lab and I refresh the page we’re not  going to see the branch that we just created   or the changes that we just made to the repository  and that’s because git is a distributed version   control system and we have to sync changes from  our local repository uh to the remote repository   so if we’re syncing changes from our local  repository to the remote repository we have   to push our changes and we would use the git  push command to do so however if we’re syncing   changes in the opposite direction from the  remote repository to our local repository   then we pull changes and we do that using the  get pull command now right now there’s no changes   from the remote repository that are not in our  local repository so we don’t have to do a get   pull but there are changes locally that we should  push up to the remote repository so we’re going to   use the get push command and since this branch  doesn’t exist yet on the remote repository the   readme hyphen introduction branch  we have to pass in the dash u option   and specify the name of the remote  which by default is going to be origin   and after we specify uh the name of the remote  and origin is just going is a variable that’s   resolving to gitlab essentially it’s it’s  resolving to the url of the gitlab project   after we’ve specified the name of the remote  we specify the branch name so we’re going to   say origin and then readme hyphen introduction  okay so we’re pushing our changes the commits   that we made uh from our local branch up to get  lab and we’re also passing in the dash u option   to tell git lab uh to create the readme hyphen  introduction branch so i’m going to hit enter okay and in the return message it does confirm  that the changes were pushed up and it also tells   me that i can create a merge request from  the branch that was just created in gitlab   and you can see down here as well  that it specifies that there is   a new branch okay so let’s navigate back to  gitlab and confirm that so i’ll refresh the page   and you can see in the top message here it says  you push the readme hyphen introduction branch   and in the drop down list we can  now see that branch as well and if   i were to switch to the readme introduction  branch we should be able to see the changes   in the readme file and you can see under the  project name we have the introduction section   and the bulleted list uh with my name and the  activities that i like to do okay so the changes   were pushed up successfully and from here we can  actually create a merge request and it suggests   uh creating a merge request here as well so i’m  going to go ahead and select create merge request and on the merge request creation page you can see  in the title the title is automatically generated   from the latest commit message on the readme  introduction branch so if i open the terminal   you can see where i entered git commit that  was my commit message okay and i’m going to   leave the the title as is the other thing to  notice is the branch that we’re merging into   uh it says from readme hyphen introduction into  main so why is the main branch chosen as the   branch that we’re merging into it’s the default  branch so not only does that mean when we clone   the repository that will automatically be checked  out to the main branch but also when we open new   merge requests we’ll automatically be merging our  feature branch into the default branch which in   this case is the main branch and this also follows  the guidelines of the gitlab flow as well the   feature branches are supposed to be created off  of the main branch and then promoted to maine and   then to some number of uh pre-production branches  before being merged into the production branch   and in the description of the merge request I’ll  be a little bit more descriptive about the change   I’m gonna say that i updated the readme to include  my name and activities that I like to do okay   now if we take a look at the  fields below the description field   we have an assignee field and I’m  going to assign this merge request   to myself and then we have a reviewer field and in  this case I can only assign myself as a reviewer   but ideally you would always want a second pair  of eyes to review the code changes that you’re   submitting in a merge request but in this case I  am going to select myself as the reviewer as well   and then we can specify the milestone uh if there  is a milestone associated with this merge request   and we can also add one or more labels uh  project labels to this merge requests as well   so this is labels are used as a way of kind  of categorizing changes so for instance maybe   if this merge request was changing the UI of our  application we would have like a UI project label   that we could uh add to this merge request is kind  of a tag that is searchable if someone were to   search merge requests in this GitLab project and  then the last two options are merge options and   the first of which is automatically selected which  is delete the source branch when the merge request   is accepted and in this case we are going to  leave that checked because we’re merging a feature   branch into the main branch and feature branches  are supposed to be short-lived they shouldn’t be   long-lived branches like the main branch in  the production branch so we will leave that   checked for the second option squash commits  when merge request is accepted uh this one we   will leave unchecked but squashing commits can  be a useful feature uh basically what it means   is that let’s say you had a hundred commits and  uh maybe there was a large percentage of those   commits where you were just fixing small things  like adding a semicolon to the end of a statement   or adding a comment here and there uh it would  be useful to reduce the number of commits and to   do that you can squash one two or more commits  together into a single commit if you wanted to   but I’m going to leave that option unchecked  and I’m going to select create merge request okay so after the merge request gets  created we’re brought to this page   with three tabs of information the overview  tab the commits tab and the changes tab and   in the overview tab we have kind of a summary of  all of the activities that are happening in the   merge requests the overview tab is really where  the conversation about these changes will happen   so we can see the description of the merge  requests and in addition to that we can see   other events um like where I requested a  review for myself and I also assigned this   merge request to myself we can add comments uh  from this page as well and we can also control   the workflow of the merge requests on this tab  as well so from this overview tab we can approve   the merge requests and we can also proceed with  merging the branch into the main branch as well   and the approve button is available to  me because I’m assigned as a reviewer   of this merge request so I can review it since or  I can approve it since I am a reviewer but you’ll   notice that next to it says approval is optional  and for the free tier of git lab uh you can’t   enforce approval before a branch is merged but  if you have a higher tier of GitLab then you can   there’s a setting where you can enforce that uh  one or more approvals have occurred on a merge   request before it can be emer uh before it can  be merged so this merge button would be grayed   out if uh if that feature was enabled or if  that setting was enabled and if I scroll up   and select the commits tab i get a list  of all the commits that are included   in this merge request and then if I select the  changes tab I can see a diff of the changes   that are included in this merge request  as well so in the diff that you see here   we’re comparing the main branch with the latest  version of the readme hyphen introduction branch   if we had made more than one commit on the readme  hyphen introduction branch then we could select an   older commit and compare an older commit on that  branch with the current version of the main branch   it also shows me how many files have  changed and how many lines have been added   and how many lines have been removed and  in the settings or the preferences here   i can compare changes in line or in a side-by-side  view where it will show uh the main branch version   of the readme file on one side and the uh readme  hyphen introduction branch on the other side   okay so we have this side by side diff available  to us as well I’m going to select the inline diff   now a very useful feature for reviewers and  participants of a merge request is the ability to   comment on each line of code in a diff okay so if  I hover over each line I have this comment button   and I can add a comment to that line or I  can do as it says I can drag for multiple   multiple lines so I can comment on uh all of these  lines from line three to line six okay I can add a   new comment for that entire block that we added  or I can add a comment for a single line okay   so now I’m going to act as my own reviewer and  I’m going to request some changes to line six and   I’ll ask myself to add an additional activity  to the list of activities that I like to do okay and I can either start a review or just  add a comment and since I’m requesting changes   I’m going to select start a review okay and  it says submit review and I’m going to do that and now that that review has been submitted  i should be able to see it on the not only in   the diff in the changes tab but i should also be  able to see it in the overview tab as part of the   activity so if i scroll down now i can see that  i started a thread on the diff and i can see the   comment that i added here and since i requested  changes i as the creator of the merge requests   should make those changes those requested changes  and then when i’ve done so i would select resolve   thread to indicate to the reviewer that i did make  those changes so i’m going to go ahead and make   the changes that were requested on the readme  file and i’m going to make the changes locally   and not in the editor and when we make changes  locally and we push them after a merge request   has already been created for a branch those  changes will be automatically associated with   the open merge request for my branch so let’s  go ahead and navigate back to the terminal and i’m going to open the readme file in vim and in the activities line i’m  going to add one more activity okay so i like uh mountain biking tennis and  going to the beach all right so i’ll go ahead and   save and quit and I’ll do a git status and  I’ll add the changes to the staging area and then I’ll do a git commit  well actually let me do a   get status real quick okay they’re in the staging  area and then I’ll do a git commit dash m and   I’m going to say adding third  activity to readme to project readme all right okay so if I do a git status I have  one commit so I’m ahead of the remote branch and   it says use git push to publish my changes so I’m  going to do that I’m going to say git push without   the dash up option because I’ve already created  the readme hyphen introduction branch in git lab and you’ll notice in the output of the git  push command now it says we get a message   from the remote and it says view merge  request for readme hyphen introduction   so it recognizes that we already have a merge  request open for this branch and it specifies   which merge requests merge requests number one and  then if I navigate back to the GitLab interface   we can see automatically in the merge requests  the merge request gets automatically updated   with the latest commit that was pushed  to the readme hyphen introduction branch   and in the review that I started on line six git  lab recognizes that I modified this line after the   review was started and so it adds kind of like a  reply to that thread saying that moss changed this   line in version two of the diff just now since I  made the requested changes I’m going to go ahead   and resolve the thread so I’ll select resolve  thread and now if I switch roles to the reviewer   I would just double check that the changes  that I requested were added so I would select   version two of the diff and I would review  again review line six to make sure uh those   changes were added and it looks like they have  been so I would go back to the overview page and I would select approve and then  I would merge the merge request   so I’m going to go ahead and select  merge and delete source branch   is checked so the readme hyphen introduction  branch should be deleted after we select merge   and then git lab gives us a confirmation  to say that the changes were merged   successfully and the source branch was deleted  but we do still have the option to cherry pick   our change uh into a new merge request or we if we  found like a regression for instance after merging   we can revert the change which means that it  will basically be undoing the merge into the main   branch okay so now that we’ve merged our first  merge request let’s navigate back to the home page   and we’re checked out to the main branch and if  i scroll down to review the readme file we can   see that now on the main branch the changes  that were previously on the readme hyphen   introduction branch are now included on the main  branch’s version of the of the file but remember   that since we’re using the environment branches  variation of the gitlab flow when we merge into   the main branch the main branch acts as kind of  like a pre-production branch or maybe a staging   environment so our final destination or the final  target branch is the production branch so we need   to make a second merge request to merge the  main branch now into the production branch   so to create that second merge request i’m  going to navigate to the merge requests   section and i’m going to select new merge  request and on this page i have to select   the source branch and then the target branch okay  our source branch our target branch is listed as   main right now but we know that’s not the case  our target branch should be the production branch   and our source branch should be the main branch  so here we’re saying we want to merge main   into the production branch okay so i’m going  to select compare branches and continue   and for the title i’ll provide something  similar to the original commit message i’ll just   say that we’re updating we updated  the readme file with an introduction i’ll leave the description blank  and then i will assign it to myself   and i will uh also assign myself as a reviewer  okay and then i will select create merge request and for this merge request i’m just going to  directly approve and merge it but it is important   to note that for every merge request that we  create between two branches that when a merge   request is opened it should trigger automated  testing and as changes are promoted up through   pre-production branches and they get uh closer to  being merged into the production branch the scope   of testing broadens at each level so when we have  a merge request open from the feature branch into   the main branch our scope of testing will likely  be smaller than when we’re merging the main branch   into the production branch so we’ll go ahead and  assume that automated testing was completed when   this merge request was opened and i’m going to  select approve and then i’m going to select merge and merging these changes into the production  branch essentially means that we are cutting   a release and to formalize that release  what we can do is create a git tag so   i’m going to navigate to the repository  section and then i’m going to go to tags and currently we don’t have any tags in this  repository and i’m going to select new tag to   create one and i’m going to use semantic  versioning and i’m just going to save   v1.0 for the tag name and then we are going to  create the tag not from the main branch but from   the production branch since it represents our  uh our production environment and the tag can   optionally have a message associated with it  i’m just going to say this is the first release and under the release notes i’ll  simply say updated the project   read me with uh introduction section  okay and then i will select create tag and now that we’ve created this  tag it should have also generated   a release in the deployment section so if  i navigate to deployments and then releases   we will see version 1.0 and it  gives us the ability to download   assets of the source code okay so now we’ve  completed the gitlab flow but there is one   last step that we need to do and that is to sync  our local repository with the remote repository   right now the remote repository has commits that  the local repository on my machine doesn’t have so   we need to do a get pull from the command line  to sync the remote repository with our local   repository so i’ll navigate to the terminal and  in my project i’m going to first do a git status   and when i do a git status you’ll notice that  i’m currently checked out to the readme hyphen   introduction branch and that branch no longer  exists in the remote repository it was deleted   after we merged the branch into the main branch so  what i want to do here is first do a git checkout   to the main branch and now that i’m checked out  to the main branch i’m going to do a git pull okay and so the get pole worked successfully  you’ll notice that it also uh recognized that   there was a new tag so it created  a new tag in my local repository   but if i were to execute  the get branch command here you’ll see that the main branch exists but also  the readme hyphen introduction branch still exists   locally so we need to delete the local  version of that branch and to do so we can   say git branch dash d readme hyphen  introduction and that deleted   the local version of the readme branch now that  command deleted the local version of the branch   but my local repository still thinks that  there is a remote branch called readme hyphen   introduction so if i do get branch dash dash  all it’ll show me not only the local branches   but also the remote branches and the  remote branches are listed in red and   you see here that the readme hyphen introduction  branch is still listed and to update this list   of remote branches we can pass in an option to  the get pull command called dash dash prune and   this will prune remote branches from this list  so i’m going to say i’m going to hit enter here and in the output it says that it deleted the  readme hyphen introduction branch and i’ll   run the get branch command again and we can  see it’s no longer listed in the local branches   or in the remote branches list anymore and there  is one last thing that we should do that i forgot   about before wrapping up the gitlab flow and that  is to close out the original issue that we created   in the gitlab project now that we’ve synced  the local repository with the remote repository   let’s go ahead and close out that issue so i’m  going to navigate back to gitlab and then i’ll   navigate to the issues section and then list  and then i’ll select the issue that i created and then i’m going to indicate in the check box  that we completed this subtask which updates the   count of tasks completed and once we’ve done  that we can go ahead and close this issue   so i’m going to select close issue in addition  to closing the issue i’m also going to mark it as   done and now that we’ve closed the issue that  we created for this change to the readme file   we’ve come full circle with the gitlab flow so  congratulations on completing your first round   of the gitlab flow and in the next video we are  going to explore the ci cd features of git lab hey what’s up everybody my name is moss and  welcome back to this tutorial series on gitlab   we have familiarized ourselves with the gitlab  interface and are now comfortable using the   gitlab flow but we’re still not using some of the  most important features the gitlab platform offers   in today’s world just about every code base  is supported by a continuous integration   and continuous delivery slash  deployment pipeline let’s take   a look at the features related to cicd  that gitlab offers for its projects in this video i’m going to show  you how to perform ci cd in gitlab let’s review our learning objectives for this  module after completing this module you should   be able to do the following demonstrate  an understanding of how gitlab pipelines   integrate with a gitlab project implement  gitlab pipelines in your own gitlab projects   write a gitlab pipeline that produces artifacts  write a gitlab pipeline that caches dependencies   write a gitlab pipeline that uses variables and  finally describe the anatomy of a gitlab pipeline let’s define some important gitlab cicd  terminology the first is a gitlab pipeline a   pipeline is a top level component used to define  a cicd process for a gitlab project and within   a pipeline we can define stages and jobs next we  have jobs jobs are associated with stages within   a pipeline and they define the actual steps to be  executed such as running commands to compile code then we have stages pipeline stages define the  chronological order of jobs and finally we have   get lab runners gitlab runner is an open source  application that executes the instructions defined   within jobs it’s a program that can be installed  on your local machine a cloud server or on-prem   shared runners are hosted by gitlab now that  we’ve defined these concepts let’s get started okay so the first thing that i want to do is  quickly walk through the code base that we’re   going to be using i’ve created this gitlab project  called sample maven project and it’s a very simple   maven code base and it’s actually based off of  a code base that you can automatically generate   from a tutorial by maven and if you simply  search maven in five minutes in your browser   the first link here maven in five minutes   has a tutorial where you can generate the same  project so under this section creating a project   i generated this code base using  this command so it creates a project   of maven archetype quickstart so let’s  take a look at that code base in gitlab   if i exit out of the tutorial and then in the  root directory of the gitlab project i’ll go into   source so we have a pom file and then we have the  source directory and in the source directory we   have it separated out by the test directory and  then the main directory which contains a single   a single class called app and  inside of the app class it simply   prints out hello world to the console and  then if i go back to the test directory we have a single test class called  app test and if i open that up   we have a junit test test class and then  a single test case within that test class   in this test case asserts true on a condition  that is always true so this test case will always   pass unless we were to change this condition  to false and that’s pretty much all there is   to this code base it’s very straightforward so  let’s navigate back to the project home page so to define a ci cd pipeline for a gitlab  project you need to create a yaml file at   the root directory of your project  and its name should be dot get lab   hyphen ci dot yaml and there’s two ways that you  can create that file you can either create it from   the drop down here so you could just create a new  file and call it dot get lab hyphen ci dot yaml   or you can create it from the ci cd section  and they have a dedicated section for   editing and creating a GitLab pipelines i think  that the best method for creating pipelines is   using the pipeline editor and I’ll show  you why so I’m going to select editor so this will create a pipeline on the  main branch and it says create a new   dot get lab hyphen ci dot yaml file at  the root of the repository to get started   and then i can create a new ci cd pipeline by  clicking this button so I’m going to select it and on the right hand side we have this help  section for getting started with GitLab CI cd   I’m going to close this out but before I do I’m  going to open up this link for viewing its syntax   reference document that GitLab provides I’m just  going to open that up in a new tab because we may   refer to it later on okay and after I’ve opened  that up I’m going to go ahead and collapse that   help section and when we open  the editor for the first time   GitLab automatically fills out this template  pipeline definition for a very basic uh pipeline   and in the um pipeline definition there’s  three stages defined so here’s a stages   statement and then under that statement we  have a build stage a test stage and then   a deploy stage and this isn’t the only pipeline  template that GitLab offers you can see up here   it says browse templates but if I were to  open the pipeline section up in a new tab if i scroll down you can see a list of ci  cd templates based on your technology stack   or the framework that you’re using and there is a  template for just about every technology that you   can think of you have go golang templates flutter  templates gradle there’s even a maven template for   maven projects but we aren’t going to use this  template and we also are not going to use the   template defined here as well but the pipeline  definition that we’ll write is going to be from   scratch and it will closely match this structure  where we have a build test and deploy stage   and under the stages definition they define the  jobs and the first job here is the build job   and you don’t necessarily have to follow this  naming convention you could just call this build   if you wanted to but it does make it clear  when you add the hyphen job to the statement   and then to associate a job with a particular  stage we would just use the stage keyword here   and then the value would be the  name of the stage that we want this   job associated with and after associating the job  with a particular stage we can then uh specify a   shell script that would be executed by the GitLab  runner so if I hover over any of these keywords it   gives me a definition of the keyword and you can  see here for the script it says um these would be   shell scripts executed by the GitLab runner  and it is the only required property of of jobs   so under the script statement they have  two echo statements where they’re kind of   you know pretending to compile a code base right  and then under the build job they’ve defined   a unit test job which is associated with the test  stage where they run unit tests and then a lint   test job that is also associated with the test  stage so there are two jobs associated with the   test stage and then the last job is the deploy  job which is associated with the deploy stage   now one thing I want you to notice about using  the pipeline editor is at the top it says this   GitLab CI configuration is valid so when we use  the editor one of the benefits of using the editor   is that GitLab while we’re editing the pipeline  GitLab is checking and validating the pipeline   syntax and the configuration to make sure that it  is actually going to run in addition we also get   these tabs here the visualize lint and view merged  yml tabs if we look at the visualize tab it gives   us a graphical version of our pipeline so now you  can see that the build job is associated with the   build stage the test jobs the unit tests and the  lin test jobs are associated with the test stage   and the deploy job is uh associated with the  deploy stage by default when multiple jobs are   associated with a single stage those jobs will be  executed in parallel and then on the lin tab it   gives us some information on the parameters  and properties of our pipeline definition   so here it also says that the syntax is correct  and the configuration is valid and then for each   of the parameters in the pipeline it gives us some  properties associated with that parameter so you   can see here all of the jobs are listed and then  in the value we have these properties also listed   under the value so for this first property we have  the only policy and its value is branches and tags   and this policy is referring to the only keyword  that you can use in a pipeline definition so   if we take a look at the keyword reference we  have only and accept keywords and you can use   only an accept with four other keywords references  like get references pipeline variables changes and   also kubernetes and these keywords control if  a job will run in a pipeline because if i use   references for instance i can specify specific  git references so only run this job when   the the get reference matches a particular regular  expression so for instance only run this job if   it’s a particular branch like the main branch  or a feature branch and that can be a regular   expression as well so it can be like any branch  that starts with a JIRA issue id for instance   so going back to that pipeline definition if we  take a look at the value here branches and tags   this job will run when the get reference  for the pipeline is a get branch or a git   tag and then below the only policy we have  the when keyword and its value is on success   and this specifies a conditional the one keyword  specifies a conditional so when should you run   this job only on success of previous stages so  this is only going to run if prior stages have   have passed successfully otherwise if a  earlier stage has failed this job will not   run and this is the default value for this  condition so we didn’t have to explicitly set   the only keyword or the when keyword in that  pipeline definition because this is the default   behavior jobs will only run when when prior jobs  have passed successfully unless you change that   you explicitly change that condition  okay and then on the last tab we can   uh view the merged yaml file okay  so this is just a view-only version   of the yaml file without the comments and then  I’m going to navigate back to the edit tab okay so let’s start editing this template so that   it works for our maven project so i’m  going to delete all of these comments here and like i said before our pipeline definition  is going to be similar to this one so i am   going to keep the stages definition and i  also will keep these jobs but i’m going to   clean it clean it up a little bit so i’m  going to delete the extra echo statement we’ll keep that lint test job and then  we’ll keep the unit test job as well so now we can start adding our own  stuff to this pipeline definition   and the first thing that i want to specify is the  docker image that the git lab runners should use   when they execute jobs in this pipeline so if your  project has dependencies that need to be installed   for it to be able to compile the code base  and run tests on the code base you can specify   a docker image that includes those dependencies  and the gitlab runner will use that image to   actually execute all of the steps defined  within your jobs and to specify the image   it’s very simple at the top here i’m going to use  the image keyword and then after uh specifying   the image keyword we would uh provide a value  and that value is going to be the name of the   docker image that we want the runner to use and in  this case we’re going to use the maven image which   includes all the dependencies that we’re going to  need in order to uh to compile and test and run   our maven project so after specifying uh  the maven image name i’m going to specify   the version and in this case i’m just going to say  latest so i’m going to use the latest docker image   for maven so now that we’ve defined  the docker image that should be used   when running these jobs the next thing that i  want to define are variables so we can define   pipeline variables inside  of our pipeline definition   using the variables keyword and what should  be our variables for this pipeline definition   well we’re going to have two variables the first  is going to be called maven cli options and the   only option that we’re going to pass to maven  is the dash dash batch mode and this will run   maven in a non interactive mode so that it won’t  prompt interactive mode so that and now that i’ve   defined this variable i can reference it in  any of the shell scripts that i define in any   job in the pipeline definition and i said that  there were two variables and the second variable   is going to be called maven options  okay and we’re only going to pass in   one option and that’s the location of the local  repo so i’m going to say dash d maven dot repo   dot local is equal to and then i’m actually  going to reference an environment variable   that is known as a predefined environment variable  and it’s called ci underscore project directory so   we don’t have to explicitly define the value of  this environment variable because it’s predefined   by gitlab okay so within the project directory we  will specify the dot m2 folder and then repository   and i think the git lab configuration validator  is complaining about a couple of things that   i’ve done here if i hover over the yellow squiggly  line it says cannot read an implicit mapping pair   i think the first thing is this extra quotation  mark but also i’ve used tabs here and i think   i should be using two spaces so i’m gonna do  one two and one two so now that we’ve defined   those variables uh the next thing i wanna do is  utilize gitlab’s built-in caching feature for   uh its pipelines we can actually cache artifacts  of a pipeline run to speed up future runs of   the pipeline and to do that we simply need to  specify the cache keyword and then after using   the cache keyword we would then specify the paths  within the project that we would like to cache   and in our case it’s really important to cache  the maven dependencies because otherwise um the   maven dependencies will be re-downloaded for  each job that runs so below the paths keyword   we can specify the path that we want to cache  which is going to be dot m2 and then repository   okay so now that we’re caching the maven  dependencies we can move on to the build job   and under the build job i’m going to leave this  echo statement but i’m going to add one more   shell script and here i’m going to  invoke maven with the cli options   so i’m going to reference the variable that  we defined so maven cli options and then   we will use the compile command and that’s  all we need for the build job so i’ll scroll   down to the unit test job and again i’m  going to add one more shell statement   and this is going to be maven and then  we will use the maven cli options again   and then we’ll invoke the test command now one  thing that is really cool is that gitlab can   actually render junit test reports and all we  have to do is generate those test reports as   artifacts so under the script statements  i’m going to specify the artifacts keyword when we use the artifacts keyword we can specify a  path that contains artifacts that we would like to   persist beyond uh the the length of the job so  after the pipeline has finished any paths that   were specified as containing artifacts those  items will be persisted after the the pipeline   finishes so we can access those artifacts and  download them from get lab and in this case   we’re storing junit reports so the first thing  that i want to specify is when these artifacts   should be generated and i’m going to say that  they should always be generated and then under the   when condition i’m going to specify the reports  keyword and under reports i’m going to specify junit okay and under the junit keyword we can specify  the path to our junit reports and that’s going   to be under the target directory surefire  reports test and then any file with test hyphen   dot xml okay i’ll also do this for  the reports so i’m going to do this okay so now that we’re generating those junit reports  as artifacts we should be able to download those   reports after the pipeline finishes and then also  we will be able to though those reports will be   rendered within the gitlab ui so you’ll  be able to see what that looks like   once we run this pipeline okay so after the unit  test job there is the lint test job and it’s   not doing anything but i am going to leave  this job there so that you can kind of see   that the job runs in parallel and then after  the lint test job we have the deploy job for   the deploy job we won’t actually deploy the  application to some remote server what we’ll   do is we’ll just use maven package and then  we’ll run the application locally so under the   echo statement what we’re going to do is invoke  maven and we will invoke it with our cli options and we’re going to invoke the package command  and finally after invoking package we will   run the program using maven and then we’ll  invoke we’ll reference the cli options   and then we’ll say exec java dash d exec dot  main class is equal to com dot my company dot app   and then the app class so when this command is  ran we should see hello world printed out to   the console of the job now the last thing  that i want to add to the deploy job   is the environment keyword so we’re going  to add an environment to the deploy job and it will be the staging environment so this  deploy job is going to you know quote unquote   deploy our maven application to the station  environment and what that is going to do is   it’s going to create a deployment under the  deployment section in the environments page   so we’ll take a look at that after the pipeline  has ran other than that i think that’s pretty much   everything that we need for this pipeline so all  we need to do is uh commit our changes to the file   and as soon as we make a new commit the pipeline  will run so i’m going to select commit changes and it says that it’s currently checking the  pipeline status and in a little bit it should   show up with a link to the running pipeline  there we have the link to the running pipeline   so i’m going to go ahead and select that and  open it up in a new tab so when we navigate   to the pipeline tab we can see the status  of each job in each stage and you can see   under the testing stage that both test jobs are  currently running in parallel and the build job   has already completed uh successfully so now  the deploy job has begun now that both of the   test jobs have completed successfully and this  pipeline run should take a little bit longer   because on the first run the cache is empty so  we haven’t cached any of the maven dependencies   so after this run the pipeline run should be a  lot quicker and now it looks like the deploy job   has completed successfully so the whole pipeline  has completed successfully let’s take a look at   each one of these jobs so i’m going to open up the  build job in a new link and when we open up a job   we get the console output of all of the commands  that we defined uh in the uh in the job definition   so up at the top we can see that the job begins  it’s running with get lab runner and then after   that you can see that the gitlab runner is  pulling the maven the latest maven docker image   so that it can run the the job within that  docker image and it’s really convenient next to   each of these statements you get the time  duration for how long that that particular   command took and in the top right you can also see  the total duration of the job which was 44 seconds   the timeout period is set to one hour and  that simply means that if at one hour the   job is still running uh that the job will  automatically be cancelled because maybe it’s   you know the job is hanging for some unknown  reason and you don’t want to utilize all of your   runner you know resources on a job that’s hanging  so if we scroll down further in the console   we can see that the runner clones down the code  base and then on line 30 it checks the cache   for default and it says fatal file does not  exist so there is no cache because this is   the first run of the pipeline and then on line  36 we can see the first shell statement of our   build job where we say we’re compiling the code  we invoke maven compile with the cli options and   then starting at line 44 you can see where maven  begins downloading all of the maven dependencies   so what i’m going to do is  i’m going to scroll down below   where it’s downloading those dependencies and  after it downloads the dependencies it uh compiles   the module and we can see that it was a successful  build and it took a total of eight seconds   and since the job was successful you can  see it line 393 it’s saving a new cache   and on uh 395 we can see that it caches the dot  m2 repository directory and then it uploads that   zip file to essentially back to gitlab so now  that we’ve seen the build job let’s take a look   at the test job not the lint test job but the  unit test job so i’ll open that in a new tab   and here if i scroll up to the top i’m going to  use this button to scroll to the top we can see   roughly the same output as we did in the build  job where it’s um you know preparing the maven   docker image to execute our maven commands  on so starting on line 36 we can see   where our unit test job begins and then we  invoke uh maven with our cli options and then   the test command okay and then it downloads  the necessary uh dependencies and if i scroll   down below that we can see where the tests  actually get executed and one test ran and there   were zero failures so we get a successful build  and then below that you can see here it saves the   cache for the successful job and we can see that  it’s caching the m2 repository directory now   below the cache creation starting at line 211 you  can see where it’s uploading the artifacts that   we created and the artifacts that we generated and  remember in the pipeline definition were theJUnit   test reports and it identifies the surefire  reports directory on line 211 there were no   fail-safe reports so it says that there were  no matching files there but it did find uh one   matching file for the surefire test reports and  it uploaded those artifacts as a JUnit test report   so we’ll take a look at those test reports in  a little bit but first I’m going to go back to   the pipeline and let’s open up the deploy job and  let’s quickly walk through the deploy job as well   so I’m going to scroll up using the scroll to  top button and then again we have a very similar   you know output as we did in the previous jobs  it clones down the code base uh it recognizes   that there is a cache and it downloads that  cache and it extracts it and then the uh maven   package command is invoked so it then downloads  the necessary dependencies and if I scroll down   you can see it’s running running the  tests again and then if I scroll further it packages the program as a jar file and then it  runs the exec command on the main class okay and   then it downloads uh more dependencies and then  if I scroll down to the bottom you can see where   on line 250 it actually runs uh the app class  and it prints to the console hello world   and then finally on line 258 you can see that  it creates a new cache okay and then the job   finishes so now that we’ve looked at the job  output let’s navigate back to the pipeline tab   and on the pipeline tab we can see several tabs  here the pipeline the overall graphical view of   the pipeline but then we also have this test tab  and we can see that there is one test so if I open   this test tab we can get a summary of the tests  that pass and this is generated from the JUunit   reports and it shows us which jobs are associated  with those tests and if I wanted to download   these test reports I could simply go back to the  pipelines page which will show me a list of all   the pipelines that have ran and you can see the  pipeline that we just ran over here on the right   it shows me uh an artifacts drop down and I can  actually download artifacts that were generated by   the pipeline and in this case there was only one  set of artifacts which uh which was the JUnit test   reports and in addition to the artifacts I also  specified an environment in the deploy job and   that should have showed up under the deployment  so if I go to deployments and then environments we can see that there is one environment the  staging environment and there is one deployment   to the staging environment and it shows the job  associated with that deployment and the commit as   well if I wanted to see a list of all of the jobs  that have ran I can go back to the CI/CD section   and select jobs and this will show me  a list of all of the jobs that have ran   in the past you’ll also notice  that under the jobs section   we can create schedules for our pipeline so if I  select new schedule I can specify an interval uh   pattern or a cron pattern to run our pipeline  uh maybe like every uh every day or every week   so that’s also a useful feature that we can  use for our GitLab pipelines now a few more   things that I’d like to show you are in the  settings so if I go to settings and then CI/CD we can update various settings related to our  pipeline so if I expand the general pipeline   configuration I can actually specify a custom path  for the pipeline definition within the project   I can also change the timeout period for jobs that  fail if they run longer than the timeout period   and then below the general settings if I collapse  this you have auto DevOps and if you turn this on   GitLab will attempt to like automatically  set up a pipeline based off of your project’s   technology like whether it’s a maven project or  you know a going project or something like that   under auto DevOps we can configure GitLab runners   and right now I’ve been using shared runners  which are hosted by GitLab and under shared   runners I can see all of the runners  that are available to me that I can use however if I didn’t want to use shared runners  and instead I wanted to host the GitLab runner   program on my own infrastructure I could register  my own runners with this GitLab project so that   in the pipeline definition I can assign jobs to  those runners that are hosted on my infrastructure   and then under the runners configuration  we can also define pipeline variables   at the project level uh here as well so  if I expand uh the variables section now   i can create new variables and these variables  that i uh create can be protected and masked   so protected variables can only be exposed  to protected branches or tags and then masked   variables are hidden in job logs and this is  useful in the event that you have um environment   variables that would be passwords so for instance  if you’re trying to upload um an artifact to   artifactory and you need to authenticate with your  artifactory instance you would need the username   and password for the artifactory user in that case  you can use a masked variable for the artifactory   password so if i were to select add variable i can  specify the key of the variable like r to factory   password and then the value of the  password and i can specify the type   and the environment scope and i can protect it  and then i can also mask the variable as well if i   added that variable you can see that the value  here is um is not visible but if i need to i can   still reveal the value using this button and the  last thing that i’d like to mention are pipeline   triggers so you can trigger a pipeline for a  branch or a tag by using a trigger token so   a use case a sample use case for this might  be if you wanted to trigger a pipeline to run   via a slack command so if you you know had a slack  bot you can provide the token to the slackbot so   that the slackbot can communicate with the gitlab  api and trigger this pipeline to run so i’m going   to navigate back to the cicd pipeline section and  i think that wraps up everything that i wanted to   cover in this particular module so i hope you  enjoyed this video and i will see you in the next hey what’s up everybody my name is moss and  welcome back to this tutorial series on gitlab   we’ve introduced you to gitlab pipelines but you  may be in a situation where your team is already   using jenkins pipelines to facilitate ci cd this  means that you already have pipelines defined   and you need to convert those jenkins  pipelines into their gitlab pipeline equivalent   while taking advantage of gitlab’s most useful  ci cd features before migrating any of your   pipelines you’ll need to understand some key  differences in how these tools facilitate ci cd   in this video i’ll show you how to migrate  to gitlab ci cd from jenkins pipelines   let’s quickly review our learning objectives  after completing this video you should be able   to do the following explain the differences  between jenkins pipelines and gitlab cicd   migrate your own jenkins  pipelines to gitlab pipelines   and use gitlab pipelines to run tests on  the lambda test selenium automation grid there are a couple of prerequisites that you will  need before starting the tutorial the first is   familiarity with jenkins pipelines and terminology  you will also need a lambdatest account let’s begin the tutorial by performing  a comparison of terminology and concepts   between the two tools we will define a mapping  of terms between declarative jenkins pipelines   and gitlab cicd we will refer to jenkins  terms and draw a mapping from that term   to its equivalent in gitlab the first is  the agent section of a jenkins pipeline   this section of the pipeline specifies which  jenkins agents should execute the pipeline in git   lab we use what are known as git lab runners which  execute jobs in a gitlab pipeline jenkins agents   and get lab runners do have differences but they  serve very similar roles in their respective tools   both are software applications that  execute tasks defined in a pipeline next is the jenkins stages section jenkins and  gitlab share the concept of stages in their   pipelines in both tools stages define the  chronological order of a pipeline execution   however in gitlab stages are enumerated in  a list at the top of the pipeline definition   we then have the steps section of a jenkins  pipeline the steps section of a jenkins pipeline   allows you to define commands to  be executed by the jenkins agent   in gitlab we can use the equivalent  script section in a gitlab pipeline there are two important jenkins directives  which you have likely used in the past   the first is the environment directive this  jenkins directive will allow you to define   environment variables that will be available  during pipeline runtime the variables keyword   in gitlab provides equivalent functionality  as the jenkins environment directive   the last one is the jenkins tools directive this  jenkins directive allows you to install tools   that are necessary to execute the pipeline steps  however there is no equivalent in gitlab for the   tools directive and instead git lab recommends  using pre-built docker container images now that   we’ve defined this mapping between the tools  let’s move on to the next part of the tutorial okay so the first thing that I want to do is walk  through the code base that we’re going to be using   and once we’ve reviewed the code base then we’ll  walk through the Jenkins pipeline that tests this   code base and after walking through the Jenkins  pipeline code we’ll then write an equivalent   GitLab pipeline together this will demonstrate  a simple migration from a Jenkins pipeline   to a GitLab pipeline but hopefully it will  highlight some of the key differences that i   mentioned during the presentation in the pipeline  that we write we’ll utilize the lambda test   selenium automation grid in order to execute  the tests that are defined in this codebase   so let’s start walking through the code

base I’m  in git lab and I’m currently inside of the project   which is called automation demo automation  demo is a maven project that utilizes   test ng as its testing framework and what  you’ll notice under the source directory   is that there is only a test directory there is  no main directory and that’s because there’s no   application for this code base this is just a  test class this code base contains only a single   java test class and it’s testing a website  a public website out on the internet   so let’s navigate into the test directory  and take a look at the test class   so we have a single test class called automation  demo test dot java so I’ll open up that file and   in this test class we have three methods the first  is the test setup method and then we have a single   test method called test element addition and then  we have a teardown method so the test setup method   is parameterized and it runs before our single  test method the first thing that the test setup   method does is set the desired capabilities  and the capabilities are parameterized   so the we get these uh parameters from the  testing configuration xml configuration and   after setting the desired capabilities it then  generates a new remote web driver and it uses   the lambda test hub URL now these capabilities  are parameterized but if you wanted to you could   actually use the capabilities generator that is  provided by LambdaTest to automatically generate   this code that sets the desired capabilities I  have the capabilities generator already pulled up   in a tab but you can google search lambda test  capabilities generator and it should pull up as   the first result you can see here the capabilities  generator right here so I’ll navigate to this page   and from here I can select which language I want  the capabilities to be generated in in our case   it would be java and then I can select selenium or  selenium and then I could just copy this code into   my test class so I’ll navigate back to the test  class and under where the capabilities are defined   you can see that it creates a new remote  web driver and here it lists the hub URL   and it concatenates it using the username and  access key variables which are defined up here   so my username for my lambda test account is tech  with moss and then I have my account access key   defined as an environment variable which is called  uh lt underscore access under underscore token   now you might be wondering where does this hub  URL come from and we can actually retrieve the   full URL which includes the username and access  key from the capabilities generator so if I   navigate back to the generator you can see in the  right hand side here access key if I click that   we have the username the access key and then we  have the full hub URL which includes username and   access key and i could copy that to my clipboard  and I could also use that here with everything   hard coded and once the test setup method  completes we then run this single test method   called test element edition which connects to  using the driver connects to this test URL and   the test URL is just to do mvc.com so if I were to  navigate to this URL let’s open it up in a new tab it’s a very simple to do uh to-do list  application so if I just say to do one   and hit enter it adds this  as an item in a to-do list   and then i can check each item and mark it  as completed and i can clear those items okay so if i scroll back to our test method  after connecting to the test url   the test method then adds  five items to the to-do list   so you can see here in the in the for loop it adds  uh five items and then after it adds those items   it iterates over that list and for each item it  marks it as complete and then deletes that item   from the list and once our test method completes  the teardown method is called and it quits the   driver okay so now that we’ve walked through the  test class let’s navigate back to the repository and real quickly i want to show the test ng  xml file so that we can see how our tests are   configured and inside of our xml file you can  see that there are three test scenarios defined   in the first test scenario we’re using chrome on  windows and in the second scenario we’re using   firefox on windows and then in the last  one we’re using microsoft edge on mac os   so now let’s navigate back to the repository and you can see in the repository I have  a Jenkins file defined a Jenkins pipeline   so let’s take a look at this Jenkins pipeline so  this is a pretty simple pipeline it has a single   stage called the test stage and it  begins by specifying that it can run   on any available Jenkins agent and then  after the agent section it then defines   an environment section and in the environment  section we define two environment variables   lambda test underscore username which is  my my lambda test account username and then   maven cli options okay and we run it in batch  mode and then we specify the testing configuration   xml file and inside of the test stage  we have the steps section and inside of   steps we invoke the pipeline maven integration  plugin using the with maven statement   and with that invocation we specify the maven  installation and we also specify some additional   options in this case we specify the JUnit  publisher so this is also using the JUnit   Jenkins plugin in order to publish JUnit reports  visually in the Jenkins UI and inside of the with   maven statement we invoke with credentials  and specify some Jenkins credentials called   lambda tests access token so I created a Jenkins  credential to store my lambda test account access   token and we’re making that access token value  available as an environment variable called lt   underscore access underscore token so now  in the innermost statement we invoke shell   and call maven with our maven cli options and  then the test command and if i navigate to jenkins   i actually ran this pipeline already if i take  a look at the console output you can see where   it invokes the pipeline maven integration plugin  it masks the environment variable lt access token   and then it calls maven with those  cli options and the test command   and if i scroll down we can see where the tests  begin and you can see it makes a connection to   the remote web driver and it runs those tests  on the lambda test selenium automation grid   and finishes successfully after the build  finishes you can see where the pipeline   maven integration plugin then publishes the junit  reports and if we navigate back to the build page you can see here that we can review  the test results of the pipeline   so if i navigate into the test class  we have the same test method but it was   executed three times for each of our test  scenarios and if i navigate to the pipeline page   we also get the test result trend graph here as  well in this case we only have one one result   okay so now let’s navigate back to git lab and  we’ve walked through the jenkins pipeline so now   let’s write an equivalent gitlab pipeline so from  here i’m going to navigate to the ci cd section   of the repository and we’ll open up the pipeline  editor so i’m going to open this up in a new tab   then i’ll select create new ci cd pipeline and  we’ll start with this basic template but we are   going to delete the majority of it so we’ll only  have one stage so i’m going to go ahead and delete   these comments and i’ll leave only the test stage  so i’ll delete the build stage the deploy stage okay and we’ll leave one uh test job okay now when the gitlab runner executes this test job   it’s going to invoke maven commands so maven needs  to be available somehow to the get lab runner   and in the case of jenkins i installed maven on  the jenkins controller node so when we invoked   the pipeline maven integration plugin we were  able to reference a specific maven installation   that the plug-in could use to execute maven  commands but as i mentioned in the presentation   gitlab recommends using pre-built docker container  images that have all of your dependencies already   installed on the image and we can specify a  docker image in a pipeline that a gitlab runner   should use to execute the script section of a  particular job and not only that we can specify   default images at the top level of the pipeline  but we can also specify docker images per job   in the pipeline so if a particular job needs  to utilize a specific docker image we can also   specify those images under a job definition within  the pipeline and that will override any of the   images that are defined as the default  images in the top level of the pipeline   in our case we’re going to use the default  image throughout the whole pipeline   and to define an image we use the image keyword  and then we specify the name of the image   as well as the tag in this case we’re going to use  the maven image and we’ll use the latest version   of the maven image now after specifying the  docker image we need to replicate the environment   directive in our jenkins pipeline so if we go back  to the jenkins pipeline we have this environment   directive where we define two variables  the username and then the maven cli options   so we need to replicate that in our pipeline  and to do that we can use the variables keyword   so following the image definition i  will use the variables keyword and   under variables we’ll first define  the username environment variable and after the username variable  we have maven cli options   and here we’re just going to specify batch  mode so it will run maven in a non-interactive   mode so that it doesn’t prompt the user for input  and then we will specify the testng xml file and finally we’ll specify a maven options variable and here we’re going to specify the local repo is equal to and then i’m going to use  a predefined environment variable ci   underscore project directory dot m2 and then repository and similar to the  last video we need to cache the dependencies   that maven downloads when running maven  commands so that when the pipeline runs   it’s running in a fresh environment we don’t want  it to re-download all of the maven dependencies   so we want to make sure that we cache  that and that is a difference between   the gitlab pipeline in the jenkins pipeline  the jenkins pipeline is a shared workspace   that’s going to exist between pipeline runs unless  we explicitly tell it to utilize a fresh a fresh   workspace so below the variables section i’m going  to use the cache keyword and below cache i’ll   specify the file paths that i want to cache so  i’m going to use the paths keyword and below paths   i will specify dot m2 and then repository okay  so now that we’re caching the maven dependencies   let’s move to the test job and i’m going to remove  these scripts i’ll also remove these comments and under the script section we’re going to invoke  maven so here i’ll say maven and then dollar sign   and we’ll reference our environment variable maven  cli options and then the test command so that’s   everything that we need for the script section but  we do also want to produce junit reports as well   and we can generate those reports using the  artifacts keyword so below the script section i’m   going to use the artifacts keyword and then under  artifacts we’ll first specify the when condition   when these artifacts should be produced and we’re  going to say always and under the when condition   we’ll specify what kind of artifact and this will  be reports and under reports we’ll specify junit   as the type of report and finally under the  junit keyword we would specify the path to   our surefire reports so i’m going to say target  and then surefire reports and then test hyphen   then asterisk and then dot xml and that’s pretty  much all we need inside of the pipeline definition   but we are missing one environment variable  and that is the lambda test access token   environment variable so in jenkins we save  that value as a jenkins credential and then   in the jenkins pipeline we invoked the with  credentials function to use the access token   as an environment variable in the case  of git lab we can define those kinds of   environment variables that shouldn’t be you know  checked into version control in the settings   of the repository and then under the ci cd  section so let’s go ahead and open that up and from here let’s expand the variables section and i’ll select add variable and we’ll call it uh lt underscore access token and to retrieve the value i’ll navigate back  to the lambda test capabilities generator   and i’ll select access key and then i’m going  to copy the access key value to my clipboard   okay and i’ll navigate back to  gitlab and we’ll paste that value in and this is of type variable and we’ll keep the  environment scope the same it’s protected but   we also want this variable masked as well and  masking this variable means that it will be   it won’t its value won’t be revealed in the  pipeline job logs so i’ll go ahead and select   add variable and you can see in the ui that the  value of the variable isn’t revealed okay so now   let’s navigate back to the pipeline editor and  there’s one thing that i’d like to point out   that is a really important difference between  gitlab pipelines and jenkins pipelines so in   gitlab if we were to have multiple stages for  instance before the test stage let’s say we had a build stage where we compiled code the the  compiled program would be an artifact that   would be used during the test stage however each  of the jobs that are ran in uh their respective   stages are being ran in a fresh environment it’s  not a shared workspace so the uh the compiled   program that was generated during the build stage  would not be available to jobs in the test stage   so if artifacts are produced in a particular  stage that a downstream stage are dependent on   then what we need to do is use the artifacts  keyword to specify those artifacts that were   produced in the upstream stage what happens when  we use the artifacts keyword is the artifacts   that we specify are uploaded to gitlab by the  gitlab runner and by default those artifacts are   downloaded by downstream jobs so this default  behavior is different than in jenkins pipelines   where in a jenkins pipeline you have a jenkins  agent running all stages of the pipeline in a   shared workspace unless we explicitly state in  the pipeline to use different jenkins agents for   each of the pipeline stages and there is a nice  example of the artifacts keyword usage in the   gitlab documentation that i’d like to quickly show  so if we google search artifacts gitlab keyword and i’ll select the artifacts keyword if  i scroll down to this code snippet you can   see part of a pipeline definition here and  we have four pipeline jobs defined we have   two build jobs for two different platforms and  two test jobs for each of those platforms so for   the osx build it produces a set of binaries and  you can see here how the artifacts keyword is used   under artifacts they specify paths to produces  artifacts and then the binaries directory   and we have the same definition for the linux  platform build as well and then if we take a   look at the test jobs what you’ll notice is this  dependencies keyword so the default behavior is   all artifacts that were produced in previous  upstream stages will automatically be downloaded   by a job so for instance in the deploy stage here  this is going to download all of the artifacts   that were previously produced however if a  job only needs a subset of artifacts that   were produced in prior stages then what you  can do is specify the dependencies keyword   and so in the case of testing the osx platform all  we need are the binaries from the osx build job so   under the dependencies keyword we specify the uh  the job name that produced those artifacts and   you can see that the same thing happens for the  test job for the linux platform the dependencies   uh that are specified here are the artifacts from  the build job for the linux platform so i did   want to quickly detour because i do think this  is a very important difference between jenkins   pipelines and gitlab pipelines and it’s a use case  that you’ll likely run into if you’re if you need   to you know compile your application and even if  you didn’t have to compile your application you’re   likely producing artifacts in an upstream stage  that need to be shared with downstream uh stages   so let’s navigate back to our gitlab  pipeline and i’ll remove this build sage   since we won’t be using that and let’s  quickly do a side-by-side comparison   of our gitlab pipeline in our jenkins pipeline  just to make sure that we’ve covered everything   that was defined in the jenkins pipeline so i’ll  pull this jenkins pipeline out into a new window okay so starting from the top we have the top level  pipeline definition then we have uh agent any   so this can run on any jenkins agent uh here we  don’t have an agent section we’re just specifying   the image that should be used by  the gitlab runner when executing   the commands defined in our script  section and then for the environment   directive in our jenkins pipeline we have the  equivalent of variables keyword to define our   environment variables in the pipeline in the  jenkins pipeline we don’t need to specify   the maven options variable we’re using the  pipeline maven integration plugin here and then   we also have the cache statement in our  gitlab pipeline which we don’t have to specify   in the jenkins pipeline because it’s using you  know a shared workspace across the whole pipeline   in between pipeline runs so unless we clear that  workspace we won’t have to re-download the maven   dependencies every time we run the jenkins  pipeline so in gitlab we do need to specify   the cache keyword so that we’re not re-downloading  those maven dependencies on each run then we have   the stages definition in our jenkins pipeline  with just the single test stage here we have   the stages definition and then a single test  job that is associated with the test stage   and then in the step section we  invoke with maven and we specify the   maven installation that we want to use and we say  that we want to also utilize the junit publisher   and then we invoke the with credentials  function to specify the access token credentials   as an environment variable and  here in the gitlab pipeline   since we’re using the docker image the maven  docker image we don’t have to specify um you   know with maven or anything like that or a maven  installation this is going to be ran inside of the   maven uh docker container so here we invoke  uh the maven test command with our cli options   and finally we produce the artifacts from the  test job which in this case are junit test reports   here we’re specifying the junit publisher  using the pipeline maven integration plugin   now i do want to mention that  i wrote this jenkins pipeline   this way because we are using a maven project and  since we’re using a maven project it’s best to use   the pipeline maven integration plug-in but even  without the plug-in we could still do the same   thing that we’re doing here for our maven project  and i have an alternate version of the pipeline   in this repository as well so it’s called  jenkinsfile old and if we open this up   the first difference that you’ll see between the  two Jenkins pipelines is that here I’m using the   tools directive to specify a maven insulation  and a jdk and I’m also specifying the maven   options environment variable as well so I guess  you could say this is a more generic version   of the pipeline because maybe your your tool  dependency isn’t maven or the JDK maybe your   tool dependency is that you know Python 2.7  or Python 3 is installed for you to be able to   run the steps in the Jenkins pipeline and if you  recall from the presentation GitLab does not have   an equivalent for this tools directive where we  can specify tools that should be installed or   present on the Jenkins agent that is executing  the steps defined in the pipeline instead in   GitLab we’re using docker images to to perform the  same role as the tools directive and that gives   us somewhat similar functionality to the image  keyword in our GitLab pipeline and to show an   example if I search for docker uh pipeline plugin  and then cloud ps they actually have an article that specifies how you can run a docker image kind  of the same way you run it here you can see we’re   invoking docker.image we’re specifying the image  name in a version and then inside of this block   we download the source code and then we execute  maven so this is happening within the docker   container similar to how this script is being  executed inside of a docker container so this is   another alternative method to writing our Jenkins  pipeline but it does require the the docker   pipeline plugin to be present on the Jenkins  instance and I think that’s what I like about   GitLab in this case even though it’s it’s great  that Jenkins is an extensible tool in the case of   GitLab none of this functionality is provided  through plugins it’s just there by default   okay so let’s go ahead and commit our GitLab  pipeline I’m going to exit out of these windows and we will commit these changes which should  trigger a pipeline to automatically run so we should see it pop up here in a second and you can see that a pipeline is now  running so I can select view pipeline and we have the test job running so  I’ll go ahead and open up the test job   and let’s see where where it’s at okay so it looks  like the job has downloaded the maven dependencies   and then it started the tests and you can see down  here that it began a session with the remote web   driver to execute the tests and three tests  ran and there were zero failures so there was   a successful build and then it creates the cache  and then it also uploads artifacts which in this   case are the surefire the JUnit test reports and  in the first run of the pipeline we would expect   to see the download of maven dependencies but in  future runs of the pipeline those dependencies   should be cached so they won’t be redownloaded  so I’ll navigate to the pipelines section and the   first thing that I’d like to point out from the  pipeline page is next to our our pipeline we have   this artifacts drop down here where we can  download the artifacts that were generated   from the pipeline in this case we just have the  JUnit test reports if I navigate into the pipeline   we have the visual graphical view of the pipeline  execution but under the tests section we can also   uh see the results of the test execution in  the pipeline so we have a 100 success rate we   can see which jobs uh executed tests if I go  into the test job it tells us the test class   name as well as the name of the test and then  the status of that test and how long that test   or the duration of that particular test now this  test uses the lambda test selenium automation grid   as the remote web driver so if we  navigate to our lambda test account   we should be able to see the results of the tests  and the test scenarios in our lambda test account   and the results of those tests are recorded  and we can access those recordings from the   left-hand menu here if i select automation it’ll  take us to the automation page where we can view   a timeline of test results so  I’ll click on the most recent here   and from the automation logs tab we can view  the results of each of our test scenarios we had   three test scenarios defined one  for windows 10 on Firefox version 93   one for windows 10 on chrome version 94 and  then the final one is Mac OS and then that’s on   running on Microsoft edge version 94. so for each  of these test scenarios we can view the recording   of that scenario so if I select  play we can see the website that   we’re connecting to in our tests and  then it adds five items to the to-do list and once those five items are added it begins   checking them off and marking them as  completed which clears the item from the list okay and then that concludes the test scenario   and i won’t go through each one but you  can see in each of the test scenarios   we have the test scenario successfully  completing the the test defined in our test class and for each of these scenarios we can use the  tabs up here to dive deeper into the details of   the test scenario execution in the event that  maybe the scenario failed and we had to perform   uh debugging then we can explore all the details  of the scenarios of the scenario from these tabs so I’m going to navigate  back to our GitLab project and I think that wraps up everything  that I wanted to cover so I hope   you enjoyed this video and I  will see you in the next one hey what’s up everybody my name is moss and  welcome back to this tutorial series on git lab   in the last video we discussed  the differences between Jenkins   and GitLab CI and I walked you through a sample  migration from a Jenkins pipeline to a GitLab   pipeline in this video I’m going to introduce you  to some additional features of GitLab pipelines   we are going to cover the packaging  and releasing features of git lab let’s review our learning objectives for this  module after completing this module you should   be able to do the following deploy artifacts from  a GitLab pipeline to the GitLab package registry   describe git lab releases describe the GitLab  package container and infrastructure registries a software release in a GitLab project may include  the following generic software packages generated   from GitLab pipeline job artifacts such as  platform specific binaries release notes   release evidence that includes everything  associated with the release such as issues   milestones or test reports and by default a  snapshot of the gitlab project’s source code now let’s talk about the registries available  in gitlab starting with the package registry the   gitlab package registry allows you to use gitlab  as a public or private software package registry   and the registry supports a number of package  managers you can publish and share software   packages to the registry and these packages  can be published from within a cicd pipeline   packages are associated to a gitlab  project and groups that project is added to the gitlab container registry is a private  container registry for publishing and consuming   container images and every gitlab project  has its own container registry the container   images in the registry are associated with a  gitlab project and any groups that project has   been added to you can utilize container images  stored in the registry from a gitlab pipeline   you can also build and publish container  images to the registry from a gitlab pipeline lastly we have the infrastructure  registry which supports publishing   and sharing of terraform modules each gitlab  project has an infrastructure registry   and you can build and publish a  terraform module from a gitlab pipeline   now that we’ve defined releases and the  available registries in Gitlab let’s get started okay so the first thing that i’d like to do  is quickly walk through the code base that   we’re going to be using today and once we’ve  done that we’ll then write a gitlab pipeline   for our code base i’m currently logged into git  lab and i’m inside of the test pipeline project   the test pipeline code base should be  pretty familiar to you if you’ve been   following this series it’s a maven project  that was generated using the quick start   maven archetype if we take a look at the source  directory it has a single app.java class and it   simply prints out hello world to the console okay  and then it has one matching test class as well but what’s more relevant to review in this  video is the ci underscore settings.xml file   and the palm.xml file because inside  of these files we have configurations   that are going to be used by the Gitlab pipeline  that we write the ci underscore settings.xml file   is used as our maven settings.xml file so  let’s quickly take a look at the settings and inside of our settings we define a server  configuration with an id of gitlab hyphen maven   and then we also define a property with the name  job hyphen token and its value actually references   a predefined gitlab environment variable so this  is how we would reference a gitlab environment   variable from within a file and this variable  is called ci underscore job underscore token   this predefined environment variable is one of  several ways that we can authenticate with the get   lab package registry if we want to authenticate  with the gitlab package registry from within a   gitlab pipeline then we would want to use the  CI job token to do that however if we want to   authenticate uh with the package registry outside  of a Gitlab pipeline so we’re authenticating from   a Jenkins pipeline or even from our local machine  what we would want to use is either a personal   access token a gitlab personal access token that  we generated for our account and that has to have   the scope of api access or we need a deploy  token that’s generated from our GitLab project   and the value of either the deploy token or the  personal access token has to be used in place of   the CI job token since we’re authenticating from  outside of a GitLab pipeline but in our case we   are going to write a GitLab pipeline so I’m going  to use the ci underscore job underscore token   environment variable to authenticate with the  package registry so that we can deploy a maven   package to the projects registry and one thing  that I’d like to point out before we move on is   that this code base will be made available to you  okay so now let’s take a look at the pom.xml file inside of the palm.xml file I modified the  version tag and again I’m referencing a predefined   GitLab environment variable called ci underscore  commit underscore tag so when we write the   GitLab pipeline we’re going to configure the  pipeline to run anytime a Git tag is pushed or   created in our GitLab project so the pipeline  is going to reference the environment variable   and so will the palm.xml file when it generates a  snapshot the other thing that was modified in this   pom.xml file is the repositories tag so we added a  repositories tag and it specifies the GitLab maven   package registry url and to form the package  registry url we use GitLab predefined environment   variables again and in this case you can see  the first environment variable that’s reference   is ci underscore api underscore v4  underscore url so this is going to be the   api url for git lab followed by projects followed  by the next predefined environment variable   which is our GitLab project’s id ci underscore  project underscore id and then we specify   packages and then maven okay so now  that we’ve reviewed the palm.xml file   and the ci underscore settings.xml file we can  start writing a GitLab pipeline that deploys this   this maven codebase as a maven package  to this GitLab project’s package registry   so what I’m going to do now is navigate to the  pipeline editor so under CI/CD I’ll select editor and then I’m going to select  create new ci cd pipeline   okay and the first thing that I want to do  is delete all of the stuff that we don’t need   in this pipeline template  so I’ll delete the comments   and then I’m going to delete the build and  test stage and just leave the deploy stage so I’ll remove all of the jobs  associated with the test and build stage   so we only have the deploy stage and the single  deploy job now in this case since we’re just   demonstrating the uh the package registry feature  in GitLlab I’m removing the build and test stage   but of course in a production and pipeline  you’d want to keep the build and test stage   in addition to the deploy stage and after removing  those stages I’m going to define the docker image   that the deploy job should use when executing  these steps inside of the deploy job so at   the top of the pipeline definition I’m going to  specify the image keyword and then I’m going to   specify the maven image and the latest version of  the maven image the next thing that I want to do   is define the relevant pipeline variables so under  stages I’m going to define the variables keyword   and under variables we are going to have a  single variable called maven underscore options   and this is going to specify our local repo  so d maven repo local and then dollar sign CI   underscore project underscore directory so this is  a predefined environment variable that we can use   and then the dot m2 repository and after defining  the variables I’m going to use a keyword that we   haven’t used in previous videos and that is the  workflow keyword the workflow keyword is used to   control the behavior of the pipeline and under the  workflow keyword we can specify the rules keyword   um and rules essentially uh create conditions  on which the pipeline will either be ran   or not ran and in our case we’re going to define  a single rule so under the rules keyword I’m going   to put hyphen and then I’ll put the conditional  if statement and then I’m going to put dollar sign   ci underscore commit underscore tag so what this  rule is saying is that this pipeline will run   if it was triggered by the creation of  a Git tag either a Git tag was pushed   to the project or we created a Git tag manually  from the repository section and then the tags page   now after specifying the workflow rules  we will create a cache using the cache   keyword so under workflow i’m going to use  the cache keyword and we’ll specify paths and we’ll specify one path which will be dot  m2 repository and then the final thing that   we need to do is actually invoke maven in the  deploy job so in the deploy job i’m going to   remove this first statement here and we are going  to invoke maven and then we’ll say maven deploy   and then specify the settings file  using s ci underscore settings dot xml   and then I’ll also remove these comments here so if I wrote this pipeline correctly it should  publish the maven package to this gitlab project’s   package registry and it says that this is a  valid gitlab ci configuration so let’s go ahead   and commit this pipeline and then see if it runs  successfully so i’m going to navigate down here   and i’ll select commit changes  and based on the workflow   keyword this shouldn’t run automatically until  we’ve created a new tag in the repository   so let’s navigate to the pipelines page and  you can see that no pipeline has started yet   so i’m going to navigate to the repository  section and then to the tags page   and from here i’m going to select new tag  and we’ll give the tag name version 1.0.0   and we’ll create it from the main  branch i’ll leave the message   blank and release notes blank for  now and then i’ll select create tag   okay so that created a new git tag and if  i navigate back to ci cd and then pipelines   that triggered a new pipeline job so  i’m going to open up that pipeline job and we have the single deploy job so  i’m going to open up the deploy job   and let’s take a look at the output okay so it  looks like the pipeline completed successfully   and if we take a look at the output i  won’t go through all of the output but   starting at line 614 we can see where  maven deploy started and on line   617 we can see where it started uploading the  maven package to the url that we specified   in the palm.xml file and you can see in  the url how it expanded the predefined   environment variables like the api url for GitLab  as well as the GitLab project id right here   and then also the the tag version name as well  so it appears that it successfully uploaded   our maven package to this project’s package  registry and to verify that let’s go to the   packages and registries section and then I’m  going to navigate to the package registry page and from this page you can see  that we have one package available   and it’s associated with the v 1.0.0 tag and  it’s a maven package so if I were to open that   the package up we can see all the details  related to this maven package so on this   page it provides a history of the package  and it also shows me how to add this package   as a dependency in a downstream project  and also how to set up this registry   this GitLab projects registry in my palm.xml file  and then i can also access the files associated   with this maven package so that’s pretty much  all I had for this video I hope you enjoyed it   and I will see you in the next series if you’d  like to learn more be sure to follow our blog at   lambdatest.com forward slash blog as well as our  LambdaTest community at community.lambdatest.com you can also earn resume worthy  LambdaTest Selenium Certifications   at lambdatest.com forward slash certifications you

By Amjad Izhar
Contact: amjad.izhar@gmail.com
https://amjadizhar.blog

Affiliate Disclosure: This blog may contain affiliate links, which means I may earn a small commission if you click on the link and make a purchase. This comes at no additional cost to you. I only recommend products or services that I believe will add value to my readers. Your support helps keep this blog running and allows me to continue providing you with quality content. Thank you for your support!