Mailing-List: contact dev-help@community.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@community.apache.org
MIME-Version: 1.0
From: Christopher <ctubbsii@apache.org>
Date: Tue, 12 Apr 2016 23:13:50 +0000
Message-ID: 
 <CAL5zq9YvcwcmVty-219fwJPSS6OkCjN=q8FwjtaJ7mFJ-A+O+w@mail.gmail.com>
Subject: Jenkins Views cleanup?
To: ComDev <dev@community.apache.org>
Cc: "infrastructure@apache.org" <infrastructure@apache.org>
Content-Type: multipart/alternative; boundary=001a11c08c8af9926e053051d0af

--001a11c08c8af9926e053051d0af
Content-Type: text/plain; charset=UTF-8

So,

I've noticed that Jenkins views are getting kinda crazy.
https://builds.apache.org/

You might not be able to see all the tabs and craziness until you log on.
(I believe Jenkins uses LDAP for authentication).

In short, we used to have tabs for:
"A-F", etc.

Then, some of those sections got too big, so it was changed to:
"A-D", etc.

This broke anybody linking to a particular view.

Now, some projects have started creating their own top-level tabs, which
get mixed in with the "A-D", "E-G", etc. (Example, "Brooklyn", "Tika",
"directory").

To future-proof links to particular views, and to clean up the current
views, I would like to propose (and am soliciting volunteers to help
accomplish this, if there's not a good automated way to configure these)
that we standardize on separate tabs for each of the 26 letters in the
English alphabet "A", "B", ..., "Z". If we have any builds/projects which
don't start with one of these characters, they can have their own group.
Any special views, like the "PreCommit Builds" and "Most Recent Builds" can
be left alone, or moved into a "Special" nested view.

I tried to get started with an "A" group and a "B" group, but it's a lot of
tedious work.

(Note, the "A" group is a "Nested View", and the specific project views
underneath this are "List View" type. Once the first "List View" is
created, the "Nested View" it is in can be configured to have a default
view, which can be set to the first project, to make the tabs work as
expected.)

I also noticed that many views use different naming conventions and
filters. I think that can really be deferred to the individual projects,
but I found this particular pattern to work well for a stable "Regular
Expression Job Filter":
(?i)(incubator-)?projectname-.*

This filter works well if projects stick to naming builds starting with
either of the following patterns:
projectname-
incubator-projectname-

The first part is for case-insensitivity. Some projects, like "Ant" might
need a more complicated filter: (?i)(incubator-)?((easy)?ant|ivy)-.*

Honestly, I don't really care about filters that much, or how projects
choose to name their builds. Mostly, I just want predictable tabs with
stable links, so I can find and link to builds reliably, without navigating
through clutter. I just found that filter and naming convention to be
useful. There is a risk that if people don't use consistent naming
conventions, that they might lose track of builds which keep running,
taking up valuable Jenkins resources when they are no longer needed, but I
think that risk is probably pretty low unless they're not generating
notifications to their community mailing lists (or being ignored when they
are).

Thoughts?

--001a11c08c8af9926e053051d0af--