6aa1807cdc
The Four Opens are how I expect this project to be run and participated in. |
||
|---|---|---|
| client | ||
| services | ||
| tools | ||
| .dockerignore | ||
| .gitignore | ||
| Dockerfile.jenkins | ||
| Jenkinsfile | ||
| LICENSE.txt | ||
| Makefile | ||
| README.adoc | ||
| essentials.yaml | ||
| supervisord.conf | ||
| update-essentials | ||
README.adoc
Evergreen
Evergreen is an automatically updating rolling distribution system for "Jenkins Essentials." It consists of server-side, and client-side components to support a Chrome-like upgrade experience for Jenkins users.
Design Documents
Evergreen and Jenkins Essentials are both captured in the following design documents:
| JEP | Title |
|---|---|
JEP-300 |
|
JEP-301 |
Jenkins Essentials
Jenkins Essentials provides the end-user with a pre-assembled collection of legos that can be immediately used to implement CI [1] and CD [2] workloads. At the same time, this focus on end-users success in these well-defined scenarios will help the Jenkins project develop new features, and fix bugs, more rapidly than before.
Hacking
Backend services are written in Ruby, while the client-side is a mix of standard Jenkins components and Node.js.
Everything should be easily executed via some Docker tooling behind make. To
run tests for example, simply run make check in the root directory of this
repository.
The Four Opens
Inspired by the Openstack project [3] Jenkins Essentials follows "The Four Opens":
Open Source
We do not produce “open core” software.
We are committed to creating truly open source software that is usable and scalable. Truly open source software is not feature or performance limited and is not crippled.
We use the MIT license.
Open Design
We are committed to an open design process. The development cycle requires active collaboration to gather requirements and write specifications for upcoming releases. Those events, which are open to anyone, include users, developers, and upstream projects. We gather requirements, define priorities and flesh out technical design to guide development for the next development cycle.
The community controls the design process. You can help make this software meet your needs.
Open Development
We maintain a publicly available source code repository through the entire development process. We do public code reviews. We have public roadmaps. This makes participation simpler, allows users to follow the development process and participate in QA at an early stage.
Open Community
One of our core goals is to maintain a healthy, vibrant developer and user community. Most decisions are made using a lazy consensus model. All processes are documented, open and transparent.