After the long delay and working with Infra, we have a nightly jenkins job that builds and pushes the docker image.
Whenever we have branch_9x and branch_9_0, etc. We can copy the job for those branches. The tags for the image default to the version of Solr being built, so it should auto-use whatever the Solr version is at that point. We can think about adding additional tags (9.0.0-SNAPSHOT -> 9.0-SNAPSHOT and 9-SNAPSHOT), but for now this is acceptable IMO. https://ci-builds.apache.org/job/Solr/job/Solr-Docker-Nightly-main/ https://hub.docker.com/r/apache/solr-nightly/tags - Houston On Wed, Sep 29, 2021 at 6:13 PM Houston Putman <[email protected]> wrote: > Got the ball rolling here: INFRA-22375 > <https://issues.apache.org/jira/browse/INFRA-22375> > > On Wed, Sep 29, 2021 at 5:43 PM David Smiley <[email protected]> wrote: > >> Okay; +1 to your proposal: apache/solr-nightly:9.0.0-SNAPSHOT >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> >> >> On Tue, Sep 7, 2021 at 11:56 AM Houston Putman <[email protected]> >> wrote: >> >>> Did you need to coordinate with Infra to create the job? I see the >>>> build machine tag is "lucene"; maybe this doesn't make sense after the >>>> project split? >>>> >>> >>> I merely copied the solr-main-check job, to create this one. I think all >>> of the Solr jobs still use the lucene boxes for now. We can go through and >>> remove the build machine tag from all of them. >>> >>> I noticed a build failure emailed today. Apparently the test >>>> "user_volume" failed. >>>> >>> >>> It seems that the setfacl command stopped being available two days after >>> creating the jenkins job, very strange.... >>> >>> RE apache/solr-nightly tag... >>> >>> >>> So I think it's good to remember that the official Solr "release" image >>> isn't going to live at *apache/solr:9.0.0*, it's going to remain an >>> official image so it'll be *solr:9.0.0*. >>> We definitely can't do the nightlies as a part of the official image, so >>> it'll have to have a different tag. To me it would be confusing if >>> *apache/solr* was that tag, since users wouldn't know whether to use >>> *apache/solr* or *solr* when searching on docker hub. I'm perfectly >>> fine not using the *-nightly* suffix, but I would prefer an easy way to >>> distinguish. >>> >>> >>> I have a separate question as well. I set up a pipeline to test the >>> official dockerfile generation as well, which should work very similarly to >>> the regular docker build and test job. The only difference is that the >>> official dockerfile generation requires a GPG key to sign the Solr >>> artifacts. Do we have a GPG key for jenkins building, or do we do any type >>> of signing in other jenkins jobs? >>> >>> - Houston >>> >>> On Mon, Sep 6, 2021 at 5:48 PM David Smiley <[email protected]> wrote: >>> >>>> Thanks so much for doing this Houston! Did you need to coordinate with >>>> Infra to create the job? I see the build machine tag is "lucene"; maybe >>>> this doesn't make sense after the project split? >>>> >>>> I noticed a build failure emailed today. Apparently the test >>>> "user_volume" failed. >>>> >>>> RE apache/solr-nightly tag... I'm not sure the "nightly" part is right >>>> because what if we want it published at other intervals? Moreover, I think >>>> the snapshot-ness of any build should be captured in the tag and not in the >>>> name of the image. So let's just do apache/solr, ehh? If users come >>>> looking for the official images, we can have a README to tell them what's >>>> going on. >>>> >>>> ~ David Smiley >>>> Apache Lucene/Solr Search Developer >>>> http://www.linkedin.com/in/davidwsmiley >>>> >>>> >>>> On Thu, Sep 2, 2021 at 4:38 PM Houston Putman <[email protected]> >>>> wrote: >>>> >>>>> For those interested we now have pipelines working to test the local >>>>> docker build as well as the building of the official dockerfile. >>>>> >>>>> https://ci-builds.apache.org/job/Solr/job/Solr-Docker-Test-main/ >>>>> >>>>> https://ci-builds.apache.org/job/Solr/job/Solr-Docker-Official-Test-main/ >>>>> >>>>> I'm not sure how to actually capture the error and log outputs that >>>>> live at solr/docker/build/test-results, so if someone wants to do that >>>>> please go ahead! >>>>> If not it should still work and people can check the jenkins workspace >>>>> to look for the logs (not ideal, but not an awful solution for now). >>>>> >>>>> I will look into getting the *apache/solr-nightly* docker tag setup >>>>> with INFRA next week and modify the jenkins pipeline to start pushing the >>>>> nightly image when the tests pass, >>>>> unless anyone objects. >>>>> >>>>> - Houston >>>>> >>>>> On Thu, Sep 2, 2021 at 12:27 PM Eric Pugh < >>>>> [email protected]> wrote: >>>>> >>>>>> I frequently want to test latest Solr as part of something larger, so >>>>>> making it easier to access would be good for me. It’s a bit of pain >>>>>> adding non-dockerhub locations, so this would be nice! >>>>>> >>>>>> >>>>>> On Sep 2, 2021, at 11:34 AM, Houston Putman <[email protected]> >>>>>> wrote: >>>>>> >>>>>> Hello all, >>>>>> >>>>>> I'm creating a Jenkins pipeline to do a daily build and test of the >>>>>> new Apache Solr docker image. (Probably both the local and the official >>>>>> image) >>>>>> >>>>>> Is there any interest in having a place on docker hub where these >>>>>> nightly docker images get published? Kind of like we have nightly maven >>>>>> and >>>>>> TGZ artifacts published? >>>>>> >>>>>> I was imagining something like apache/solr-nightly:9.0.0-SNAPSHOT, >>>>>> which is very clear in both the tag and version that it is not a released >>>>>> version of Solr. >>>>>> >>>>>> Any thoughts or opinions appreciated. >>>>>> >>>>>> - Houston >>>>>> >>>>>> >>>>>> _______________________ >>>>>> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | >>>>>> 434.466.1467 >>>>>> | http://www.opensourceconnections.com | My Free/Busy >>>>>> <http://tinyurl.com/eric-cal> >>>>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed >>>>>> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> >>>>>> This e-mail and all contents, including attachments, is considered to >>>>>> be Company Confidential unless explicitly stated otherwise, regardless >>>>>> of whether attachments are marked as such. >>>>>> >>>>>>
