[jira] [Commented] (SOLR-13537) Build Status Badge in git README
[
https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16875482#comment-16875482
]
Jason Gerlowski commented on SOLR-13537:
I've merged Marcus' PR to master. I was thinking about copying this back to
other branches {{branch_8x}} etc, but after considering it a bit, I'm less sure
that's a good idea. {{master}} is the branch where the build-badges are most
visible. It's also the branch used most by novice developers- the ones most
likely to get use out of the build-badges. (Typically, new contributors offer
patches/PRs against master and it's up to the committer to work with other
branches from there.)
Anyway backporting the build badges to other branches offers less value, and it
also carries a bit more risk. The {{master}} build jobs will be around
indefinitely, since our branching model has us always working off of
{{master}}. Other branches aren't as "sticky" - eventually jobs for other
branches will stop running and get deleted indefinitely, so unless we're going
to remember to remove the badges later it's probably not worth adding them to
{{branch_Yx}} branches.
Unless anyone makes a good argument for porting this to other branches, I'll
close this ticket out. Thanks for the idea and the legwork Marcus.
> 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
>Assignee: Jason Gerlowski
>Priority: Trivial
> Attachments: Markdown Preview Of Build Status README.png, Simple
> Artifact Build Badge.png, Simple Artifact Build Badges.png, Single Line
> Badges.png
>
> Time Spent: 40m
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13537) Build Status Badge in git README
[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16875477#comment-16875477 ] ASF subversion and git services commented on SOLR-13537: Commit 2755f26ae4bc296a10b43e9e3486ba286136ec24 in lucene-solr's branch refs/heads/master from Marcus [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2755f26 ] SOLR-13537: Add master build-badges to README These build badges can be used by novice developers to tell at a glance whether the master branch build (compilation-only) is broken. Authored-by: Marcus Eagan > 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, Single Line > Badges.png > > Time Spent: 40m > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13537) Build Status Badge in git README
[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16870715#comment-16870715 ] Marcus Eagan commented on SOLR-13537: - Build badges won’t be dynamic in a forked repo because they point to builds on the Apache master branch. For pull requests, we only need to configure web hooks in Jenkins to kick off a build whenever a PR is opened. We cannot do that until we clean up the tests, unfortunately. Otherwise, such an addition would be a nuisance. It’s pretty easy but will need to be a bit different due to the type of this project and its test suite. Still, adding a PR appropriate CI pipeline is an effort for another PR/JIRA Issue. > 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, Single Line > Badges.png > > Time Spent: 0.5h > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] [Commented] (SOLR-13537) Build Status Badge in git README
Build badges won’t be dynamic in a forked repo because they point to builds
on the Apache master branch.
For pull requests, we only need to configure web hooks in Jenkins to kick
off a build whenever a PR is opened. We cannot do that until we clean up
the tests, unfortunately. Otherwise, such an addition would be a nuisance.
It’s pretty easy but will need to be a bit different due to the type of
this project and its test suite.
Still, that’s an effort for another PR.
On Mon, Jun 24, 2019 at 1:18 AM Jan Høydahl (JIRA) wrote:
>
> [
> https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16870695#comment-16870695
> ]
>
> Jan Høydahl commented on SOLR-13537:
>
>
> {quote}somebody forks the repo, commits changes to their fork, and the
> badge actually shows whether or not their repository compiles
> {quote}
> I have seen this done in Pull Requests. You can configure various
> validation rules including running tests, that will be required before the
> merge button will work. I.e. if they fork repo, commit some changes and
> file a PR, we should be able to configure something that is run after every
> commit to the PR. Don't know if tools like circleCI will be free for open
> source, but they are capable of running our build and precommit. Yetus does
> this for Jira patch attachments but I have not seen it doing it for PRs?
>
> > 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, Single Line
> Badges.png
> >
> > Time Spent: 0.5h
> > 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: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Marcus Eagan
[jira] [Commented] (SOLR-13537) Build Status Badge in git README
[
https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16870695#comment-16870695
]
Jan Høydahl commented on SOLR-13537:
{quote}somebody forks the repo, commits changes to their fork, and the badge
actually shows whether or not their repository compiles
{quote}
I have seen this done in Pull Requests. You can configure various validation
rules including running tests, that will be required before the merge button
will work. I.e. if they fork repo, commit some changes and file a PR, we should
be able to configure something that is run after every commit to the PR. Don't
know if tools like circleCI will be free for open source, but they are capable
of running our build and precommit. Yetus does this for Jira patch attachments
but I have not seen it doing it for PRs?
> 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, Single Line
> Badges.png
>
> Time Spent: 0.5h
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13537) Build Status Badge in git README
[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16870012#comment-16870012 ] Shawn Heisey commented on SOLR-13537: - What would be really awesome would be a badge that reflects the build status of the actual repository. As in ... somebody forks the repo, commits changes to their fork, and the badge actually shows whether or not their repository compiles. Total pipe dream, probably not really possible. > 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, Single Line > Badges.png > > Time Spent: 0.5h > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13537) Build Status Badge in git README
[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869929#comment-16869929 ] Marcus Eagan commented on SOLR-13537: - [~janhoy] Good idea Jan. I've updated the PR and added screenshot to the JIRA issue. > 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, Single Line > Badges.png > > Time Spent: 20m > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13537) Build Status Badge in git README
[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869924#comment-16869924 ] Jan Høydahl commented on SOLR-13537: I'm ok with this. Just perhaps put the badges next to each other instead of on separate lines? > 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: 20m > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13537) Build Status Badge in git README
[
https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869799#comment-16869799
]
Jason Gerlowski commented on SOLR-13537:
I'm considering committing this next week.
The build badges aren't as cool/meaningful as they could be if we had
consistently passing tests, etc. And I don't really buy that it provides any
value for DevOps engineers (all of whom would be using formal releases vetted
through other, stronger processes). But there is at least one tangible benefit
this patch offers: someone encountering a compile issue on {{master}} can look
at the README for a clue to whether their local issue is a legit problem that
the build slaves hit as well, or whether it's just a local environmental issue.
Since the risk of this change is super low, I think that's enough to make it
worth committing.
Wanted to give this one last bump in case Jan or Shawn still had doubts about
the value.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13537) Build Status Badge in git README
[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865578#comment-16865578 ] Jason Gerlowski commented on SOLR-13537: bq. If we had a way to run just plain unit tests and precommit that would be a better build state badge candidate. Missed this comment of Jan's the first time around. Mark Miller created a jira awhile back for separating out our unit and integration tests so each could be run separately (SOLR-12921). That seems like a prerequisite here. There's a lot of other good reasons to separate out our tests from one another, but this provides an additional little carrot if we want to incorporate unit tests into the badge down the road. > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13537) Build Status Badge in git README
[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865549#comment-16865549 ] Erik Hatcher commented on SOLR-13537: - Fully seconded everything you said, [~gerlowskija] Visibility to a matrix of various builds is a holy grail here, and taking the steps to get a first pass of compilation-only badges gets a useful addition to readily spot the (unusual) compilation, or precommit, failure. > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13537) Build Status Badge in git README
[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865543#comment-16865543 ] Jason Gerlowski commented on SOLR-13537: 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13537) Build Status Badge in git README
[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865229#comment-16865229 ] Marcus Eagan commented on SOLR-13537: - [~elyograg] I was using the Solr artifact so I put it in the Solr Jira. I've now added the Lucene artifact. So would it be appropriate for either, or default to Lucene? More committers in the future could be using GitHub a lot more. That is a reasonable assumption that I made. One of my initial motivations was to inspire others to dig into why things were red. I do not think there's any reputation problem at risk here. Many projects are often red. There have been instances, though infrequently, where Lucene did not compile. Those builds would have been red, but usually Solr is green. It's almost always green for that task. Perfect world the tests pass when they should and fail when they should not. > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13537) Build Status Badge in git README
[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864826#comment-16864826 ] Shawn Heisey commented on SOLR-13537: - Does the badge reflect the build only or the build+tests? I don't think it would be all that useful with the build only, and with the current state of Solr tests, build+tests would be red a large percentage of the time. That could cause a reputation problem for the project ... although it could be argued that's a plus, as it might be a strong motivation to make things better. The idea proposed by [~janhoy] where we report on a build running a smaller subset of tests (at least until Solr's full integration tests improve) sounds good. I think that's the only way this would be helpful right now. We have people diligently working on improving the Solr tests so they don't fail constantly, but it's a huge task, and isn't going to be completed quickly. I wish I had enough free time available to help with that. Unless I'm mistaken, I think the badge would only show up on github. 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. As Jan says, the information is not all that useful to anyone who is not working in the code, and because of the state of Solr tests, I have doubts that it would be useful to those of us who are working in the code. Down the road, I do think it's a great idea, but right now, I'm not sure it is. Consider this a -0 vote. Side note: This probably belongs in LUCENE, not SOLR. > 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 > > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13537) Build Status Badge in git README
[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864642#comment-16864642 ] Marcus Eagan commented on SOLR-13537: - [~janhoy] I don't know if you saw, but I added a new badge and screenshot using a different build rather than the flaky ones. > 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 > > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13537) Build Status Badge in git README
[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864413#comment-16864413 ] Jan Høydahl commented on SOLR-13537: I’m not sure how useful this is? What would it mean to a casual user or sevOps if the badge is red? Or green? Since our tests are advanced integration tests, they go up and down every second day, and we have a bunch of known flaky tests. Lucene devs know this and look at the last N test runs to judge quality of the code. If we had a way to run just plain unit tests and precommit that would be a better build state badge candidate. > 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 > > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13537) Build Status Badge in git README
[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864185#comment-16864185 ] Marcus Eagan commented on SOLR-13537: - I added a new screenshot to reflect how it would look in the future. I changed the build badge based on comments from some members of the Solr team. > 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 > > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
