Interestingly it was SOLR-179 (Ryan M) that added the prevention of
error propagation because the idea was to start anyway and display a
webpage of the error. But it was later partially undone by SOLR-1846
(Hossman), albeit left this bit, probably by mistake -- an oversight.
Because it didn't quit
It can definitely be made more explicit, so I did that:
https://github.com/apache/solr/pull/2504 (as well as clean up some
deprecation notices)
On Thu, Jun 6, 2024 at 12:37 PM David Smiley wrote:
> I saw an entry that refers people to the Confluence page I was
> referring to. That page clearly
I saw an entry that refers people to the Confluence page I was
referring to. That page clearly instructs to delete old jobs.
On Thu, Jun 6, 2024 at 1:19 PM Houston Putman wrote:
>
> Ok, I see that in the release wizard there is an item to add new jenkins
> task for the release branch, but there
Ok, I see that in the release wizard there is an item to add new jenkins
task for the release branch, but there is not an item to remove the old
jenkins tasks.
I'll go ahead and make a PR for that.
- Houston
On Thu, Jun 6, 2024 at 8:19 AM Eric Pugh wrote:
> David, I went to look at the builds
The OWASP one succeeded. I updated some other "main" branch builds to
use JDK 21. I didn't yet touch the ones that run tests but will do
that after seeing if this round goes well. Ideally our test situation
would be in better shape :-/
On Wed, Jun 5, 2024 at 12:17 AM David Smiley wrote:
>
> We
> I recall getting a direct email to me if I contributed a
> change to a CI failure. I would like this. I would also like a dev
> list email periodically (weekly?) listing the CI job status
+1 to any effort that aims to summarize "builds@".
Even for folks that check "builds@" regularly it can b
We could add (yet) another Github workflow validation. Or maybe take
the Docker one, which looks at certain paths (including bin/solr), and
generalizes to be not just testing docker but also running BATS
integration tests. Then think of this as the "integration test"
build. The "paths" it looks
David, I went to look at the builds and the long list is rather overwhelming!
So +1 to pruning.
On 2024/06/04 19:53:14 David Smiley wrote:
> I suspect nobody was reading the conversation Eric and I were having
> on bui...@solr.apache.org; maybe because nobody looks there. Maybe we
> should neve
I think a weekly heads up would be great to have.
You mention “PR validation doesn’t run BATS tests”…. Maybe it should? We’ve
had a lot of churn in the CLI, and we’ll probably continue to have that till
10x comes out, so that would be a nice check. Plus, if we add more
integration style
Thanks Jason!
On Thu, Jun 6, 2024 at 9:02 AM Jason Gerlowski wrote:
>
> It worked! There's a PR here with the fix:
> https://github.com/apache/solr/pull/2502. Take a look when you get a
> chance and let me know what you think!
>
> (I haven't created a JIRA ticket, since it's a minor change to ou
It worked! There's a PR here with the fix:
https://github.com/apache/solr/pull/2502. Take a look when you get a
chance and let me know what you think!
(I haven't created a JIRA ticket, since it's a minor change to our
build. If anyone would prefer a JIRA ticket to document this beyond
what this
Yeah, this is definitely a pain from time to time.
For anyone who hasn't hit this, steps to reproduce are:
1. Start on a branch that has a new JAX-RS-annotated interface in
Solr's 'api' module.
2. Any gradle task that compiles SolrJ will build Solr's OpenAPI spec,
generate SolrRequest implementat
12 matches
Mail list logo