Create README.md

[jukzi]

@iloveeclipse @mickaelistria where is the CI? "All checks have passed" within <1sec. impossible.

[merks]

Note that I saw some discussions about renaming the referenced file to CONTRIBUTING.md because that's more "standard". E.g., like this one:

https://github.com/eclipse/windowbuilder/blob/master/CONTRIBUTING.md

I just thought I'd mention it so that if that were to happen, we keep it in mind...

[jukzi]

i also dislike that the Readme - or whatever name the file gets is in another project specific repository. - what is "releng.aggregator" and why should i know that repo - should i?

[iloveeclipse]

@jukzi : the CI kicks in not immediately, which confuses me a lot too, but now you should see it is running.

[mickaelistria]

GitHub usually recommends creation of a CONTRIBUTING.md file about instructions to contribute. The README is more a project presentation.

[laeubi]

@jukzi : the CI kicks in not immediately, which confuses me a lot too, but now you should see it is running.

Even at gerrit the build does not kicks in immediately so was everyone confused there too? If you like you can create an additional GH action that is most times faster to add at least a note that it was scheduled....

The eclipse-ci is simply slow and often overloaded ...

[laeubi]

GitHub usually recommends creation of a CONTRIBUTING.md file about instructions to contribute. The README is more a project presentation.

By the way you can read more about it here: https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/creating-a-default-community-health-file

[jukzi]

The difference to gerrit is that i was asked if i want to submit which should not happen until the tests verified sucessfully.

[laeubi]

The difference to gerrit is that i was asked if i want to submit which should not happen until the tests verified sucessfully.

Github asks you before submission as well anyways I assume contributors use their power to override checks with care, either with github or gerrit ...

[jukzi]

hopefully unrelated error

!ENTRY org.eclipse.core.resources 4 1 2022-03-25 09:04:20.224 !MESSAGE Internal Error !STACK 1 org.eclipse.core.internal.resources.ResourceException(/31f4888e1aac001c1866ad91bc5a5993/.project)[368]: java.lang.Exception: File not found: /tmp/570162268919/.project.

why??

[jonahgraham]

IIRC the Eclipse Foundation has disabled using github hooks to trigger builds, as a result there is a period where the merge button is green. This didn't happen on Gerrit because the verified flag needed to be +1

[iloveeclipse]

Just observed a delay of 7 minutes between PR creation and Jenkins job startup, where I was able to merge PR with "all checks are green" message. OMG. Is this our setup so bad or github in general?

[jonahgraham]

Just observed a delay of 7 minutes between PR creation and Jenkins job startup, where I was able to merge PR with "all checks are green" message. OMG. Is this our setup so bad or github in general?

If I read the Jenkins job configuration correctly it is set to poll every 10 minutes for new PRs to build. In that window you will have a green merge button. It is probably time to go back to EF and ask them about enabling hooks?

I hope the above is relevant as it was quite a few years ago that EF told me of that policy and I last setup a new jenkins job to build GitHub PRs.

[iloveeclipse]

It is probably time to go back to EF and ask them about enabling hooks?

@jonahgraham : please do. The delay of 10 minutes is too large.

[jonahgraham]

It is probably time to go back to EF and ask them about enabling hooks?

@jonahgraham : please do. The delay of 10 minutes is too large.

I'll take that as an action point - my contribution to moving the Platform to GitHub

[iloveeclipse]

@jonahgraham : thanks. Another item I miss already is the email notification on build finish. With multiple patches I'm involved in it is impossible to track the state without such notifications. This should be also done for all platform repositories.

[jonahgraham]

Another item I miss already is the email notification on build finish. With multiple patches I'm involved in it is impossible to track the state without such notifications. This should be also done for all platform repositories.

That is a whole other issue - I can look at that too as I miss it in my other repos (some eclipse-cdt-cloud ones). But with so many more github repos I agree. I can take a look at what can be done easily, otherwise I will have to leave it for others.

[mickaelistria]

Having GitHub/Jenkins hooks set up would indeed save a few minutes in the review process. However, it wouldn't prevent from merging without warning before job completion, just like Gerrit never has prevented from merging until the job had completed and voted -1. So the overall workflow is the same, Jenkins is just sometimes a few minutes longer to trigger a build from a GitHub PR than from a Gerrit review, but still the delay is not new because of GitHub and has always also/mostly depended on the build queue. I let interested people look at Gerrit reviews and measure the actual time between a patch set being pushed and the "Build Started" comments. This is sometimes a matter of hours, even with Gerrit. Overall, it's not a new problem.

About emails, I believe they'd need to be explicitly requested in the Jenkinsfile, with https://plugins.jenkins.io/email-ext/ . But better than a PR would be to have the Jenkins job commenting on the PR (so a mail notification would be emitted) with http requests like https://stackoverflow.com/questions/46382950/how-send-a-comment-in-a-github-pullrequest-from-jenkins-jenkinsfile

[jonahgraham]

Not quite, on Gerrit you need a verified +1 and code review +2 to enable the submit button. Any committer can do that +1 verified, or the bot can do it, but those scores are required to enable the submit. On github the merge button is green with all checks passed message. We can protect branches on github to disable this, but the standard github workflow does not have the granularity to allow a committer to override on a case by case basis.

