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) <j...@apache.org> wrote: > > [ > https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
