What Is a Monorepo?

what is a mono repo [Music] if you've worked with jenkins for any amount of time you're probably used to creating jobs that point at a single repository that represents a single application for example let's say that you have an application that is made up of three parts a front-end and two back-ends therefore you have three separate code repositories but how do you create a jenkins job when the code for all three applications live in separate directories within a single repository this scenario is what is known as a monorepo although this is a less common way to manage your source code it's not completely abnormal in this video we're going to take a look at a couple of different ways you can easily manage your jenkins jobs even when using a mono repo here's today's starting point i have a jenkins lts controller it's version 2.303.3 attached to this controller i have a linux based agent that has two executors on it and it also has docker installed on it when this jenkins controller was installed it was installed using install suggested plugins i've also installed the docker pipeline plugin we also have a sample repository for this video the link to that sample repository is down in the description let's go ahead and take a look at that sample repository what we have here is a repository that has a folder for front end which in this case just has a text file and then we also have a back-end folder that actually has two separate folders api and web and each of these have a web text and an api text these are just placeholders we didn't need any real code in order to demonstrate how this is going to work let's go back up to the root of the repository and take a look at jenkinsfile 1. with jenkinsfile1 what we can see here is we are going to get a handle to an agent that has the label of linux which our agent that's connected to the controller has and then based on the stage we're going to use different tooling using via docker the front end one is going to be using node the back end for web is going to be using maven and then for the rest api we're using golang so three separate container images based on the type of application that we're building now let's scroll back up top and see how this is really going to work and it boils down to this win condition when changed that and what this means is from a get change set perspective if any changes happened within the front in directory so we're using ant pattern matching so star star we're looking for front end and then any files within front end and we're also double checking with a before agent so we're actually not spinning up that agent so we're going to evaluate whether or not this change set is associated to a change inside of front end and if it is then this agent gets and then we run the commands so we're looking at our three different folders front end backhand web and backend api so let's head back over to our controller and create a job before we do that let me go ahead and grab my url and let's click on new item and i'm going to call this local just because we'll call it local and pipeline okay and pipeline script from scm we'll change this to git here's our repository url we're on the main branch and our script path is jeans file dash one we'll go ahead and click on save now at this point we've not made any changes to our repository so if we run this job we click on build now what we're going to see is we're going to see a checkout of the repository there's an empty change log probably because this is the first build that's true so we're skipping front end web and rest api because of the change that was made which was no change at all so let's go ahead and go over and make some changes to the files within front end and back end and see how it reacts so i'm going to load up my application here and the first change i'm going to make is to front end and i'm going to just type in some text text literally we'll save that and let's go ahead and commit this change to frontend.txt which lives inside the front end directory so we'll say this is front end and we'll sync the change up okay that change has been made so now that we've made that change let's go ahead and run our job for local so we'll click on build now and looking at build number two we see the clone of our job and then we can see that front end is starting up because this is our node agent and we can see the output for npm version node and catting out front end and then what we have it stops it and then we skip both web and rest api because the changes that were made were only made to the file in front end now let's go and make a change to both back-ends to both web and to api so let's take a look back over here at api we'll say text we'll save that one and we'll go ahead and do the same thing here for api and if we go ahead and check both of those and commit those we'll say that's text and now let's go back over and run our job what we should see this time is that no job will run for front end which it appears that front end was skipped as expected because we made no changes since that last change set to front end but we did have the back end for web and the back end for api both run their respective stages and we can confirm that by taking a look here at the stages now let's think about the scenario where you have multiple mono repos sort of sounds weird right if you have a mono repo within an organization you would think there would be one and only one mono repo but in many organizations instead of going down the full poly repo route some teams will create a mono repo just for their application even though the quote unquote application is made up of three five ten different applications themselves so if we have the case that we have right here a front end and two back ends and that pattern is used throughout numerous types of quote unquote applications then how can we simplify this what do i need to do in order to leverage using that exact same pipeline that i use for this mono repo for those other mono repos well what we can do is we can create our own pipeline and reuse it through a shared library so let's go back over to our repository and take a look at jenkinsfile 2. and what we have here is we're calling in a library shared library and the reference to this shared library is in the readme of the repository and we're going to be calling monorepo pipeline and what we're doing is passing in four parameters a base agent a front-end agent a back-end web agent and a back-end api agent why are we passing those in if we're wanting to be able to use the same pipeline well although the pipeline is the same each of the different applications may need different versions of either node maven or go so this gives the teams the ability to change the versions of these specific agents when they need them if we take a look at mono repo pipeline we can see here that our pipeline from line 8 down to 71 is practically exactly the same the only differences are when we're referencing the agents so in this case pipeline params base agent or pipeline params frontend agent as it references back to what's being passed in to monorepo pipeline so if you're trying to figure out where pipeline params is coming from it's coming from this definition where pipeline params is being loaded in to the values being passed in from the body so let's go back over to our jenkins controller and let's create a new job we're going to say new item we're going to call this multi and click on pipeline click ok we're going to change pipeline script from scm get here's our url we're going to change our branch specifier to main and change our script path to dash 2. we'll click on save and again no changes have been made to the repository yet so we're going to run it once and make sure that that is really true so when we take a look at the output of build number one we see what we saw in the very first run of jenkins file one to where empty change log no change log since the last commit so now we're good well let's go back over to our vs code and let's clean up all of these files so api web and frontend are all now going to be empty but it's going to force a change in my change set so let me go back over here i didn't save these files so save and save now we have three files all three are going to go in we're going to say save and sync changes go ahead and push that up and now let's take a look back over at our job for multi click on build now when we look at the output for number two we see our clone we see our shared library coming in and now we're seeing each stage for node for maven and for go what kind of repository strategy should you follow when working with jenkins as we've seen it is possible to successfully run jenkins jobs for a mono repo however in order to keep the jenkins side of the equation simple and manageable you should opt for polyrepo over monorepo if you have any questions or comments you can reach out to us on twitter at cloudbees if this video was helpful to you give us a thumbs up and if you haven't subscribed to klobby's tv yet why not take a moment click on that subscribe button and ring that bell and you'll be notified anytime there's new content available on cloudbees tv thanks for watching and we will see you in the next video

Channel: CloudBeesTV

Views: 598

Keywords: darin pope, jenkins, jenkins tutorial, jenkins monorepo, monorepo jenkins, jenkins monorepo plugin, jenkins monorepo pipeline, what is a monorepo, jenkins shared library, jenkins pipeline for monorepo, jenkinsfile for monorepo, jenkins pipeline monorepo, monorepo multiple jenkinsfile, multiple jenkinsfile monorepo, jenkins changeset, jenkinsfile changeset, jenkins when changeset, jenkins pipeline changeset example, jenkinsfile when changeset, jenkins pipeline changeset

Id: UyxVsfEWLFs

Length: 11min 51sec (711 seconds)

Published: Thu Nov 25 2021