 Welcome to the GitLab 13.4 release showcase. We'll show you some of the newest features released in 13.4. Hello, my name is William. I'm a technical marketing manager. Today, I will cover a new feature for inline code test coverage right in the Merge Request View. So, what is it? It is a visual representation of code test coverage right in the Merge Request located in the changes view. Orange when no test coverage was found and green otherwise. And why is this important? By having this view available at the moment of reviewing code in a Merge Request, it is easier to determine if the code has been tested, leading this way to a faster and more efficient reviews that ultimately speed up merge and deployments. Follow these links to learn more. And if you want to replicate my demo, under the demo repo, you can find the project. Let's jump to the demo. So, here we are in a project. We can see that Sasha, the developer, has some issues assigned. She selects the first one and creates a merge request from where she will make some changes to the code. Once she's done with the changes using the Web IDE, she will assign this merge request to William for further review. Now, we can see that William gets the merge request assigned, opens it and under the changes view in the merge request, he can find out if the code has been covered by unit test. This information comes from a code coverage tool used to measure the effectiveness of tests. It can show which parts of your code are being exercised by tests and which are not. This information is available in the merge request, making it easier for the reviewer to approve or not the MR and overall, speed up the code quality and deployment process. And how do I do that? Very easy. By taking advantage of the power of GitLab CI. In the GitLab CI YAML file, add the necessary scripts to execute your test coverage tool and make sure to save the report in XML format as a report artifact. Hi, everyone. My name is Itzy Ganbaru, technical marketing manager, and today I will talk about parent child pipeline and what's new in 13.4. Parent child pipeline is a way to split the long and complex pipeline to small modules. Everything runs in the same project, but instead of running one big pipeline and one CI configuration files, we can split it to small pipelines, smaller folders, and each folder has its own configuration file. The child pipeline behaves like a regular pipeline because it's on stages and drops and it runs. When it runs, it runs like a normal pipeline. So what's new in 13.4? Child pipelines now can trigger their own child pipeline. And this is useful for cases that where also the child pipeline become complex, now GitLab allows another level of nested pipeline. And currently supports nested child pipelines with depth of two real discussions to increase it to five, but this is currently can support only two. So why does it matters? As the pipeline become more complex, new challenges comes with the pipeline. First, the overall distribution time become longer, and when we speak about DevOps and CI CD, we try always to optimize the pipeline time. So our child pipeline breaks the normal stages and allows to reduce the overall pipeline execution time. The second thing is that it simplifies the configuration. Instead of having the one complex long file CI CD other file, of course, now we can break it to small models, which can be easy to manage. And maybe even different teams can manage their module and not the one team need to manage the entire pipeline. Sometimes we use the imports include, when we include the some templates, which is a great capability, but sometimes also it leads to complexity. Also it potentials for namespace collisions where jobs are unintentionally duplicated. So this solved the problems that we have been with the import includes. Instead of include, you can just trigger child pipelines. Here is another advantage is the ability in on runtime to determine if you want to start or not start a sub pipeline and the ability to dynamically define that and create dynamic child pipeline is very strong for some customers. How it works. Very simple. In the repository, you will need for each child pipeline to create a sub folder. In the sub folder, you will add a .github-ci yaml file for each child pipeline. You need its own CI yaml file. And in the parent, the yaml file to trigger the child pipeline, you will need the trigger job with this keyword trigger. And include the full path of the child configuration file. In this case, Android is the name of the directory. And if now what's new in 2004 is that the child can trigger another child is the same, but you will need to add the full path. Android, Google TV is another directory that I created. And this is how it works. You can also pass variables from the parent to the child pipeline. And a little more, we have my demo project documentation and we have, there is a blog for that. So short demo. So I created the spatial project for parent child pipeline. And so this is the parent. It has two childs and which are two directories that I created, 1200 and one for iOS. This is the main yaml file. And I have two trigger jobs. For the iOS and for the Android. And this is the keyword that I created. And also here keyword. And this is how I pass environment variable for the child pipeline. And let's go to visit the child. So this is my child. And it says it's online yaml. And this child also has three children. And again, here we have a trigger job. That's called to its children, to its child. If I will open the child again, it will have its own configuration with two jobs. The last part of this demo, to see the pipeline visualization and also here there is some improvement in Territor.4 about how you recognize the relationship between child and parent. So two trigger jobs that triggers child pipelines. And this is new. This arrow if you click here, it will open the child pipeline. And if you want to know what with the father, this is the new thing that they highlighted the father. Same here. You can click here to see this child. And this child, you can click here and see. And another child. And I can see the full path to the grandfather. Who is the grandfather for this child? This is his father. And this is his grandfather. So this is a parent child pipeline. It's important for customers because it's useful. It decreases overall exhibition time and decreases complexity. So go to know that it exists. Play with it. Thank you for watching. Bye-bye. Hello. My name is Cesar Cvedra. I'm a technical marketing manager at GitLab. In this segment, I'm going to be going over a new feature introduced in GitLab 13.4 called GitLab Kubernetes Agent. What is the GitLab Kubernetes Agent? It is a new way to deploy Kubernetes, two Kubernetes clusters. This is a brand new addition to our product. The agent itself runs inside of your Kubernetes cluster and it orchestrates the deployments by pooling new changes from GitLab rather than GitLab pushing updates to the cluster. This is also known as the pool-based CICD within GitOps. Why does it matter? So for customers, it matters because many organizations, they cannot open their Kubernetes clusters to the Internet because of corporate security compliance or maybe even government security regulations. This new capability will allow them to comply with both types of security regulations. And in short, no matter what method of GitOps customers using, GitLab has you covered, whether it's the pool-based approach to CICD which is this one here or the push-based approach to CICD which is your more conventional way of doing GitOps, which we already support that. So why does it matter to GitLab? So this new capability allows us to be on par with other competitors in the market that already offer pool-based CICD within their GitOps solutions. So now, in fact, many competitors actually only offer pool-based CICD. In our case, we're able to offer pool-based and push-based CICD within GitOps. And those two are actually complementary. It's not either or. You can use one of them only or both together combined. Here are some resources about this new capability. There's a link here to the documentation. There's another link to the issue itself. Soon as this video is public, I will update this presentation to provide the link right there on the left side of the first bullet. And then I also have a much longer video that is an end-to-end demo on how to install GitLab and install the agent on the server side and the cluster side in a demo and how the whole thing works. And things to follow, I'm providing here a link to our revision page for this capability. This is the first release. It's the first MVC that we put out for the Kubernetes agent. And right now it has a configuration-driven setup. And but in the future, we plan to add a lot more features like, for example, integration with the deploy boards and GitLab managed apps, as well as a UI to configure and set up the agent on the cluster. All right, so now let's move on to the demo. I have my own instance of GitLab up on running on GKE, which includes the CAS, the Kubernetes agent server. I have also installed the agent on the cluster. Here you see two projects in the GitLab account. The first one is Kubernetes agent, which contains the configuration of the agent itself, which includes the information about what project will be observed by the agent for changes. And now we're going to go to the GitOps project. This is the project that is being observed for changes. And we're going to go ahead and edit it. And we're going to kind of pay something from the documentation. It's just a manifest file that contains an Nginx deployment. It's going to be deployed under the same namespace of GitLab agent. And that's Nginx right there. And there are two replicas. So once we save this and it's committed to the mainline, the agent will detect that update. And then it'll communicate this to the other server side. It's going to communicate this to the agent. The agent is actually polling. And as soon as it detects the configuration change, it will update the cluster. And as you can see here, the agent has already deployed. The two instances of Nginx. And now, so that you can see how modifications can be immediately detected by the agent, we're going to increase the replicas to three. The agent is going to detect this change. And it's going to go ahead and act upon it and instantiate another pod with a third Nginx, which is right there. Now we have three. So this is a quick demo of the GitLab Kubernetes agent, which allows organizations to use a pool-based CI CD approach to GitOps and without having to expose their Kubernetes clusters to the internet. Hi, my name is Cesar Saavedra. I'm a technical marketing manager at GitLab. In this segment, I want to cover capability introduced in 13.4, track environments at scale with the environments dashboard. Since GitLab 12.5, you can only see seven environments across three projects with the environment dashboard. In 13.4, we introduced an improvement to the dashboard by paginating it to help you support and manage your environments at scale. You can now see more environments across many projects. In fact, you can add up to 150 projects for GitLab to display on this dashboard. Why does it matter? For customers on prospects, usually customers have hundreds of deployments running in their different environments. Besides production, they could have QA, pre-production, integration testing. With this new capability, they are no longer limited to seven deployments across three projects. They can now support and manage many deployments for multiple projects from a single dashboard at scale. This new capability can help you detect, identify, and troubleshoot problems faster. Why does it matter? To us, GitLab allows us to... I mean, the introduction of this new improvement allows us to better compete in requests for information, bids, requests for proposals, as well as proof of concept projects. Here are some resources to read up and learn more about this new improvement. There's documentation there, also the issue for this improvement. And on the right side, you see the link to the city direction page, which includes the area of the environment dashboard. And these are one of the things you should follow. Okay, so now let's move on to the demo. All right, so the way you access the environment's dashboard is by selecting the more menu. And that's how you get to the environment dashboard, and then you click on add project. And let's just search for projects that have the word spring in them. I know projects like that. So there's one, spring NBC JPA, and that has actually two running environments. And let's add some more projects. Let's look for spring again. And find another project that we can add to the dashboard. I think this one is a good one. There you go. That's two more environments. And let's add more projects. Again, let's look for the projects whose names have spring, the word spring. And let's scroll down and find more. There you go. That has only one environment. So let's continue adding more projects. So this time, let's look for projects that have the name Python in their names. So this new project has two environments, and actually they're failed. You can easily see that they are failed environments. And let's add one more with the name Python in it. And there's going to add two more. As you can see here, you have a total of nine environments. You can add up to 150 projects with this new capability. And as you can see, it allows you to see all the environments and on one single dashboard that can help you not just identify and detect problems, but also to troubleshoot them faster. This concludes this demo. Thank you very much. Hey, my name is Fernando, and I'm a technical marketing manager here at GitLab. Today I'm going to show you some of the new features and release 13.4. Well, let me go and share my screen. So the first feature I want to share with y'all is the grant user's deployment permission without code access. So what this does is you can give non-code contributors permission to approve merge requests for deployment and deploy code to what is called a protected environment. So what you can do here is you can give different people access, different groups access, and different roles access to be able to deploy onto protected environments. So one example would be reporters. You can allow them to approve MRs and as well as deploy to protect their environments. And you may want this because they may be some type of testers or some type of customers that want to interact with the product and you want them to be able to deploy the new code change to one environment that they belong to. But you don't want them to be able to access the code, but you want them to check out the new feature and test out the new feature. So there what you would do is you would allow them to deploy to their environment. Developer, same thing. They should be allowed to develop push merge into protected branches, but not into production. So that's like having a dev environment. And within the dev environment, you're giving developers deployment access, but they won't have deployment access to production because that'll be left for maintainers. And then managers and operators will follow the same flow as reporters where you want them to be able to deploy to certain environments, test certain features, but you don't want them to go ahead and mess with the project. And why is this important? So for customers, it allows better separation of duties. And it also gives code access to team members that may need to do emergency approvals and deployments. So maybe the development environment or the staging environment is broken and developers can't do anything and everyone's on vacation. Or different things like that, then approvals can be done by these members and they can also deploy. And you can also set managers probably to deploy to production if needed. So that way they have access for that deployment and they would do it in at a time of emergency. So it really enhances our situations like that, enhances testing and just allows more functionality and gives deployment access to those who really need it. And for us, it enhances our CI permission capabilities. So it just enhances our portfolio of capabilities we have within permissions. Some resources and now let me just show you how it works. So it's pretty easy to set up in the project settings. You go to the CI CD settings. You select protected environments and select an environment. So I'm going to say staging. And I'm going to allow all developers and maintainers to be allowed to deploy the staging and that's it. That's all I have to do. And that'll be a protected environment that developers and maintainers are allowed to deploy in. And this can even be changed to individual members or different groups which are part of this project. And that's pretty simple and that goes. And now let's move on to the next feature. So the next feature is a security center. This will be a quick one. So what we have done here at GitLab is we've made the Instant Security Dashboard more of a security center. So what we've done is we've kind of moved everything around and made everything a lot cleaner and a lot more organized. And it provides a better user experience. So as you can see, the biggest change is the menu structure. So rather than everything being on a single page, everything has been separated into little sub pages. And it just adds all the security related functionality to one page where a user can easily go through. And why does this matter? Well, it provides a better user experience for our customers. Makes it easier for them to navigate through the security context and assess the security posture of projects and groups of projects in more of a natural way without having to jump into different menus and different systems and find everything they have everything open one place. So it just enhances their experience. And for us, one reason why this is beneficial for us is it makes future enhancements a lot easier. So developers within GitLab can make it a lot easier to develop new features and new things within the security space. And all the security functionality can be added to one place so that way there's no confusion on where it is. Here's some documentation. And now let's jump into a quick demo. And this is how it looks. So you can see that there's a security tab. And from here, you can see the projects that are here. They're given a different security status, A through F, depending on the severity of the vulnerabilities found. There is a vulnerability over time showing how many vulnerabilities have been introduced and at what time they were introduced. And from there, you can see that you can easily access the vulnerability report that will have the different vulnerabilities within every space and can be sorted by status, severity, standard and project. And then you can also see that the settings are available as well. So you can keep adding different projects to build your whole instance level security dashboard. And yeah. And now to move on to the final feature, which is the most exciting one for me, is using Hashtag for both secrets and CI jobs. Now, what was added here in 13.4 is a new secret syntax for the GitLab CIMO, which is a secret syntax. And what this does is it allows GitLab to draw secrets and different variables that are stored as key value pairs in Vault and allows them to use them on your CI job. So a few things to consider about this. Vault is required. There needs to be secrets in Vault and there needs to be a JWT authentication enabled in Vault and needs to be enabled in GitLab as well. And Vault needs to be configured and needs to be able to communicate properly. You need to be able to communicate to Vault through a public IP. So the Vault needs to be exposed externally. And just to consider Vault can be run on Kubernetes as well. So it does require some setup with Vault. The piece that we've introduced is just being able to easily call Vault with certain syntax once Vault has already been set up. And I'm planning to make a demo video on this on how to set up Vault properly and gathering some resources and editing documentation. But for now, I just want to highlight this feature. So why does this matter for our customers? So it adds extra protection to GitLab environment variables by having a secret storage, which is Vault. And number two, it makes it easier to actually access these protected environment variables from Vault by using specific syntax. And for us, it's good because the user it makes the user experience a lot easier, a lot better. But also it adds another great integration to our portfolio and HashiCorp is one of our partners. So it helps us keep integrating different features, different HashiCorp features like Vault. Here's some information. And now let me just let me just show you this. So let me share the terminal real quick. Okay, so in my Vault, there's a few things that I have set up. So I have a policy and my policy says that within this path, I can read and list secrets. So this is my path on Vault OPS data staging secret and within that path, I have different key value pairs. And I'm only able to read and list it based off that policy. Then I have a role. And this role, what it does is it maps to my project ID. So this is only accessible from within my project. And it uses my policy that I've defined up here. So within this project on this space, I can read and list everything in this path. So that's my role. Then I have a key value pair. So I've created a key value pair with a key foo and a value world. And this is secret to the Vault. And it's using kvv2. So the kvv2 secret engine. And then from there, so now we want to be able to access this from GitLab. So how do we do that? So let me share Chrome again. So I've created this project. That's my simply simple notes Vaulted. And a few things to check out. So in the CI YAML, in my deploy staging job, I use this secret syntax. So I'm using the secret syntax. And I'm saying make an environment variable named foo and populate it with what's in staging, secret, and the value the key foo at ops, which is the head directory, which is slash ops, slash staging, slash secret. And then the key is foo. So it's going to populate this with a file that it extracts. And that file is going to contain the value of foo. And then here I'm going to echo foo so you can see what it is. And I'm going to cat foo so you can see what's in that file. So I'll show you the location of the file and the file. And then you can see there's three environment variables required. One is the URL for the Vault server. One is the off-road that I'm using. And one is the off-path, which is JWT because it is a JWT authentication. So this will be pretty standard. That needs to be set up anytime you're extracting secrets. So now let me go ahead and show you the job. So if you look at this job, you can see that if I echo foo, it gives me a path to a temporary file, a temporary directory with the file foo in it. And you can see that once I cat foo, you can see world, which is the value of that key. So that's pretty much the Vault integration and new syntax in a nutshell. And I'm happy to have shown you these features from 13.4. So please reach out to us on the technical marketing slack and let me know if you're interested in any demos on these features and highlighting these main parts. Thank you. So here are with the Atlassian developer page, the developer.alassian.com. This is where we are going to set up Atlassian as Omnia provider. What we do is go to this URL up here and then we're going to create a new app. The app name GitLab. Great. Go ahead and create that. And then this is going to give us a client ID and a secret. So we're going to go make sure that we copy both of these. And left sidebar we'll see under APIs and features. We'll click OAuth2.0. And then there we will call back URL. We'll enter our URL. We can see that's an example right here. So you'll switch that out. Go ahead and save those changes. Our app doesn't have any APIs. And then we'll go ahead and click add. Go to the Jira platform recipe API. Click that. Can figure. And then we'll add the view Jira issue data. We'll also add view user profiles which has already been added. So we don't need to remove that. And then create and manage issues. And we have our app for the GitLab configuration on your GitLab server. Open the configuration file. You either use omnibus or source installation either these codes. For the provider configuration for Atlassian. Same thing you'll use omnibus or source installation code that's specific to each. And then you'll change your client ID and your client secret to the client credentials that you received in the application registration steps we went through. Save that configuration file and then reconfigure or restart GitLab for the changes to take effect. If you install a GitLab via omnibus or from source respectively. And then on the sign in page there should now be an Atlassian icon where the regular sign in form is located and click the icon to begin the authentication process. And if everything goes right the user is signed in to GitLab using their Atlassian credentials. Thanks for watching and I hope you enjoyed. Please hit the subscribe button. And remember here at GitLab everyone can contribute.