Thanks for bringing this up. I get the appeal of consolidating things on GitHub, but I have to be -1 on this for now. To be honest, GHA's reporting just isn't quite there for me yet. Digging through logs in Jenkins is so much easier, and the test reports are much more readable at a glance. A huge dealbreaker for me right now is how it affects my AI tooling. I rely on an AI coding agent, and the Jenkins MCP server is a lifesaver, it feeds the exact build failure reason directly to the agent. GitHub doesn't have a native way to do this. Furthermore our GH build matrix is so massive, trying to get those results without an MCP server means the agent has to scrape GH using a messy mix of CLI commands and HTTP calls. It completely bloats the context window.
On Tue, 2 Jun 2026 at 05:30, Slawomir Jaranowski <[email protected]> wrote: > > Hi, > > I see that many of our jobs at Jenkins [1] are unstable ... To be fair to Jenkins, that dashboard is a little harsh! It flags a job as unstable if *any* PR or branch is acting up. Since we have so many repos with old or dead branches, our overall health looks a lot worse than it actually is or at least this mean we should cleanup dead branches maybe. > Looks like software on jenkins agents are not updated without a > separate issue for the infra team. > Examples jenkins use > - Maven 3.9.11 - there is 3.9.16, > - JDK 11 in version 11.0.24 - there is 11.0.31 > and so on ... Honestly, do we really need to chase every single patch release for CI? (at least this is available with GHA) I doubt most developers out there are updating their local JDKs or Maven installs the second a new patch drops (I know I'm not! Are you? :)). Testing on slightly older patches still reflects real-world usage pretty accurately. > > We use Jenkins to deploy a snapshot version of projects and publish > content for the main site. > > Jenkins can not be used for verification of PR from fork repo. > Jenkins build status requires authorization. > True, but GitHub Actions isn't completely frictionless either. We still have to manually approve workflows for external contributors. With Jenkins, we just sidestepped the issue by not building external forks at all. > We have more of our builds on GitHub with PR verification. > We have some automation jobs implemented on GitHub actions [2] > It looks like ATR [3] is also based on GitHub actions. > ATR is for release. Do you really plan to release from a GHA? Personally, I will never upload my key anywhere. So I'm not sure to understand how this is related to Jenkins or GHA? As far as I can understand, there will be a Maven plugin for ATR > So I would like to start discussion about switching all CI jobs to > GitHub Actions. > > It will be easier to maintain one environment. > > Next step we can ask infra for dedicated GitHub runners instead of > Jenkins runners to increase stability. > > [1] https://ci-maven.apache.org/job/Maven/job/maven-box/ > [2] https://github.com/apache/maven-gh-actions-shared > [3] https://release-test.apache.org/ > > -- > Sławomir Jaranowski > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
