Learn GitLab in 3 Hours | GitLab Complete Tutorial For Beginners

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

Channel: LambdaTest

Views: 221,056

Keywords: Gitlab, Gitlab ci, Gitlab ci pipeline, Pipeline, Gitlab pipeline, Gitlab pipeline tutorial, Cross browser testing, Gitlab cicd tutorial, Gitlab cicd, Gitlab cicd pipeline, GitLab registry, gitlab vs github, gitlab api, gitlab push local branch to remote, what is gitlab, gitlab tutorial, gitlab runner, gitlab ci, gitlab pages, gitlab ci variables, jenkins, cross browser testing tutorial, cross browser testing with selenium, cross browser testing tools, lambdatest tutorial

Id: 8aV5AxJrHDg

Length: 206min 42sec (12402 seconds)

Published: Fri Dec 10 2021