... | ... | @@ -664,66 +664,5 @@ scope, but could be considered instead of Docker for runners. |
|
|
|
|
|
### Jenkins
|
|
|
|
|
|
[Jenkins][Jenkins CI] was a fine piece of software when it came out: builds! We
|
|
|
can easily do builds! On multiple machines too! And a nice web
|
|
|
interface with [weird blue balls](https://www.jenkins.io/blog/2012/03/13/why-does-jenkins-have-blue-balls/)! It was great. But then Travis
|
|
|
came along, and then GitLab CI, and then GitHub actions, and it turns
|
|
|
out it's much, much easier and intuitive to delegate the build
|
|
|
configuration to the project as opposed to keeping it in the CI
|
|
|
system.
|
|
|
|
|
|
The design of Jenkins, in other words, feels dated now. It imposes an
|
|
|
unnecessary burden on the service admins, which are responsible for
|
|
|
configuring and monitoring builds for their users.
|
|
|
|
|
|
It is also believed that installing GitLab runners will be easier on
|
|
|
the sysadmins, although that remains to be verified.
|
|
|
|
|
|
In the short term, Jenkins can keep doing what it does, but in the
|
|
|
long term, we would greatly benefit from retiring yet another service,
|
|
|
since it basically duplicates what GitLab CI can do.
|
|
|
|
|
|
GitLab CI also has the advantage of being able to easily integrate
|
|
|
with GitLab pages, making it easier for people to build static
|
|
|
websites than the current combination of Jenkins and our [static sites
|
|
|
system](howto/static-component). See the [alternatives to the static site
|
|
|
system](static-component#Alternatives-considered) for more information.
|
|
|
|
|
|
[Jenkins CI]: https://en.wikipedia.org/wiki/Jenkins_(software)
|
|
|
|
|
|
TODO: "audit" jenkins as per [this document](https://bluesock.org/~willkg/blog/dev/auditing_projects.html), possibly in its own
|
|
|
"jenkins" service page.
|
|
|
|
|
|
In particular, we need to answer:
|
|
|
|
|
|
* Why does this project exist?
|
|
|
* What does this project do?
|
|
|
* What is the context in which it exists?
|
|
|
* Who has worked on this project in the past? (@weasel?)
|
|
|
* Who is currently working on this project? (@weasel? @hiro?)
|
|
|
* Who are the stake-holders? Who "owns" the service/application?
|
|
|
(@weasel is the service admin i believe)
|
|
|
* Who will cry out in anguish when the service/application goes down?
|
|
|
(lots? which team still use it?)
|
|
|
* Are there other projects that depend on it? What are they? (same as
|
|
|
above?)
|
|
|
* Are there possible future users that this project is working
|
|
|
towards? (maybe more a question for GitLab CI)
|
|
|
* Is there an active community around this project? (Jenkins is still
|
|
|
healthy, actually, but not well supported in Debian)
|
|
|
|
|
|
* design and architecture? do we really need to dive into this? would
|
|
|
include stuff like:
|
|
|
* What are the major components, services, storage systems, queues,
|
|
|
etc for the project?
|
|
|
* What data does the project use and how does it flow through the
|
|
|
system?
|
|
|
* What languages, versions, and runtimes are used?
|
|
|
* interesting in the context of replacing with GitLab CI: What
|
|
|
infrastructure is used? How is it defined? Who is responsible?
|
|
|
* Is there a system for authentication/authorization? How does it
|
|
|
work? Who is responsible for the systems involved?
|
|
|
* where are the repos for control, which repos use it?
|
|
|
* security review?
|
|
|
* technical debt
|
|
|
* urgent stuff |
|
|
See [the Jenkins replacement discussion](service/jenkins#discussion)
|
|
|
for more details about that alternative. |