Isn't this a huge drawback in build time when you have large projects in your monorepo and you're only using one build pipeline? For example I could just create 2 jobs in Jenkins with sparse checkouts on the git repo to frontend and another one to backend. With this solution they'll be run in parallel. Just 1 job for the whole monorepo would take ages to complete.
If we follow the suggestion presented in this video, we are either going to end up with a large Jenkinsfile, or use libraries - a level of complexity one way or the other. Please consider my suggestion: Why not create two Multi-Branch pipelines where the "" is configured to that sub-repo respectively. E.g. *Multi Branch pipeline 1* has ScriptPath= root/Project001 and *Multi Branch pipeline 2* has ScriptPath= root/Project001 . The clause on the changeset gets applied within the 2 Jenkinsfile - at a top level stage element ``` pipeline { agent any stages{ stage('This is Project002'){ when{ beforeAgent true anyOf{ //Need the triggerred by clause so that I can kick off a build using the portal triggeredBy cause: 'UserIdCause' changeset "**/Project002/**" } } stages { stage('Build') { steps { echo 'Building project 002 with nested stages..' } } - - - ``` Do you see any concerns?
This is very helpful, instead of having jenkinsfile in all the sub modules,we now can have one at root directory of monorepo.
Excellent video! Thank you! 👏
Great overview. Thank you
Isn't this a huge drawback in build time when you have large projects in your monorepo and you're only using one build pipeline? For example I could just create 2 jobs in Jenkins with sparse checkouts on the git repo to frontend and another one to backend. With this solution they'll be run in parallel. Just 1 job for the whole monorepo would take ages to complete.
Such a large pipeline is not sustainable. Azure Devops/Git would it in a different way and a much more managrable way (trigger, pr elements in YML)
If we follow the suggestion presented in this video, we are either going to end up with a large Jenkinsfile, or use libraries - a level of complexity one way or the other.
Please consider my suggestion:
Why not create two Multi-Branch pipelines where the "" is configured to that sub-repo respectively. E.g. *Multi Branch pipeline 1* has ScriptPath= root/Project001 and *Multi Branch pipeline 2* has ScriptPath= root/Project001 .
The clause on the changeset gets applied within the 2 Jenkinsfile - at a top level stage element
```
pipeline {
agent any
stages{
stage('This is Project002'){
when{
beforeAgent true
anyOf{
//Need the triggerred by clause so that I can kick off a build using the portal
triggeredBy cause: 'UserIdCause'
changeset "**/Project002/**"
}
}
stages {
stage('Build') {
steps {
echo 'Building project 002 with nested stages..'
}
}
-
-
-
```
Do you see any concerns?
‘Jenkins’ doesn’t have label ‘lunix’
What I expected - what is a monorepo? How is it different from polyrepo?
What this video presents - how to use jenkins on monorepo.
Please fix title.