Another advantage I see from GH Actions: it provides instant feedback to
those who do not contribute regularly and know their way around in ASF
infra. Especially for first-time contributors, it's good to see fast
feedback on their contribution.
For me, it feels like I'm wasting my time to later run the same checks
on ASF infra. I know it's what we currently do, and I'll stick with what
we agreed upon (AFAIK), but I'm not a fan of it.
Regarding toolchains: I think (never proved it, though) that we could
make toolchains work on GH Actions, too. I'm not sure what exactly we
need, but I think we could always update toolchains.xml with some shell
script before we run a build. However, more recent versions of Maven
(3.6.2 and up) have MNG-6665 [1] included which even allows the use of
environment variables in toolchains.xml.
Thanks,
Maarten
[1] https://issues.apache.org/jira/browse/MNG-6665
On 04/07/2022 13:23, Slawomir Jaranowski wrote:
Hi,
advantages GH
- build PR from external forks
- mac OS
- re-run only failed jobs
- shared actions - code in one place
disadvantages - space to improvement GH
- need build matrix with many maven versions - fix in our shared action
- there are no reports of tests for build, can be implemented [1]
- there are no reports history
- there is no toolchains support, or I don't know
So summarized, It can be a good way for verifying PR and branches, jenkins
will only build and deploy default branches.
Jenkins will still be used for deployment snapshots until we are sure of
secure store and process tokens for repository.
[1]
https://github.blog/2022-05-09-supercharging-github-actions-with-job-summaries/
pon., 4 lip 2022 o 11:58 Karl Heinz Marbaise <khmarba...@gmx.de> napisał(a):
Hi,
agree on the whole story here.
Kind regards
Karl Heinz Marbaise
On 02.07.22 21:41, Tamás Cservenák wrote:
Howdy,
I'd like to spin a discussion about the ASF Maven Jenkins instance.
As you know, ASF Infra operates one separate instance of Jenkins only for
Maven related projects. Still, aside this being a chore for INFRA, it
does
have quite some shortcomings:
- lack of all needed OS-es (has linux and windows nodes only)
- regular (lately more often) issues with windows nodea (like post build
workspace cleanup and others). But really, like 1 out of 3 fails due to
some windows node issue.
In short, it does not give us needed coverage, plus regularly generates
false negatives (red X) for PRs and master builds.
OTOH, GH Actions proved very usable, quick, has macOS and in general
fast.
Still, GH Actions cannot deploy snapshots to repository.a.o, nor is
something we'd want (see last npmjs token leakage).
Currently we have this "duality" of CI, and almost always one has to
check
why a job failed, and MANY times it fails due Jenkins non-build related
issues (usually on Windows nodes).
Hence, I'd propose something along those lines:
- "scale down" Jenkins, keep linux nodes only, and make it "deploy" only
(preferably of master branch commits only)
- hence Jenkins would "loose" CI title, it would be just "deployer" to
repository.a.o
- use GH Actions for running tests on PRs and master branches and rely on
its results on GH UI
This would give us (and ASF INFRA) benefit of:
- the maintained instance becomes way simpler, linux only (ASF INFRA)
- PR and master CI results come in way faster
- no more (well, GH Actions has outages as well, but less) false
negatives
WDYT?
T
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
