Open sevein opened 6 years ago
I think we should start simple, only focusing in the master
branch. I think this is important because we want to think first in the implications of how these things happen over time (commit after commit). One branch, one pipeline. Having multiple branches or adding support for pull requests would add parallel pipelines and progression over space.
Our master
branch contains packages that are currently published in the following repos:
We wouldn't have had a problem like #88 if this mechanism was in place. The packages in /1.7.x
seem to be manually placed. Could we have a Jenkinsfile
that automates the whole process?
This is the first Jenkinsfile
that I've written in my life but is this something we could do?
node {
stage('Fetch code') {
checkout scm
}
stage('Build packages') {
jobDsl targets: ['jenkins-groovy/build-packages.groovy'].join('\n')
}
stage('Publish packages') {
jobDsl targets: ['jenkins-groovy/publish-packages.groovy'].join('\n')
}
}
The simplest approach could just build all the packages each time and publish them in a temporary folder and later replace the old folder so it happens atomically? E.g. using rsync --link-dest=...
? I really don't know how's this working internally so please excuse me if this doesn't make any sense.
As a developer I want the packages available in the
master
branch to be accessible via public repositories. If a package is deleted, updated or added tomaster
I want the public repositories to reflect the change as soon as possible.