jenkins.io Documentation

This repository is the source for the official Jenkins website. It uses Awestruct and Asciidoctor to generate the web presence for the Jenkins automation server.

If you wish to contribute to the website, refer to the Contributing document.

The Jenkins documentation infrastructure is transitioning from an Awestruct-based build system to modern static site generation tools. This retooling aims to solve the limitation where technical documentation was not bound to specific product versions.

Key architectural changes include:

• English Site (jenkins.io): Moving from Awestruct to Antora and Vite.js to provide versioned documentation.
• Chinese Site (jenkins.io/zh/): Moving from Awestruct to Docusaurus to provide a modern look and version control.
• Shared Components: UI components shared across various Jenkins websites (like jenkins.io and plugins.jenkins.io) are managed in the jenkins-io-components repository.

This project involves developing an AI-powered chatbot integrated directly into the Jenkins interface. The goal is to assist users in navigating workflows, accessing documentation, and troubleshooting issues using natural language queries.

Core Objectives

• Workflow Guidance: Answering questions like "How to set up a Jenkins pipeline?" or "How to configure Jenkins for specific use cases?".
• Troubleshooting: Assisting users with common Jenkins issues.
• Resource Access: Providing quick access to Jenkins core, plugins, and official documentation.

Project Details

• Category: Plugins
• Skills Required: NLP, Python, JavaScript/TypeScript, LLM, AI/ML, UI/UX, and Jenkins.
• Estimated Effort: 175 - 350 hours.
• Difficulty: Intermediate to Advanced.

Jenkinsfile Runner Actions allow users to execute Jenkins pipelines directly within GitHub Actions runners. This enables running Jenkins pipelines in a Function-as-a-Service (FaaS) context. The project provides two main types of execution models:

1. Runtime type actions: These run the pipeline directly on the GitHub Actions runner host machine. They are compatible with all runner types (Linux, macOS, Windows) but download dependencies at runtime.
2. Container type actions: These run the pipeline inside a customized container. Most dependencies are pre-prepared in the container, making them faster and more isolated, but they are primarily designed for Linux runners.

These actions are built upon the Jenkinsfile runner command-line tool.

The Plugin Installation Manager Tool is a command-line utility designed to automatically install Jenkins plugins based on provided input. It is primarily used to create reproducible environments and is integrated into official Jenkins container images.

Core Purpose:

• Automate plugin installation via CLI.
• Support reproducible environment setups.
• Facilitate plugin pre-installation in Docker images.

Key Technical Domains:

• Java
• YAML and data structures
• Package management theory
• Command line interface (CLI) design
• Jenkins Docker images and Configuration as Code (CasC)

The Pipeline as YAML experiment aims to provide out-of-the-box support for Jenkins Pipeline definitions using YAML instead of the traditional Groovy-based Declarative or Scripted syntaxes. This approach aims to increase accessibility for users unfamiliar with low-level Pipeline scripting and to improve interoperability with other CI/CD systems like JayeX, Tekton, Travis CI, and GitHub Actions.

Key features targeted for this syntax include:

• Pipeline Types: Support in Pipeline jobs, Multi-Branch Pipelines, and organization folders.
• SCM Integration: Support for YAML definitions stored in SCM (e.g., a jenkinsfile.yml in the repository root).
• Declarative Features: Support for steps, agent definitions, matrix configurations, and post-build actions.
• Tooling: Provision of a YAML Schema or a YAML schema generator for the new syntax.

The remoting-opentelemetry-plugin allows system administrators to monitor and troubleshoot the Jenkins Remoting module (the communication layer between Jenkins controller and agents) using OpenTelemetry.

It collects and exports telemetry data including:

• Metrics: General system metrics (e.g., System CPU load, JVM memory usage) and Filesystem metrics. Metrics can be filtered using regular expressions.
• Logs: Agent logs exported to an OTLP/gRPC endpoint.
• Traces: (Note: Implementation details for tracing are listed as future work/ongoing research).

Data is sent to an OpenTelemetry Protocol (OTLP) endpoint, which you can then visualize using tools like Prometheus, Loki, and Grafana.

The Custom Jenkins Distribution Service is a tool designed to help users package Jenkins distributions as WAR files or Docker images based on specific configurations. It allows for scenario-based configuration of Jenkins core versions, plugins, common settings (user/password, update-center), and plugin-specific configurations (Kubernetes, Sonarqube).

Key features include:

• Selection of Jenkins core version and plugins.
• Support for common and plugin-based configurations.
• Integration with backup/restore and data storage solutions.
• Output as a jenkins.war or a Docker image.

The service is intended to be self-hostable by Jenkins users for internal use.

This project explores best practices and architectural templates for building Android applications using Jenkins. The goal is to document successful patterns and avoid common pitfalls in Android CI/CD.

A proposed proof-of-concept architecture includes:

• A Jenkins controller configured with JCasc.
• An Android agent.
• A generic Docker agent.
• An Android emulator.
• An Android device farm (e.g., using STF).

The setup is intended to be docker-compose based and compatible with Windows, Linux, Vagrant, macOS (x86 and ARM), and Gitpod, making it easily transposable to production environments.