Install jenkins with Homebrew

Project links

• Homepage
• Repository

Commands and aliases

• jenkins
• jenkins-cli

Project history

The project began as Hudson in 2004, created by Kohsuke Kawaguchi while he worked at Sun Microsystems. The origin story preserved by the Jenkins community describes Hudson as a way to test code before commits so broken builds would not surprise a team.

In January 2011, Hudson community leaders proposed renaming the project to Jenkins after talks with Oracle left unresolved control over the Hudson name. The follow-up vote produced a strong result for renaming, and the project began moving domains, mailing lists, and GitHub organization identity to Jenkins.

Jenkins developed as an extensible automation server with a large plugin ecosystem, a web administration model, Pipeline-as-code workflows, agents, remoting, and CLI/API surfaces. That breadth explains why package managers often split Jenkins into regular and LTS formulas.

Adoption history

Jenkins spread through development and operations teams because it combined a self-hosted automation server with plugins and job configuration that could fit many build systems, source-control hosts, test runners, artifact stores, and deployment workflows.

The project documentation treats the CLI, plugins, Pipeline, and LTS release line as ordinary administration surfaces, showing how Jenkins adoption includes both interactive web use and scripted operations.

How it is used

Package users install Jenkins to run a controller service, manage jobs and plugins, expose web and API endpoints, and interact with the server through the bundled CLI. Jenkins stores much of its controller and job configuration under JENKINS_HOME as XML files, while newer workflows often define build logic in Jenkinsfiles through Pipeline.

Why package nerds care

Jenkins is package-nerd significant because it is an application, service, plugin host, Java runtime workload, and CLI endpoint all at once. A formula has to encode service startup, upgrade behavior, filesystem state, and compatibility expectations, not merely place a binary on PATH.

The separate Jenkins and Jenkins LTS formulas are also a useful packaging example: the package name communicates release cadence and operational posture while both formulas point back to the same upstream project.

Timeline

• 2004: Hudson, later Jenkins, was started by Kohsuke Kawaguchi at Sun Microsystems.
• 2010: the jenkinsci/jenkins GitHub repository was created in November.
• 2011: Hudson community leaders proposed the Jenkins rename in January.
• 2011: the rename vote concluded with 214 eligible votes for renaming and 14 for the status quo.
• 2011: Jenkins infrastructure began moving domains, groups, and GitHub organization naming to the Jenkins identity.

Related projects

• Hudson is the predecessor name and historical fork context for Jenkins.
• Jenkins Pipeline is the related workflow system for defining delivery logic as code.
• Jenkins plugins are the integration mechanism that connects the server to source control, build tools, cloud providers, credentials, notifications, and deployment systems.
• Jenkins LTS is the related conservative release line packaged separately by Homebrew.

Sources

• https://community.jenkins.io/t/lets-thank-kohsuke-the-creator-of-jenkins/168
• https://github.com/jenkinsci/jenkins
• https://www.jenkins.io/blog/2011/01/11/hudsons-future/
• https://www.jenkins.io/blog/2011/01/29/jenkins/
• https://www.jenkins.io/doc/book/managing/cli/
• https://www.jenkins.io/doc/book/managing/plugins/
• https://www.jenkins.io/doc/book/pipeline/