[
https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16865543#comment-16865543
]
Jason Gerlowski edited comment on SOLR-13537 at 6/17/19 12:11 PM:
------------------------------------------------------------------
Disclaimer: I talked to Marcus about some of this already offline.
I want to second one thing that Jan and Shawn have already said: test-flakiness
definitely prevents us from doing this on a full test-run right now - the
status would be red all the time and pretty useless. So since we can't cover
tests: "What's the point?" is a reasonable question.
Personally, I think there's still value in basing a badge off of a
compile-only, or a compile+precommit Jenkins job. Compilation issues do
occasionally sneak in. Precommit failures a little more frequently. A badge
would give a way to sanity check that at-a-glance when one of us sees (e.g.) a
precommit failure locally.
bq. Since github is not the canonical source repository, and as far as I can
tell the readme is not rendered by Apache gitbox, I wonder how often our
committers would actually see it
Maybe I'm wrong, but build status badges are "just images". I would expect
them to work anywhere that our markdown gets rendered to HTML. So in that
sense they're as portable as tables, text formatting (italics, bold, etc.), or
any other markdown syntax. Unless I'm missing something at least. As far as
who gets use out of build-badges, I don't use GH much, but judging from the
number of PR's we get there, it's very popular among early contributors. So I
imagine that even if the badge was GH-only, there'd still be some value there.
Unfortunately I don't think we have any nightly or hourly precommit jobs in the
Apache jenkins. There's a job or two that just run precommit, but it looks
like it triggers on JIRA patches as well as on merged code (maybe through
Yetus?) Anyway, I don't think the precommit jobs we have now are super
meaningful, so it's tough to incorporate them into a badge.
So if we wanted a badge without creating any new Jenkins jobs for it, it'd have
to just be compilation. It's not as useful as it could be, but maybe we don't
want the perfect to get in the way of the good here. (We could also create a
precommit-only nightly job, that'd just take a bit more committer effort.)
was (Author: gerlowskija):
I want to second one thing that Jan and Shawn have already said: test-flakiness
definitely prevents us from doing this on a full test-run right now - the
status would be red all the time and pretty useless. So since we can't cover
tests: "What's the point?" is a reasonable question.
Personally, I think there's still value in basing a badge off of a
compile-only, or a compile+precommit Jenkins job. Compilation issues do
occasionally sneak in. Precommit failures a little more frequently. A badge
would give a way to sanity check that at-a-glance when one of us sees (e.g.) a
precommit failure locally.
bq. Since github is not the canonical source repository, and as far as I can
tell the readme is not rendered by Apache gitbox, I wonder how often our
committers would actually see it
Maybe I'm wrong, but build status badges are "just images". I would expect
them to work anywhere that our markdown gets rendered to HTML. So in that
sense they're as portable as tables, text formatting (italics, bold, etc.), or
any other markdown syntax. Unless I'm missing something at least. As far as
who gets use out of build-badges, I don't use GH much, but judging from the
number of PR's we get there, it's very popular among early contributors. So I
imagine that even if the badge was GH-only, there'd still be some value there.
Unfortunately I don't think we have any nightly or hourly precommit jobs in the
Apache jenkins. There's a job or two that just run precommit, but it looks
like it triggers on JIRA patches as well as on merged code (maybe through
Yetus?) Anyway, I don't think the precommit jobs we have now are super
meaningful, so it's tough to incorporate them into a badge.
So if we wanted a badge without creating any new Jenkins jobs for it, it'd have
to just be compilation. It's not as useful as it could be, but maybe we don't
want the perfect to get in the way of the good here. (We could also create a
precommit-only nightly job, that'd just take a bit more committer effort.)
> Build Status Badge in git README
> --------------------------------
>
> Key: SOLR-13537
> URL: https://issues.apache.org/jira/browse/SOLR-13537
> Project: Solr
> Issue Type: Wish
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build, documentation
> Affects Versions: master (9.0), 8.2
> Reporter: Marcus Eagan
> Priority: Trivial
> Attachments: Markdown Preview Of Build Status README.png, Simple
> Artifact Build Badge.png, Simple Artifact Build Badges.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In order to aid developers and DevOps engineers who are working in a
> git-driven ecosystem, it would be helpful to see the status builds in the
> README. This is a standard for many open source projects. I think one could
> debate whether we should have a multi-line build badge visual in the README
> because people need to know about the builds for various versions and
> platforms in the case of Lucene/Solr because it is such a large and widely
> used project, in a variety of environments. The badges not only celebrate
> that fact, they support its persistence in the future with new developers who
> look for such information instictively.
> I would recommend the active build pipelines (currently 8.x and 9.x) for each
> platform, Linux, Windows, MacOSX, and Solaris.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
