Upload eventfile and unit test results #1389
Conversation
|
Thank you @laeubi . |
| @@ -8,6 +8,15 @@ on: | |||
| branches: '**' | |||
There was a problem hiding this comment.
one might also want to trigger this workflow on PRs...
See for example https://github.com/eclipse-platform/eclipse.platform.ui/blob/04265dec58c0fa26b5fe7360c0a6d56cf8218517/.github/workflows/ci.yml#L6-L10
There was a problem hiding this comment.
one might also want to trigger this workflow on PRs...
In a previous discussion with @rgrunber , we agreed that we don't want it at the moment, to avoid the risk of disturbing current activity on JDT, and the failure here proves it was wise to be cautious.
We may discuss enabling it for PRs later if there is a demand for it from JDT contributors; but at the moment Jenkins seems sufficient and reliable enough.
There was a problem hiding this comment.
If reporting problems is "disturbing" it might be better to delete verification checks altogether ;-)
There was a problem hiding this comment.
Jenkins does already report problems well enough. The ci.yml here is more added so that contributors can have GitHub builds on their forks for free, to validate their changes, before pushing a PR (that would then be verified on Jenkins).
There was a problem hiding this comment.
Why not upload test results from jenkins on pr as a comment?
|
Two questions from a github-naive user:
What issues would be detected by this workflow beyond what the jenkins job does? Is the original intention to run additional verification after each PR merge? For what benefit? |
|
The original intention is captured in #1254 : "an easily be used to enable validation in forks, just by enabling GitHub actions on the forked repository. So it makes it almost free for contributors to get some CI validation, and thus to provide higher quality PRs more easily." |
Sure, but what should be the result from all this here on the original repo? Should validations run before and after each PR merge?? |
The expected result here would be a GitHub build running only for branches (master and so on) when changes happen, and with a successful result. It's not meant to replace Jenkins build nor to add extra redundant checks to PR validations; nothing new happens for PRs. |
|
As mentioned in #1254 (comment) , we could have the job only run on forks (stay silent on the original repo until a migration away from Jenkins does happen) if having the additional job running becomes annoying. |
In general having run the verification on different systems/configuration gives better confidence that we are not coding against a single configuration specific setup (e.g. Jenkins uses Redhat Linux, Github uses latest Ubuntu Linux), beside that Github offers runner for Windows+Mac while Jenkins only offers Linux by default. Also from time to time we see the Jenkins instances where down, then its good to have at least the alternative verification at hand.
This is more a side-effect, without that users would have to do all the setup on their own fork with that one only needs to enable Action runs.
The only benefit is for those who don't know how to run a maven commandline. |
|
@mickaelistria @akurtakov @rgrunber @stephan-herrmann any interest in improving github actions or should we close this? |
|
If/when we get them not failing I will push them. |
akurtakov
force-pushed
the
fix_ci_workflow
branch
from
51f1363
to
1e53e12
Compare
|
Can someone with sufficient github knowledge please review this? Otherwise #1254 is due for a revert, IMHO, as we keep getting bogus error mails upon every successful merge, which in the end means that no committer will pay any attention to such mails any more. |
Everything is green... |
|
Let's have this one and see what(if anything) still annoys people after that. |
|
I've rebased #1698 to see the effects there. |
FYI @mickaelistria @stephan-herrmann