[laeubi]

The point is: If I have write access to the repository I could merge a change anyways, in gerrit and in github.

If you click in github on the "files" tab you can choose to approve (+2) or request changes (-1) the PR and I think it is the responsibility of the reviewer to decide on this and check that the build passes and so on.

So if you like we can enable that at least one approving review is required to merge a PR if you like something similar like gerrit: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests

[laeubi]

It is probably time to go back to EF and ask them about enabling hooks?

@jonahgraham : please do. The delay of 10 minutes is too large.

I'll take that as an action point - my contribution to moving the Platform to GitHub

Please note that Tycho also uses a 10 minute delay and the settings reads "Periodically if not otherwise run" so at least for Tycho there seems to be another trigger as it picks up PRs relative fast (about a few seconds).

But what one should note is, that the plafrom ci has a lot of projects handle and the tycho ci only one.

So probably its not the timeout but simply a lack of resources/executors ...

[laeubi]

By the way if your are certain, you can take a look at https://ci.eclipse.org/platform/job/eclipse.platform.resources/indexing/console to see what triggered the scan...

[mickaelistria]

I think we should better have a general CONTRIBUTING.md default file see https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/creating-a-default-community-health-file

It's already there.

[jonahgraham]

It is probably time to go back to EF and ask them about enabling hooks?

I have started with a request to the helpdesk on this: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1076

Another item I miss already is the email notification on build finish.

See PR #11

---

The point is: If I have write access to the repository I could merge a change anyways, in gerrit and in github.

For me the point is that the tool should do as much of the work as possible!

By the way if your are certain, you can take a look at https://ci.eclipse.org/platform/job/eclipse.platform.resources/indexing/console to see what triggered the scan...

I am certain. Not sure why Tycho is immediate - maybe hooks enabled already?

[jonahgraham]

I am certain. Not sure why Tycho is immediate - maybe hooks enabled already?

Tycho has both Jenkins and GitHub actions building PRs. The GH Actions immediately(ish) sets "In progress — This check has started...". The Jenkins build has not been detected yet, so no view on the PR yet that it is outstanding 6 minutes after the PR was created.

[vogella]

FYI - first Github action for resources finished building before the Jenkins action even started. See https://user-images.githubusercontent.com/139910/161033905-4d2b35e8-54b8-4afc-9805-cb5b93bbc23d.png

[eclipse-releng-bot]

The Jenkins build of this PR has now completed. See details at https://ci.eclipse.org/platform/job/eclipse.platform.resources/job/PR-4/15/

[eclipse-releng-bot]

The Jenkins build of this PR has now completed. See details at https://ci.eclipse.org/platform/job/eclipse.platform.resources/job/PR-4/16/

[eclipse-releng-bot]

The Jenkins build of this PR has now completed. See details at https://ci.eclipse.org/platform/job/eclipse.platform.resources/job/PR-4/17/

[jukzi]

I think we should better have a general CONTRIBUTING.md default file see https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/creating-a-default-community-health-file and the readme should describe what is specific for this repository, e.g. what is this resource repo about, how do I build it, where are the CI jobs ...

@laeubi whats the status of that? it doesnt seem to work in the sense that for example https://github.com/eclipse-platform/eclipse.platform.text show no CONTRIBUTING.md

[laeubi]

At laest when I create an issue https://github.com/eclipse-platform/eclipse.platform.text/issues/new I see the global code of conduct+contribution guideline.

It seems README.md is not on the list of supported organztaion defaults: https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/creating-a-default-community-health-file#supported-file-types

[mickaelistria]

it doesnt seem to work in the sense that for example https://github.com/eclipse-platform/eclipse.platform.text show no CONTRIBUTING.md

It doesn't show it, but if you look for example to the link "contributing guidelines" on that page, it would link to the eclipse-platform/.github/CONTRIBUTING.md (unless repo contains one CONTRIBUTING.md). I believe the lack of visibility for organization one CONTRIBUTING.md should be reported to GitHub as an enhancement request to have it appearing on the main page of the repo, like the LICENSE or the Code of Conduct.

[jukzi]

it doesnt seem to work in the sense that for example https://github.com/eclipse-platform/eclipse.platform.text show no CONTRIBUTING.md

It doesn't show it, but if you look for example to the link "contributing guidelines" on that page, it would link to the eclipse-

There is no such "contributing guidelines" on https://github.com/eclipse-platform/eclipse.platform.text. Also the right side shows "No description, website, or topics provided." and i do not have the right to edit that.

[mickaelistria]

There is no such "contributing guidelines" on https://github.com/eclipse-platform/eclipse.platform.text. Also the right side shows "No description, website, or topics provided." and i do not have the right to edit that.

There is if you try to open an issue or a pull request. But again, it seems to be missing on the right side and I encourage you to report an issue to GitHub for that.

[jukzi]

Could merge while build is running without even getting a warning :-(

[jukzi]

regarding CONTRIBUTING.md: https://support.github.com/ticket/personal/0/1568168

[laeubi]

Could merge while build is running without even getting a warning :-(

With great power comes great responsibility, if you se the build running simply don't press the button or use https://github.com/refined-github/refined-github which has an option to "merge as soon as all checks are done"