├── dockers └── compose │ ├── .gitignore │ └── docker-compose.yml ├── pipeline ├── README.md ├── docker-compose.yml └── spc │ └── Jenkinsfile ├── ide ├── .vscode │ └── settings.json └── pipeline.groovy ├── docs ├── extension.md ├── spring-petclinic.md ├── dockers.md ├── JENKINS_HOME.md ├── roadmap.config-as-code.md ├── from-jobs-to-pipelines.md ├── history.md └── resources.md ├── LICENSE └── README.md /dockers/compose/.gitignore: -------------------------------------------------------------------------------- 1 | jenkins_home_on_host 2 | -------------------------------------------------------------------------------- /pipeline/README.md: -------------------------------------------------------------------------------- 1 | # pipeline notes 2 | 3 | ## ACE Editor Shortcuts 4 | 5 | - This is the editor used for pipeline scripts as such it has shortcuts that are useful (some of the ones listed work): 6 | - 7 | -------------------------------------------------------------------------------- /ide/.vscode/settings.json: -------------------------------------------------------------------------------- 1 | { 2 | "jenkins-runner.jobs": { 3 | "ide": { 4 | "runWith": "pipelines-7080", 5 | "name": "ide", 6 | "isDefault": true 7 | } 8 | }, 9 | "jenkins-runner.hostConfigs": { 10 | "pipelines-7080": { 11 | "url": "http://jenkins:7080", 12 | "user": "admin", 13 | "password": "admin", 14 | "useCrumbIssuer": true 15 | } 16 | } 17 | } 18 | -------------------------------------------------------------------------------- /docs/extension.md: -------------------------------------------------------------------------------- 1 | # Extending Jenkins 2 | 3 | Developing plugins is valuable alone but isn't necessary to benefit from the resources to do so: 4 | - Learn the internals of Jenkins 5 | - Which can disambiguate confusing terminology like project/job/pipeline/build/etc 6 | - And we all know code tells the true state of reality so it can clear up things like outdated documentation and inconsistent UI labeling. 7 | 8 | ## Extension Points 9 | 10 | - [Extensions Index](https://www.jenkins.io/doc/developer/extensions/) outlines extension points for 11 | - [`Jenkins Core`](https://www.jenkins.io/doc/developer/extensions/jenkins-core/) 12 | - and popular plugins such as the [pipeline-model-definition](https://www.jenkins.io/doc/developer/extensions/pipeline-model-definition/) 13 | -------------------------------------------------------------------------------- /pipeline/docker-compose.yml: -------------------------------------------------------------------------------- 1 | version: "3.8" 2 | 3 | services: 4 | jenkins: 5 | image: jenkins/jenkins:2.257 6 | ports: 7 | - "127.0.0.1:7080:8080" 8 | volumes: 9 | - jenkins_home:/var/jenkins_home 10 | restart: unless-stopped 11 | # use named volume in this example for jenkins_home, if you have any issues with bind mount sample, then this is recommended (named mount) and is way more performant 12 | 13 | mails: 14 | image: mailhog/mailhog 15 | restart: unless-stopped 16 | ports: 17 | - "127.0.0.1:7025:8025" # mailhog's web app (think test instance of gmail) 18 | # - "127.0.0.1:1025:1025" # jenkins will use `mail:1025` to send emails, only map to host if you want to send files 19 | 20 | volumes: 21 | jenkins_home: 22 | 23 | # FYI host ports only listening on 127.0.0.1 now, see other compose file for more. -------------------------------------------------------------------------------- /pipeline/spc/Jenkinsfile: -------------------------------------------------------------------------------- 1 | pipeline { 2 | agent any 3 | 4 | tools { 5 | // Install the Maven version configured as "M3" and add it to the path. 6 | maven "M3" 7 | } 8 | 9 | stages { 10 | stage('Build') { 11 | steps { 12 | // Get some code from a GitHub repository 13 | git 'https://github.com/jglick/simple-maven-project-with-tests.git' 14 | 15 | // Run Maven on a Unix agent. 16 | sh "mvn -Dmaven.test.failure.ignore=true clean package" 17 | 18 | // To run Maven on a Windows agent, use 19 | // bat "mvn -Dmaven.test.failure.ignore=true clean package" 20 | } 21 | 22 | post { 23 | // If Maven was able to run the tests, even if some of the test 24 | // failed, record the test results and archive the jar file. 25 | success { 26 | junit '**/target/surefire-reports/TEST-*.xml' 27 | archiveArtifacts 'target/*.jar' 28 | } 29 | } 30 | } 31 | } 32 | } 33 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2020 Wes Higbee 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /ide/pipeline.groovy: -------------------------------------------------------------------------------- 1 | pipeline { 2 | agent any 3 | triggers { pollSCM('* * * * *') } 4 | stages { 5 | stage('Checkout') { 6 | steps { 7 | git url: 'https://github.com/g0t4/jgsu-spring-petclinic.git', branch: 'main' 8 | } 9 | } 10 | stage('Build') { 11 | steps { 12 | sh './mvnw clean package' 13 | //sh 'false' // true 14 | } 15 | 16 | post { 17 | always { 18 | junit '**/target/surefire-reports/TEST-*.xml' 19 | archiveArtifacts 'target/*.jar' 20 | } 21 | changed { 22 | emailext subject: "Job \'${JOB_NAME}\' (build ${BUILD_NUMBER}) ${currentBuild.result}", 23 | body: "Please go to ${BUILD_URL} and verify the build", 24 | attachLog: true, 25 | compressLog: true, 26 | to: "test@jenkins", 27 | recipientProviders: [upstreamDevelopers(), requestor()] 28 | } 29 | } 30 | } 31 | } 32 | } 33 | -------------------------------------------------------------------------------- /dockers/compose/docker-compose.yml: -------------------------------------------------------------------------------- 1 | version: "3.8" 2 | 3 | services: 4 | 5 | jenkins: 6 | image: jenkins/jenkins:2.255 7 | ports: 8 | - "127.0.0.1:9080:8080" 9 | volumes: 10 | - ./jenkins_home_on_host:/var/jenkins_home 11 | # using a bind mount to the host `./jenkins_home` means I can easily peruse the jenkins_home files without needing to "get into the container" 12 | restart: unless-stopped 13 | # a named volume is fine too - jenkins_home:/var/jenkins_home 14 | 15 | 16 | 17 | # I like docker-compose because I can easily spin up multiple apps like a test email server alongside jenkins! for testing email notifications from jenkins (later) 18 | mails: 19 | image: mailhog/mailhog 20 | restart: unless-stopped 21 | ports: 22 | - "127.0.0.1:8025:8025" # mailhog's web app (think test instance of gmail) 23 | # "127.0.0.1:1025:1025" # jenkins will use `mail:1025` to send emails, only map to host if you want to send files 24 | 25 | 26 | ## NOTES: 27 | # Host port bindings are constrained to listening on 127.0.0.1 28 | # - avoids external access to services 29 | # - To open external access: 30 | # - Remove IP address constraint to open the flood gates 31 | # - Bind to another IP 32 | # - https://docs.docker.com/config/containers/container-networking/#published-ports 33 | -------------------------------------------------------------------------------- /docs/spring-petclinic.md: -------------------------------------------------------------------------------- 1 | # spring petclinic example 2 | 3 | - Maven requires java as a pre-requisite 4 | - petclinic uses Maven Wrapper `mvnw(.cmd)` to simplify access to `mvn` 5 | - `spring-petclinic` example is attributable to the wonderful work done here: 6 | 7 | ```shell 8 | # create a fork of my repo if you want to push changes while following along 9 | # or use mine without the ability to push changes 10 | git clone 11 | cd jgsu-spring-petclinic 12 | 13 | # TIP - I cannot emphasize enough, make sure the build works outside of Jenkins (and any other CI tool) before you try to wire it into Jenkins. 14 | # In my younger days I struggled with build tools needlessly because I wouldn't break out of them to find out that the build tools were failing and the failure was obfuscated by my CI/CD tool (Jenkins, TC, etc). 15 | # Use the following to take this example for a spin "manually" outside of Jenkins. 16 | 17 | # Windows users, use ./mvnw.cmd 18 | ./mvnw --version # ensure maven works via wrapper 19 | # fix any issues before proceeding (resources below for troubleshooting maven wrapper) 20 | 21 | ./mvnw # no args will give a build failure and prompt you for needed arguments, you can use this to see a failure in Jenkins as you're learning 22 | ./mvnw --help 23 | 24 | # observe changes before/after, notably the `target` folder 25 | ./mvnw compile 26 | ./mvnw test 27 | ./mvnw package 28 | ./mvnw clean 29 | 30 | # final command that does everything: 31 | ./mvnw clean package 32 | 33 | ``` 34 | 35 | ## Resources 36 | 37 | - [Maven](https://maven.apache.org/) 38 | - [Build Lifecycle](https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html) 39 | - [pom.xml](https://maven.apache.org/guides/introduction/introduction-to-the-pom.html) 40 | - [Standard Directory Layout](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html) 41 | - *helpful for understanding inputs(`src`) and outputs (`target`) that need to be `linked` into `Jenkins`* 42 | - [Maven's Core Plugins](https://maven.apache.org/plugins/index.html#supported-by-the-maven-project) 43 | - Links to source code, for example the [maven-clean-plugin](https://github.com/apache/maven-clean-plugin/tree/master/src/main/java/org/apache/maven/plugins/clean) 44 | 45 | - [Maven Wrapper](https://github.com/takari/maven-wrapper) 46 | - Maven v3.7.0 will include maven wrapper! 47 | - So long as the wrapper works, I recommend pretending it is the maven `mvn` command itself 48 | -------------------------------------------------------------------------------- /docs/dockers.md: -------------------------------------------------------------------------------- 1 | # Dockers 2 | 3 | Nothing but net to master both containerization and Jenkins and merge the two where each exhibits a strength. 4 | - For example, a `Dockerfile` in many ways is very much like a `Jenkinsfile` as each can execute a build (test too, sytle checks, etc) and produce artifacts worthy of keeping including the console output when they run. 5 | - If you're familiar with Docker's multi-stage image builds, you'll know how to easily incorporate a variety of "upstream" and "official" tool images like for `maven` or `dotnet` and string them together to build a pipeline within a `Dockerfile`.... anyways I think contemplating the similarities and differences between `Dockerfile` and `Jenkinsfile` is a worthwile exploration. 6 | 7 | 8 | ## Dockers + Pipelines 9 | 10 | - [Docker + Pipeline](https://www.jenkins.io/doc/book/pipeline/docker) 11 | - These two tools together are a formidable force for simplicity and yet flexibility in all sorts of complicated CI/CD pipeline scenarios. 12 | - Official images 13 | - [jenkins/jenkins](https://github.com/jenkinsci/docker) Controller 14 | - [jenkins/inbound-agent](https://hub.docker.com/r/jenkins/inbound-agent/) 15 | - [Source](https://github.com/jenkinsci/docker-inbound-agent) 16 | - Deprecated, former repository (image) names: 17 | - [jenkinsci/jnlp-slave](https://hub.docker.com/r/jenkinsci/jnlp-slave) 18 | - [jenkins/jnlp-slave](https://hub.docker.com/r/jenkins/jnlp-slave) 19 | - Plugins 20 | - [Jenkins Cloud for Docker](https://github.com/jenkinsci/docker-plugin) for dynamic docker agents 21 | - TODO from below 22 | - Source 23 | - https://github.com/jenkinsci?q=docker 24 | 25 | 26 | ## Docker + maven example 27 | https://github.com/jenkinsci/pipeline-examples/blob/master/declarative-examples/jenkinsfile-examples/mavenDocker.groovy 28 | 29 | 30 | ## Plugin Installation Manager 31 | 32 | - 33 | - In docker images, replaces [`install-plugins.sh`](https://github.com/jenkinsci/docker/blob/master/install-plugins.sh) 34 | - Port from `bash` to `java` 35 | 36 | 37 | ## Plugins (TODO) 38 | 39 | - https://github.com/jenkinsci/docker-commons-plugin 40 | - https://github.com/jenkinsci/docker-workflow-plugin 41 | - https://github.com/jenkinsci/docker-agent 42 | - https://github.com/jenkinsci/docker-build-publish-plugin 43 | - https://github.com/jenkinsci/docker-build-step-plugin 44 | - https://github.com/jenkinsci/docker-ssh-agent 45 | - https://github.com/jenkinsci/kubernetes-plugin 46 | - https://github.com/jenkinsci/docker-slaves-plugin 47 | - https://github.com/jenkinsci/docker-custom-build-environment-plugin 48 | -------------------------------------------------------------------------------- /docs/JENKINS_HOME.md: -------------------------------------------------------------------------------- 1 | ## What is JENKINS_HOME 2 | 3 | - `JENKINS_HOME` is where Jenkins stores data on disk, such as: 4 | - system `config`, `plugins`, `fingerprints` 5 | - `workspaces` (temp directories for executing jobs aka builds) 6 | - `jobs/[JOB_NAME]` (each job has its own nested folder under jobs where job (aka project) config resides as well as its `build history`) 7 | - `build history` (jobs/[JOB_NAME]/builds), each `build` (aka `run`) has its own folder named after the `build number` 8 | - `JENKINS_HOME` docs: including backups/restores/job manipulation on disk... 9 | - Location defaults to `~/.jenkins` 10 | - Can set with env var OR system property, both named `JENKINS_HOME` 11 | 12 | ## When running in a Docker container: 13 | 14 | The `jenkins/jenkins` Docker image has `JENKINS_HOME` set to `/var/jenkins_home` 15 | 16 | ### Bind Mounting JENKINS_HOME 17 | 18 | - use volume short syntax: `./jenkins_home:/var/jenkins_home` 19 | - will create `./jenkins_home` if it doesn't exist on the `host` 20 | - path is relative to `docker-compose.yml` or `$PWD` for `docker container run` 21 | - Docker docs for bind mounts: 22 | - Considerations 23 | - Bind mounts are easily `host` accessible granting you access with all the tools (CLI and GUI) installed on the host. 24 | - Can cause permission issues when dealing with host fs issues versus container... especially possible if using `Docker Desktop for Mac/Windows` 25 | - but not always going to be a problem, often works fine. 26 | - TIP: If you get random errors that seem disk related, check if removing the bind mount fixes the seemingly random issue. 27 | 28 | ### Named volume for JENKINS_HOME 29 | 30 | - use volume short syntax: `jenkins_home:/var/jenkins_home` 31 | - tells docker to create or reuse a `named volume` called `jenkins_home` 32 | - Volume docs: 33 | - volume drivers allow pluggable storage 34 | - by default it's a folder somewhere on the host 35 | - Considerations 36 | - explicit name makes it easy to know what is what in `docker volume ls` 37 | - explicit name means it won't be cleaned up with `docker volume pr` 38 | - named volumes outlive (typically) the initial container they were attached to so naming grants an independent lifecycle versus the container using the volume 39 | 40 | ### Anonymous volume for JENKINS_HOME 41 | 42 | - If you don't specify a volume mapping for `/var/jenkins_home` then an anonymous volume will be created because the `Dockerfile` for the official `jenkins/jenkins` image codifies this special directory so it is persisted. 43 | - Considerations 44 | - anonymous volumes are intended to be disposable 45 | - anonymous volumes often are removed when the associated container is removed 46 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Jenkins Getting Started 2 | 3 | ## 2nd Edition Examples **[CURRENT EDITION]** 4 | 5 | - Course repositories: 6 | - [2nd Edition INDEX / COURSE OVERVIEW repo](https://github.com/g0t4/course-jenkins-getting-started). 7 | - I recommend cloning this repo and/or clicking links provided! 8 | - Each edition of the course has its own set of repos. 9 | - **AVOID GOOGLING** or **GITHUBOOGLING** (is that a word? :smiley:) and instead follow these links 10 | - [spring-petclinic - example notes](docs/spring-petclinic.md) 11 | - repo: https://github.com/g0t4/jgsu-spring-petclinic 12 | - https://github.com/jenkins-getting-started/jgsu-spc-jenkinsfile 13 | - `spring-petclinic` `pipeline` ported to a `Jenkinsfile` in `git` 14 | - https://github.com/jenkins-getting-started 15 | - This is a GitHub org I setup with several repos for the last demo of the course, to be scanned by Jenkins 16 | 17 | ## 2nd Edition docs/notes 18 | 19 | See the [docs](docs) folder for various additional notes I've left for you. Quite a bit of this is stuff not in the course that I wanted to share with you as you get started. Some of it is fodder for learning beyond the course. 20 | 21 | ## FAQ 22 | 23 | - **I am having an issue with building code in the `jenkins2-...` repository, how do I fix that** 24 | - If you are watching the updated / 2nd Edition course (most likely). Use the updated repos too ([see above](https://github.com/g0t4/course-jenkins-getting-started/blob/master/README.md#2nd-edition-examples-current-edition)). 25 | - If you want a challenge or are watching the 1st edition, try to adapt the 1st edition repos to work with the 2nd edition examples! A great learning opportunity! 26 | 27 | ## 1st Edition 28 | 29 | - The 2nd edition is an update to my original (1st edition) [`Getting Started with Jenkins 2`](https://www.pluralsight.com/courses/jenkins-2-getting-started) course. 30 | - You can follow this link to access the original course which is longer and has some content that wasn't included in the update given that we wanted to shrink the duration for placement into a jenkins learning path. And of course include relevant new features where applicable. 31 | - FYI the vast majority of content in the 1st edition is still relevant in the latest versions of Jenkins! 32 | - In the 2nd edition update, the `2` is dropped from the course title even though I'm still covering the latest version of Jenkins which is still `2`. 33 | - Accordingly I have dropped the `2` from repos and instead use `jgsu` in many cases as a prefix. 34 | - `jgsu` = `jenkins getting started update` 35 | - `jenkins2` was the prefix of many first edition repos. 36 | - [1st Edition Overview/Resources Gist (https://git.io/vKSVZ)](https://git.io/vKSVZ) 37 | - I share these mostly to avoid confusion with associated repos and examples that are and will continue to remain accessibly here on GitHub. 38 | - This `Jenkinsfile` highlights a complex pipeline with multiple nodes involved and parallelism, for a challenge try to get this up and running on your own. Or at least read through it and grok what you think is needed to get it working. 39 | -------------------------------------------------------------------------------- /docs/roadmap.config-as-code.md: -------------------------------------------------------------------------------- 1 | # Roadmap - Configuration as Code (JCasC) 2 | 3 | Watch this area! And the ecosystem of related changes (see my ramblings here, I probably won't have time to fit much, if any, of this into the course and I wanted to share it with you). 4 | 5 | - [Jenkins Configuration as Code `JCasC`](https://www.jenkins.io/projects/jcasc/) 6 | - [source](https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/README.md) 7 | - A primary focus of v2 was to reduce barriers to entry 8 | - to go from not knowing anything about jenkins to using it as fast as possible 9 | - or to standup new instances quickly even for experts 10 | - safe by default 11 | - hence, steamlined setup wizard (suggested plugins, create first account, URL, go!) 12 | - hence, pipelines/`Jenkinsfile` 13 | - Setup can be further streamlined... 14 | - I know because a while back a I created a [bootable zero-config docker image](https://hub.docker.com/r/weshigbee/jenkins-bootstrapped) for another course so I didn't have to constantly wait for plugins to install and poke through the setup wizard and so I could avoid the specifics of Jenkins in that course as my courses tend to run long (I like depth! and I bet you do too if you're reading my thoughts here) enough as it is and I didn't want the overhead of demonstrating configuring, let alone explaining, jenkins. I wanted ready to go instances for myself and viewers. 15 | - Think Configuration Management with 16 | - reasonable defaults 17 | - jenkins config checked into a `git` repo! 18 | - just like `pipeline` (`Jenkinsfile`) did for jobs 19 | - yaml, yaml, yaml (instead of XML) - yaml is all the rage these days which doesn't inherently make it better 20 | - desire to eliminate/reduce need for groovy init scripts (IMO nothing is inherently wrong with scripting and that is why it...) 21 | - ...warms my heart to see JCasC get its own groovy plugin for groovy scripting! 22 | - 23 | - Perhaps one can say the goal is to simplify the scripting! 24 | - Config -> Code -> Config ... that's inevitable in all of software dev (back and forth) 25 | - System config: 26 | - Jenkins has [xml config](https://wiki.jenkins.io/display/jenkins/administering+jenkins) + [groovy init scripts](https://wiki.jenkins.io/display/JENKINS/Post-initialization+script) 27 | - [Configuring Jenkins upon start up](https://wiki.jenkins.io/display/JENKINS/Configuring+Jenkins+upon+start+up) 28 | - [Groovy Hook Scripts](https://www.jenkins.io/doc/book/managing/groovy-hook-scripts/) 29 | - JCasC brings yaml config + groovy scripts 30 | - Somewhat like jobs: 31 | - Freestyle projects/jobs (xml config) 32 | - Then (scripted) pipelines (code) 33 | - Then (declarative) pipelines (config-ish) 34 | - Now [yaml pipelines (config)](https://plugins.jenkins.io/pipeline-as-yaml/) 35 | - **IMHO a mix of both is best** 36 | - `config` (opinionated aka magic aka does much with a little bit of config that is intuitive) 37 | - `code` (flexibility) 38 | - I'm happy to see active exploration into making things better as long as its practical (eventually is fine ::smiley:: ). 39 | -------------------------------------------------------------------------------- /docs/from-jobs-to-pipelines.md: -------------------------------------------------------------------------------- 1 | # From Jobs to Pipelines 2 | 3 | ## Rooted in Builds 4 | 5 | - App builds 6 | - Take inputs (source code) 7 | - Run a compiler or build tool that invokes one under the hood. 8 | - Capture outputs (logs, files) 9 | - and Report back (notifications). 10 | - `builds` were one of the first prevalent tasks to automate. 11 | - Hence the prevalence of `build` terminology in just about every automation platform, not just Jenkins... 12 | - Even `TeamCity` has only recently distinguished [`build configurations types`](https://www.jetbrains.com/help/teamcity/build-configuration.html#Build+Configuration+Types): 13 | - `regular build configuration` 14 | - so, builds... 15 | - and everything else that's not a defined `build configuration type`. 16 | - [`Composite type of build configuration`](https://www.jetbrains.com/help/teamcity/composite-build-configuration.html) 17 | - [`Deployment type of build configuration`](https://www.jetbrains.com/help/teamcity/deployment-build-configuration.html) 18 | - I am documenting this not to criticize anything, but so that you can disambiguate the explosion of often overlapping terms in any CI/CD tool, Jenkins included. 19 | - Don't get frustrated, **pick the term you like** and stick with it, **don't fret over the "proper" term in a given situation** just get your point across. There's no one right term in almost every situation 😃 20 | - *Try this:* everywhere you look, even in current versions of Jenkins you will find relics of the fundamentals of building apps (notably the word `build`) 21 | - Console output / logs 22 | - Source code 23 | - Web UI (build steps, builds, build results) 24 | - Email notifications 25 | - Plugin names! (even suggested plugins and the setup wizard) 26 | - TODO - REVIEW - Even in `pipelines` relics of the prevalence of `builds` linger in the form of `steps` (aka `build steps`) and `publishers` (aka `post build actions`) 27 | - After two decades the `build` parlance lives on! 28 | - `job` is a good generalization of `build` because it isn't specific in what it can accomplish. 29 | - `build` `jobs` were just the beginning! 30 | 31 | ## Myriad Jobs 32 | 33 | Take a minute and think what all would be nice to have automated when it comes to the work you do. Here's some ideas from my early days of software development: 34 | 35 | - `automated unit testing` - testing gives me confidence to run, not walk. Also, running tests on every check-in makes testing all the more worthwhile. 36 | - `database migrations` - this blew my mind, the thought of methodically changing schema and/or modifying data to fit new purposes and doing so in a reproducible manner so that when you get to a `prod deploy` there are 🙏 no surprises. 37 | - That means no manual execution of hand-crafted SQL scripts (Sunday at 2am). 38 | - `deployments` - what if the app was just deployed every time a check-in passed muster? 39 | - `provisioning` - what about the infrastructure that runs the app? How does it get created? What if it just appeared! What if it was reproducible! 40 | - `smoke testing`/`integration testing` - what about tests that require multiple components that may each be updating? 41 | - `manual testing` - what if you had an automatically updated environment that people could run manual tests against? Or exploratory tests? 42 | - `demo instances` - what if you white label your software and want to setup demos for prospective and/or seasoned customers? 43 | - What if you could parameterize a `job` to take a customer name and spit out a running instance of your app to demo, fully loaded with data! 44 | - `upgrade testing` - what about when customers want to update, what can go wrong? Can you write tests to mitigate failures? 45 | - `parallel testing` - what about slow tests? How can we speed them up? Some tests can (and should) be nuked but beyond that we need a mechanism to spread out the load and/or scale up capacity to handle the peak demand of 9to5 work. 46 | 47 | ## Reality is like a `workflow` or a `chain` of `jobs` 48 | 49 | - The above `jobs` are all part of the process of getting from idea to working software. 50 | - `workflows` - linking the `jobs` helps us model and automate a `workflow`, such as: 51 | - `build` 52 | - then `deploy to a test environment` 53 | - then `run integration tests` 54 | - when time consuming, run tests or test sets in parallel 55 | - then `deploy to a manual testing environment` 56 | - pause for humans to tinker with `manual and exploratory tests` 57 | - if all is well, `simulate a production deployment` including tests 58 | - if that passes, then `deploy to prod` 59 | - This is likely a simple workflow compared to reality, after all this workflow doesn't mention databases! 60 | - `job chaining` or `build chaining` was doable with `upstream` and `downstream` `job` `linking` forming a `workflow` or `pipeline` 61 | - Someone checks in changes, a `build` job is triggered 62 | - The `build` succeeds so then you want to run the next job: `deploy to a test environment` 63 | - That means the `build` job is `upstream` to the `deploy to test environment` job which is `downstream` to the `build` job. 64 | - Think of a stick (compiled app) floating down a stream of water. 65 | 66 | ## Why not create a single job to rule them all 67 | 68 | - That's viable but with the tooling in early versions of Jenkins it was prohibitive for a variety of reasons. 69 | - `jobs` just weren't created to model `pipelines` thus `linking` was necessary and unfortunately tedious! 70 | - **This is one of the reasons I loathed Jenkins v1! And it's the impetus behind the most fundamental change in v2!** 71 | - Compound this with having multiple apps needing similar `pipelines` and the work to set that up explodes! 72 | - Back to the question of one job to rule them all, well ok but... 73 | - Imagine you fail in the middle of a `pipeline`, can you retry just the part that failed? Is that safe? 74 | - Often with failures you just need to retry the `job` that failed and not re-run `upstream` jobs. 75 | - 😈 like when you're configuring a new `pipeline` and troubleshooting failures inside Jenkins without first checking them alone at the command line! 76 | - Woops, I forgot a semicolon in my prod deploy script... there goes 30 minutes of testing! 77 | - Say you lose internet for a second while `deploying to a test environment`, why would you want to compile and run unit tests again? That's silly, time consuming and potentially error prone. 78 | - There's good reason to split up a `pipeline` into multiple linked `jobs` and `promote` `artifacts` between `jobs` as needed. A simple example is that you want to take the app you packaged up in your `build` job and deploy it in each `deploy` step. 79 | - Definitely you don't want to deploy an untested version of the app because someone committed a new change while you were testing a previous version. So you need traceability of artifacts. 80 | - You don't want to define, let alone compile your source in each `job`... just imagine the wasted time! 81 | - O(n) wasted where n is the number of jobs. 82 | - Partitioning a pipeline is helpful to: 83 | - Visualize progress 84 | - When a failure happens you already know what subset (job/stage) failed. 85 | - You likely can re-run from the point of failure 86 | - If the problem is independent of your app, like a network or power outage. 87 | - Or, if it's a code bug you'll need to fix it and re-run the entire pipeline. 88 | - Or, only re-run part of the pipeline if a test had a bug in it but the app code was fine. 89 | - Controlling how the pipeline executes is another argument for splitting it up. 90 | - Sometimes you want automated promotion such that `downstream` jobs run automatically if `upstream` jobs succeeded. 91 | - Sometimes you want manual approval. 92 | - Sometimes you want a bit of both, to manually schedule an automated promotion (deployment). 93 | - All of this combined with the inflexibility and tedium of the legacy `job` approach with `linking` is what gave rise to `pipelines` defined in `code` instead of a rigid `job config form`. 94 | -------------------------------------------------------------------------------- /docs/history.md: -------------------------------------------------------------------------------- 1 | # History 2 | 3 | A bits of history to be aware of, especially terminology evolutions. 4 | 5 | ## Terms related to what you automate with Jenkins, that I think of as `functions` 6 | 7 | - Jenkins is a large, `open-source` effort with a vast `community` supporting it, notably the `ecosystem` of `plugins`. 8 | - `Jenkins Core` is the foundation upon which plugins define the behavior of a given `Jenkins` `install`/`instance`/`environment`. 9 | - As such, changes take time (often years) to propagate. Especially true when changing terms. Several terms are de facto `aliased` and so it is helpful to be aware of the mapping between previous and current terminology. I'll provide that along with an explanation of prominent terms you should know. 10 | - `mindset` - It's important to have a perspective with which you organize your understanding of any given subject. Here's my `mindset` to organize `Jenkins` and make it more intelligible. Your `mindset` may vary (YMMV 😉) 11 | - I find it helpful to contrast 12 | - `long running processes` 13 | - such as a GUI app like VSCode, or `Jenkins`! 14 | - versus `one-off`/`task`/`short lived processes` 15 | - such as a virus scan, disk defrag, or an app build with `maven` or `dotnet` 16 | - `tasks` must be triggered somehow 17 | - `manually` by a human (aka `long running process`) 18 | - `scheduled` to repeat with a tool like `cron` 19 | - `react` to some event 20 | - notably with software dev we often want to trigger `tasks` in relationship to changes being published to say a `git` repo 21 | - an `on push` or `on share` trigger, whatever lingo floats your 🚣 22 | - event detection varies 23 | - `poll` model - a `long running process` like Jenkins can `poll` for changes 24 | - `polling` is likely triggered on a `schedule` because `polling` for changes to detect an event is yet another `task`! 25 | - `push` model - an external `process` notifies Jenkins of changes and then a `task` in Jenkins will confirm (ie the `poll` task) and fetch changes to then trigger user-defined `tasks` to say `compile` an app. 26 | - I recommend a `function` mindset to grok the `tasks` you configure Jenkins to automate. So, user-defined `short lived processes` can be thought of as `functions`! 27 | - Somewhere exists a `function declaration` (aka `configuration` or `code`) 28 | - A function has `input(s)` (aka `parameter(s)`) 29 | - It `runs`/`executes` on the `inputs` (clone git repo, compile app, run tests, etc) 30 | - Concurrently `logs` progress, often via `STDOUT`/`STDERR` 31 | - Produces `outputs`/`artifacts` in the form of file(s) 32 | - Even `logs` can be thought of as `outputs`/`artifacts`... `STDOUT` is just a default file descriptor for writing output! 33 | - Select and archive `artifacts` for later retrieval 34 | - Ironically, most of what I said here about functions is just a template of a function declaration! 35 | - **TLDR: `Jenkins` is comprised of `long running processes` that trigger `executors` to run `functions`** 36 | - A big reason I like to think in terms of `functions` is because the actual terminology in Jenkins is murky at times. 37 | - That's because the typical use case of Jenkins (and similar tools) has evolved (roughly from building, to CI and now to CD). 38 | - And many other use cases are logical: 39 | - I could backup a database. 40 | - Or scrape data off of a website and store it for later processing. 41 | - Or perform cleanup on disk to save space, perhaps triggering this when free space runs low and/or on a schedule. 42 | - Calling these `builds` wouldn't make much sense! But, there are parts of Jenkins parlance that would refer to it as such, largely for historical reasons. 43 | - `job`/`project` are generic to capture a wider array of possibilities. 44 | - And even [job is marked deprecated in the Jenkins glossary here](https://www.jenkins.io/doc/book/glossary/#job) while it is used all over the code, UI and docs! 45 | - `pipelines` are a hugely popular feature in Jenkins v2 and have in many cases become another alias for `project`/`job` etc... 46 | - And of course before `pipeline` this feature set was known as `workflow` and you'll see that at times 47 | - `items` are a generic term that encompasses `folders`, `projects` and `jobs` 48 | - `folder` is an `item` to group related `items` 49 | - just like folders on a filesystem 50 | - `VCS`/`git` - I assume you are familiar with version control tools and specifically `git` which is ubiquitous. 51 | - As opposed to folders of code without versioning like was popular back in the day 🙉! 52 | - If you want a challenge you could setup a Jenkins project to build from a network share! 53 | - `build`/`build result` - the output that's captured for a given run of a `project`/`pipeline`/`job`/`function`/`task` 54 | 55 | ## Hudson and the origins of Jenkins 56 | 57 | - `Jenkins` was first known as [`Hudson`](https://en.wikipedia.org/wiki/Hudson_(software)) 58 | - `Hudson` was initially released in 2004 at Sun Microsystems 59 | - [Oracle acquired Sun in 2009/2010](https://en.wikipedia.org/wiki/Sun_acquisition_by_Oracle). 60 | - A dispute over trademarking the name `Hudson` led to the community renaming/forking the project to [`Jenkins` in Jan 2011](https://en.wikipedia.org/wiki/Hudson_(software)#Hudson%E2%80%93Jenkins_split). 61 | - Two forks emerged as Oracle also committed to maintaining `Hudson` 62 | - Politics aside `Jenkins` won the "popularity" contest early on as the community coalesced around the `Jenkins` project (fork). 63 | - `Hudson`'s last release was in 2016 [under the Eclipse Foundation.](https://en.wikipedia.org/wiki/Hudson_(software)#Move_to_Eclipse_Foundation) 64 | 65 | ## Architecture & changed/changing terms 66 | 67 | - `node` - a long running process hosting either a Jenkins `agent` or `master`/`controller` 68 | - `executor` - a `slot` that can run a single `project`, any `node` can have 0+ `executors` 69 | - in larger setups it is typical to not have `executors` on the `master` node to offload all build demand onto `agents` to avoid overwhelming the coordinating `master` node which has plenty of tasks to perform as you scale up demand. 70 | - `master`/`slave` was the original terminology for distinguishing nodes. 71 | - Long ago `slave` was renamed to `agent`. 72 | - `slave` was deprecated as part of Jenkins 2.0 73 | - `agent` is popular in Jenkins alternatives like TeamCity and so it is natural to assume it is easier to onboard new users if terminology is familiar, and hence this change in v2 which was all about making it easier to get up and running with Jenkins quickly. 74 | - [Agent terminology cleanup](https://issues.jenkins.io/browse/JENKINS-42816) highlights the undertaking required to rename a prevalent term that permeates a decades old open-source ecosystem. 75 | - Recently (mid 2020) `controller` was selected to replace `master`. 76 | - This has yet to be reflected in the [glossary](https://www.jenkins.io/doc/book/glossary/) which is one of many reasons why I do not know if this renaming is a done deal. 77 | - Neither change is anywhere near complete so expect to see a mix of both for a while (years). I'll update this if changes are made, let me know if you hear anything definitive. 78 | - I personally refer to the `master/controller` as `Jenkins` and then if applicable `agent(s)`. 79 | - The `controller`: 80 | - Stores configuration 81 | - Hosts the web UI 82 | - Schedules/Coordinates/Distributes execution of `functions` (`pipelines`/`projects`/`jobs`) across `agents` 83 | - And interacts with agents to retrieve and store `output`/`results`/`artifacts` 84 | - `blacklist/whitelist` are now discouraged and replacements suggested but not enforced (yet?), ie `allowlist/blocklist` 85 | - For more about terminology changes 86 | - [learn more here](https://groups.google.com/g/jenkinsci-dev/c/CLR55wMZwZ8?pli=1) 87 | - and [here](https://docs.google.com/document/d/11Nr8QpqYgBiZjORplL_3Zkwys2qK1vEvK-NYyYa4rzg/edit#) 88 | - and likely elsewhere including monitoring the [glossary](https://www.jenkins.io/doc/book/glossary/). 89 | - `JENKINS_HOME` - where Jenkins stores files (running builds/steps, or storing results and artifacts). 90 | - [Learn more here](https://wiki.jenkins.io/display/JENKINS/Administering+Jenkins) 91 | - `workspace` - a temporary, disposable directory to house files for the work requested (git clone, compile, test, package, etc) 92 | - typically left in place between runs of a `project` 93 | - can be helpful to speed up builds when caching / partial compilation is present in build tools 94 | - can be painful if it makes builds hard to reproduce, or leads to flaky tests 95 | - can be cleaned up before/after a `project` runs depending on the `project` config, usually isn't cleaned up by default 96 | - Workspaces are default located in `$JENKINS_HOME/workspace/[JOB_NAME]` 97 | - the `[JOB_NAME]` in the jenkins wiki shows that `job` was and still is a common term. 98 | - anyways, each `job`(`project`) has its own workspace on a given node 99 | 100 | ## later 101 | 102 | - Fingerprint 103 | - Cloud 104 | - Label 105 | - Step (build steps, SUCCESSFUL/FAILED) 106 | - Publisher (post-build actions/steps, STABLE/UNSTABLE) 107 | 108 | ## Pipeline terms 109 | 110 | - `stage` is a grouping of `steps` 111 | - to visualize progress and results 112 | - For example, 113 | - a `"build" stage` might encompass compiling, unit testing and packaging an app 114 | - then a `"test deploy" stage` might encompass provisioning the app and running some higher level integration tests all of which ensures the deploy will work in prod and then leaves a test instance for humans to poke around. 115 | - then maybe a `"prod deploy" stage` which updates a production app. 116 | - sky is the limit 117 | - `step` is a fine-grained task telling what actions to perform 118 | - I think of steps as a line of code 119 | - or shelling out to a CLI command (ie maven) 120 | 121 | ## Build status (aka Project Status technically) 122 | 123 | - Each time you run a `job`/`project`/`pipeline`/etc Jenkins captures what it refers to as a build (result) 124 | - Look in `$JENKINS_HOME/jobs/[JOBNAME]/builds/` for a history of `BUILD_IDs` and the captured results (output) 125 | - The irony is not lost that the result of running what is now a `Pipeline` or `Project` is often referred to as a `Build` or `Build status`! 126 | - `Aborted` means the build was interrupted before completion (manually, timeout, otherwise). 127 | - `Successful` means all build steps completed 128 | - `Failed` means a build step failed (ie a compiler error) 129 | - `Stable` means no publishers reported a failure 130 | - ?Publishers (post-build steps) run after the build steps and thus can amend a `Successful` status to be more specific 131 | - a vestige (IMO) of the history of Jenkins. 132 | - an example might be a unit test parser that reads the result of running unit tests 133 | - `Publishers` are going to be configurable/nuanced in how they determine a failure (stable/`unstable`), so pay attention to the docs for a given `publisher` 134 | - Personally I see a `job`/`project`/`function` as a set of steps and don't bother to distinguish `build` vs `post-build` or `publisher` steps... because why? 135 | - I wish we lived in a world where the `function` either aborted, failed or succeeded and really I just care if a problem exists, that the system helps me by telling me and makes it easy to dissect/troubleshoot. 136 | -------------------------------------------------------------------------------- /docs/resources.md: -------------------------------------------------------------------------------- 1 | # Resources 2 | 3 | 4 | 5 | ## Top level resources 6 | 7 | - [jenkins.io](https://www.jenkins.io/) 8 | - GitHub orgs 9 | - [jenkinsci](https://github.com/jenkinsci) 10 | - [jenkins-infra](https://github.com/jenkins-infra/) 11 | 12 | ## jenkins-infra 13 | 14 | Infrastructure projects 15 | - [jenkins.io source](https://github.com/jenkins-infra/jenkins.io) 16 | - [IEP - Infrastructure Enhancement Proposals](https://github.com/jenkins-infra/iep) 17 | - [infra docs](https://github.com/jenkins-infra/documentation) 18 | - 19 | 20 | 21 | ## Resources Misc 22 | 23 | - [Downloads](https://www.jenkins.io/download) 24 | - [Installing](https://www.jenkins.io/doc/book/installing/) 25 | - [JENKINS_HOME layout](https://wiki.jenkins.io/display/jenkins/administering+jenkins) 26 | - Keeping up to date 27 | - [LTS Upgrade Guide](https://www.jenkins.io/doc/upgrade-guide/) 28 | - [LTS Changelog](https://www.jenkins.io/changelog-stable) 29 | - [Weekly Changelog](https://www.jenkins.io/changelog) 30 | - [Changelog Archive](https://www.jenkins.io/changelog-old) 31 | - [Roadmap](https://www.jenkins.io/projects/roadmap) 32 | - [blog](https://www.jenkins.io/node/) 33 | - Documentation 34 | - [Where to find documentation](https://www.jenkins.io/participate/document/) 35 | - NOTE: often you'll find parts of the jenkins.io docs out of date, most of the time it's not material but it happens and you should be aware that the docs are not always (as is the case in any project) the latest state of the codebase. 36 | - [User Guide / Handbook](https://www.jenkins.io/doc/) 37 | - [Glossary](https://www.jenkins.io/doc/book/glossary/) 38 | - [CloudBees](https://www.cloudbees.com) 39 | - [docs](https://docs.cloudbees.com/) 40 | - [Pipelines](https://docs.cloudbees.com/docs/admin-resources/latest/pipelines/) 41 | - [Checkpoints](https://docs.cloudbees.com/docs/admin-resources/latest/pipelines/administering-jenkins-pipeline#inserting-checkpoints) 42 | - [Plugins](https://docs.cloudbees.com/docs/admin-resources/latest/plugin-management/) 43 | - [Tutorials Overview](https://www.jenkins.io/doc/tutorials) 44 | - [Blog Post Tutorials (category)](https://www.jenkins.io/node/tags/tutorial/) 45 | - [Use-cases/Solutions Page](https://www.jenkins.io/solutions/) 46 | - find language/platform specific help 47 | - For example, [Docker](https://www.jenkins.io/solutions/docker/) 48 | - Or, [Java](https://www.jenkins.io/solutions/java/) 49 | - [Extending Jenkins](https://www.jenkins.io/doc/developer/) 50 | - [Plugin Index](https://plugins.jenkins.io/) 51 | 52 | ## Scaling up 53 | 54 | - [Distributed Builds](https://wiki.jenkins.io/display/JENKINS/Distributed+builds) 55 | - Controller/Agent model (formerly Master/Agent -> formerly Master/Slave) 56 | 57 | ### Labels 58 | 59 | `Node` - (wes defined): any **`process`** running either the `Controller` or `Agent` Application. 60 | 61 | `Labels` are a way to **identify** and/or **group nodes** based on characteristics that are pre-requisites for your `job`/`project` configuration... 62 | 63 | - [ci.jenkins.io labels](https://github.com/jenkins-infra/documentation/blob/master/ci.adoc) 64 | 65 | Wes fodder for labels (think about what your automated tasks need and how to target nodes with those capabilities). It's kind of like if we all listed out the tasks we are good at and then along comes someone with a broken toilet... so we pull up all `plumbers` and hopefully someone is available and capable 66 | (a label is no guarantee that it is accurate!) 67 | Examples (a mix of Wes ideas and stuff I see in reality) 68 | - Hardware 69 | - RAM: `ram-2gb`, `ram-4gb`, `ram-8gb` etc 70 | - CPU: `slow`, `medium`, `fast` 71 | - DISK: `ssd`, `hdd` or even ratings perhaps `max-read-speed-X` and `max-write-speed-Y` 72 | - Dev tools installed 73 | - Broad: `docker-cli`, `xcode`, `msbuild`, `jdk`, `maven`, `grade` `dotnet` 74 | - Granular: `jdk7`, `jdk8`, `jdk9`, `mvn3` or `mvn2` 75 | - Services 76 | - `iis`, `apache`, `nginx`, 77 | - CPU architecture (`amd64`, `arm64`, `ppc64le`) 78 | - OS/Distro 79 | - Broad: `macos`, `linux`, `windows` 80 | - Broad: `debian`, `ubuntu`, `rhel`, `centos` 81 | - Granular: 82 | - Linux distros 83 | - `debian 9/stretch`, `8/jessie` 84 | - `ubuntu-(18.04.5|20.04.1|16.04.7)-lts` 85 | - (https://releases.ubuntu.com/) 86 | - Windows 87 | - `windows-server-(2004|1909|1903)` 88 | - `windows-server-(2019|2016|2012r2|2012|2008r2|2008` 89 | - `win10-(2004|1909|1809)` 90 | - [versions](https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions) 91 | - macOS 92 | - `macos-10.(+15..12)` 93 | - `osx-10.(11..8)` 94 | - `macosx-10.(7...0)` 95 | - [versions w/ codenames](https://en.wikipedia.org/wiki/MacOS#Software_compatibility) 96 | - Browser 97 | - `internet-explorer`, `chrome`, `firefox`, `edge`, `chrome-canary` 98 | - Consider deferring combined labels to be a `"querytime"` feature not a `"labeltime"` feature 99 | - Instead of `ubuntu-20.04.1-lts` we might have: 100 | - `ubuntu` + `20.04.1` + `lts` 101 | - So I could target nodes with just `ubuntu` 102 | - Or, I could say `ubuntu` + `lts` 103 | - Or, `windows` + `server` + `2016` 104 | - Why? 105 | - Avoid redundancy 106 | - Fewer labels, less time labeling. 107 | - Explosion of combinations can be confusing to find what you need 108 | - Many labels will go unused 109 | - Many have zero relevance to the targeting you need 110 | - Consider deferring the labeling process until needed unless it's broad and not a substantial cost. You could literally manually add labels to a small cluster if you need to query a subset of agents that you don't have labels to target. 111 | - Consider dynamic labeling - when the jenkins "node" process runs it can sniff out (aka fingerprint) the environment to set appropriate labels for itself. 112 | 113 | 114 | 115 | 116 | 117 | ## Pipeline resources 118 | 119 | - [Pipeline Syntax Reference](https://www.jenkins.io/doc/book/pipeline/syntax/) 120 | - [Pipeline Step Reference](https://www.jenkins.io/doc/pipeline/steps) 121 | - [Plugin Compatibility with Pipeline](https://github.com/jenkinsci/pipeline-plugin/blob/master/COMPATIBILITY.md) 122 | 123 | - Authoring `pipeline` scripts: 124 | - [`Classic UI`](https://www.jenkins.io/doc/book/pipeline/getting-started/#through-the-classic-ui) 125 | - [`In SCM`](https://www.jenkins.io/doc/book/pipeline/getting-started/#defining-a-pipeline-in-scm) 126 | - [`Jenkinsfile`](https://www.jenkins.io/doc/book/pipeline/jenkinsfile/) 127 | - [CloudBees `Jenkinsfile` docs](https://docs.cloudbees.com/docs/admin-resources/latest/automating-with-jenkinsfile/creating-jenkinsfile) 128 | - [`BlueOcean`](https://www.jenkins.io/doc/book/pipeline/getting-started/#through-blue-ocean) 129 | - [`BlueOcean` docs](jenkins.io/doc/book/blueocean/) 130 | - Official docs list this as separate category but it's really just via SCM + BlueOcean UI generating pipelines 131 | - Arguably `BlueOcean` was yet another step toward the Freestyle project type... BUT, in terms of a simplified UI for pipelines... interesting to watch popularity drift back and forth as people have needs and are compelled to travel in differnet directions to solve those needs. 132 | - BlueOcean can generate/scaffold and commit Jenkinsfiles 133 | - Major dev of BlueOcean has stalled. From what I've read, as of late (2020), the goal is to use BlueOcean "lessons learned" to redesign the Classic UI (in time drastically). 134 | 135 | ## Groovy resources 136 | 137 | - Pipelines are groovy scripts (close enough), so any groovy resources you have will be helpful. 138 | - :+1: Knowledge of groovy 139 | - Psychological Soap Box about `code` vs `config` vs `convention` 140 | - AND instances of types of code (`groovy` vs `java`) 141 | or config formats (`xml` vs `json` vs `yml`) 142 | - IMHO `groovy` is somewhat easy to read and thus it is learnable with less investment than say `shell scripting` 😉 143 | - I don't understand the supposition that people don't like code / can't code / don't want to use code... but somehow DSLs/configuration & convention (even more so) are superior in terms of grok-ability / preferable versus code... no, code/config/convention are all heads of the same coin. 144 | - **(hint: means not ends)** 145 | - > tools in a toolbelt, carry all of them not just one 146 | - > We like what we are familiar with (and we tend to become more familiar with what we like and avoid things that are difficult because even if at one time they were familiar they grow distant out of frustration and thus lack of preference). It's self-fulfilling. 147 | 148 | ## Pipeline Syntax Live Docs/References 149 | 150 | - These are docs that are built-in to a Jenkins instance and are often dynamic according to the plugins installed. Like adding the [`pipeline-as-yaml`](https://plugins.jenkins.io/pipeline-as-yaml/) plugin adds `Pipeline As YAML Converter` tool under `Pipeline Syntax` 151 | 152 | - [Snippet Generator](https://www.jenkins.io/doc/book/pipeline/getting-started/#snippet-generator) 153 | 154 | - 155 | - Form based generation of steps for either a `scripted` or a `declarative` pipeline 156 | 157 | - [Declarative Directive Generator](https://www.jenkins.io/doc/book/pipeline/getting-started/#directive-generator) 158 | 159 | - 160 | - Form based generation of nested directives (ie `when`) 161 | - NOT steps 162 | 163 | - [Global Variable Reference](https://www.jenkins.io/doc/book/pipeline/getting-started/#global-variable-reference) 164 | 165 | - 166 | - `pipeline` declarative "entrypoint" is a global! 167 | 168 | - [Pipeline As YAML Converter](http://jenkins:18080/job/vcs-spc/payConverter/) 169 | 170 | - Great example of adding a plugin (yaml pipelines) and seeing new docs light up under the [`Pipeline Syntax`](http://jenkins:18080/pipeline-syntax/) section 171 | 172 | - [Pipeline examples](https://www.jenkins.io/doc/pipeline/examples/) 173 | - Sourced from [jenkinsci/pipeline-examples](https://github.com/jenkinsci/pipeline-examples) 174 | 175 | ## JCasC - Configuration-as-code 176 | 177 | - Like pipelines-as-code did for freestyle jobs, configuration-as-code does for configuring the Jenkins `controller` 178 | - Historically, we've had `post-init groovy scripts` to modify the configuration of instances. 179 | - [Groovy Hook Scripts](https://www.jenkins.io/doc/book/managing/groovy-hook-scripts/) 180 | - [README.md docs](https://github.com/jenkinsci/configuration-as-code-plugin) 181 | - 182 | 183 | ## IDE/CLI pipeline productivity tools 184 | 185 | Assortment of tools to use on Jenkinsfile/pipelines outside of Jenkins: 186 | 187 | - https://www.jenkins.io/doc/book/pipeline/development/ 188 | - jenkinsfile-runner (JFR) 189 | - v1.0 ~Dec 2020 190 | - Allows you to test Jenkinsfile locally without a hassle all via an official `jenkins/jenkinsfile-runner` image! 191 | 192 | ## Governance / Ecosystem / Community 193 | 194 | - [Project Structure and Governance](https://www.jenkins.io/project) 195 | - [JEPs - Jenkins Enhancement Proposals](https://github.com/jenkinsci/jep/) 196 | - Design of major new functionality that may or may not see the light of day. 197 | - [Sub-projects](https://www.jenkins.io/projects/) 198 | - [JCasC](https://www.jenkins.io/projects/jcasc/) 199 | - [Jenkins X](https://jenkins-x.io/) - opinionated Jenkins mindset (not necessarily components of Jenkins) meets k8s as the clustering tech for everything from dev to prod. 200 | - [Blue Ocean](https://www.jenkins.io/projects/blueocean/) 201 | - [Evergreen/Essentials](https://www.jenkins.io/projects/evergreen/) 202 | - IIUC this has stalled too (services were never migrated earlier in 2020 to new prod cluster) 203 | - [Infrastructure](https://www.jenkins.io/projects/infrastructure/) 204 | - [JIRA](https://issues.jenkins-ci.org) 205 | - by component, ie [Core](https://issues.jenkins-ci.org/browse/WEBSITE-760?jql=component%20%3D%20core) 206 | - [https://ci.jenkins.io](https://ci.jenkins.io) 207 | - Fun way to poke around and see some practical applications of Jenkins 208 | - Jenkins dogfooding itself! 209 | - [Contributing / participating](https://www.jenkins.io/participate) 210 | - [Meetups](https://www.jenkins.io/projects/jam) 211 | 212 | ## TODOs to distill links into: 213 | 214 | - https://github.com/jenkins-infra/documentation/blob/master/ci.adoc 215 | - repos https://github.com/jenkins-infra 216 | - other GH repos 217 | - https://www.jenkins.io/participate/document/ 218 | - https://www.jenkins.io/doc/book/pipeline/jenkinsfile/ 219 | - https://docs.cloudbees.com/docs/admin-resources/latest/automating-with-jenkinsfile/creating-jenkinsfile 220 | - https://www.jenkins.io/doc/book/pipeline/getting-started/#directive-generator 221 | - https://github.com/jenkinsci/pipeline-model-definition-plugin/wiki/Getting-Started 222 | - https://www.jenkins.io/doc/book/blueocean/dashboard/ --------------------------------------------------------------------------------