Jenkins Concepts: Difference between revisions
| Line 97: | Line 97: | ||
{{Internal|Jenkins Pipeline Syntax|Jenkins Pipeline Syntax}} | {{Internal|Jenkins Pipeline Syntax|Jenkins Pipeline Syntax}} | ||
===Pipeline Execution=== | |||
{{Internal|Jenkins Pipeline Execution|Jenkins Pipeline Execution}} | |||
=View= | =View= | ||
Revision as of 19:46, 25 October 2019
External
Internal
Node
A machine which is part of the Jenkins environment and capable of executing pipelines or projects. Both the masters and agents are considered to be nodes. To view the list of nodes, go to Manage Jenkins → Manage Nodes.
Master
Agent
An agent, also known as a "build agent", is the runtime that executes the build. Agents to execute a build may be selected with a label expression, specified in the job configuration.
Worker
Equivalent with agent, the master needs workers to execute specific parts of a build pipeline.
Docker Plugin Agent
Executor
Label
Slave
Job
Equivalent with Project.
Jobs can be created from the UI and they show up on the dashboard, in the main table. A job state is maintained in $JENKINS_HOME/jobs/<job-name>. The job directory contains a config.xml and a "builds" subdirectory, which contains build state. The state include links to "lastFailedBuild", "lastStableBuild", "lastSuccessfulBuild", "lastUnstableBuild" and "lastUnsuccessfulBuild".
A job can be configured with Jenkins -> job -> Configure.
A job's configuration contains the following:
- General Configuration
- Source Code Management configuration
- Build Triggers
- Build Environment
- Build definition - usually a shell command.
- Post-build actions.
Each job has its own security context.
Build
A build belongs to a job.
Project
Equivalent with Job.
Items
Freestyle Project
Pipeline
Pipeline Overview
A Jenkins Pipeline is a suite of plugins that implement a continuous delivery pipeline. When integrated with OpenShift, the Jenkins Pipeline functionality provides the engine for OpenShift Pipeline builds. More details about OpenShift Jenkins pipeline are available here OpenShift Jenkins Pipelines.
Pipelines are expressed in Jenkins via the Pipeline DSL syntax (see below). The definition is written into a Jenkinsfile, or declared in the Jenkins UI.
The pipeline code defines the entire build process, which typically includes stages for building the application, testing it and delivering it.
Jenkinsfile
Jenkinsfile contain the definition of the pipeline. It is usually committed in the project source code repository - this makes the CD pipeline to be treated as part of the application to be versioned and reviewed like any other code.
A Jenkinsfile can be written with two types of syntax: declarative (newer and recommended) and scripted.
Pipeline Node
A node is a machine. It is part of the Jenkins environment and it is capable of executing a pipeline.
Pipeline Stage
A stage defines a conceptually distinct subset of tasks performed through the pipeline (e.g. "Build", "Test", "Deploy").
Parallel Stage
Pipeline Step
A single task. A steps tells Jenkins what to do at a particular point in time - a step in the process.
Pipeline Syntax
Pipeline Execution
View
Build Environment
Distributed Build
Plugin
The list of installed plugins can be obtained on the console Jenkins -> Manage Jenkins -> Manage Plugins -> Installed.
Interesting Jenkins Plugins
Server Administration Concepts
Instance State
A Jenkins instance state consists of the following:
- The WAR file
- Plugins.
- Settings
- Build logs
- Artifacts archives
- Jobs
- Various temporary files associated with running the jobs, including repository clones: "jenkins_home/workspace/test-build/.git/..."
Everything mentioned above is stored under $JENKINS_HOME. It is sufficient to archive this directory to make a back up of the instance. Similarly, restoring the data is just replacing the contents of the JENKINS_HOME directory from a back up.
The WAR file is stored under ${JENKINS_HOME}/war. The location can be overridden with --webroot=<new-location>. The WAR is expanded during the startup sequence.
The plugins are stored under ${JENKINS_HOME}/plugins. The location can be overridden with --pluginroot =<new-location>.