[RelEng] Add reusable verifyFreezePeriode workflow

[HannesWell]

This PR moves the Freeze-Period verification from the Jenkins build to a dedicated reusable workflow to get more detailed/clear PR checks as I have suggested on the Mailing-Lists.

All repositories that require the code-freeze check can add the following file named .github/workflows/verifyFreezePeriod.yml:

# This workflow calls the Code-Freeze-Period check

name: Check Code Freeze Period

on:
  pull_request:
    branches: 
     - 'master'

jobs:
  check-freeze-period:
    uses: eclipse-platform/eclipse.platform.releng/.github/workflows/verifyFreezePeriod.yml@master

And can remove remove the Check freeze period stage from their Jenkins file.

The only problem at the moment is, although the calendar is publicly readable, querying the Google Calendar-API requires an authentication for example via the Google-API-Key that is used with the current verifyFreezePeriod.sh script:
https://developers.google.com/calendar/api/guides/auth
https://developers.google.com/calendar/api/v3/reference/events/list

So we either have to store Foundations Google-API-Key in the GitHub organization's secret store or have to avoid using the calendar-API.
I have never worked before with the Google-Calendar API and calenders in general and know almost nothing about it.
But this StackOverflow answer suggest to fetch the data through ical/xml/html:
https://stackoverflow.com/a/18303697

However the following link returns a basic.ics file with over 20.000 lines and events going back to 2007:
https://calendar.google.com/calendar/ical/prfk26fdmpru1mptlb06p0jh4s%40group.calendar.google.com/public/basic.ics

Maybe this can searched with a more sophisticated RegEx, but I think there might be better solutions.

Can anybody, who is more proficient in this area, help in this regard.

[sravanlakkimsetti]

@mickaelistria Can you please take a look at this one? I believe this is a good idea. Can we get the api keys added to the organization?

Since this is common across all the repos I suggest this actions to be added to our common organizational repository https://github.com/eclipse-platform/.github

[HannesWell]

Alternatively this could be implemented like the eca-check. I'm not aware how this is done exactly, but it seems to be some kind of web-service that is queried by a dedicated status-check. When I click on the details I'm directed to the ECA Validation Service of Eclipse. Something similiar could be done to check if Eclipse-Platform is currently in a code-freeze period. This way the credentials could remain on the server and the service would just have to answer with yes/no.

[mickaelistria]

IMO, it's really worth getting rid of the API token, and fetching the XML or ICS file and processing it.
However, those files are not really easy to query, so maybe the best approach would be to process it with some script (using bash, python, jshell, quarkus, whatever...).

[HannesWell]

IMO, it's really worth getting rid of the API token, and fetching the XML or ICS file and processing it. However, those files are not really easy to query, so maybe the best approach would be to process it with some script (using bash, python, jshell, quarkus, whatever...).

Or I could create a custom action written in Java, just like for example Oracle does for their Setup-Java action:
https://github.com/oracle-actions/setup-java/blob/main/action.yml

This has the advantage that I'm way more proficient in Java than any of the languages you mentioned and this would also allow read the file's content from an InputStream, so the calendar file would only be transferred partially to the current date. Downloading half a Megabyte for each freeze-check is IMHO too much for this simple yes/no question.

[mickaelistria]

My opinion here is "whatever works with public access. Thinking more about it, the HTML calendar can have options to only show the current day. So, if weal manage to get a good URL to show only current day, some wget <URL> | grep Stabilization may be enough.

[HannesWell]

My opinion here is "whatever works with public access. Thinking more about it, the HTML calendar can have options to only show the current day. So, if weal manage to get a good URL to show only current day, some wget <URL> | grep Stabilization may be enough.

With a lot of try and error and searching multiple forums I managed to find a good URL that fits our needs based on htmlembed using the mode=AGENDA and the dates parameter available with it. The latter parameter seems to have the same effect like timeMin and timeMax in the calendar-v3 API (except that it only accepts whole days, but I think this is fine).

It would be nice to display a descriptive text about the result of the check directly at the corresponding item in the list of performed checks which is displayed for a PR, but I did not figure out how to set that from a workflow. So at the moment the check is only displayed as failed or passed and if one wants a message he/she has to click on the details to see the message.

An individual descriptions like for the ECA-check would be nice to have:

@mickaelistria or @sravanlakkimsetti do you know if and how this could be done from a workflow or is this only available for bots/apps? Maybe @laeubi or @jonahgraham know this immediately?

Besides this cosmetic imperfection I think this is ready to be used.

The last question is: Are you sure this is the right repository for workflows reused by other Eclipse-Project repos?
From the naming eclipse-platform/eclipse.platform.releng.buildtools could also be a suitable repo.
I'm just asking explicitly because, if we later find that it should be moved to another place or that the file should have another name it has to be adjusted in each calling repo. So the full name should be chosen wisely, because correcting it requires some work and reusable workflows cannot call other workflows.
On the other hand the content of the workflow only needs to be adjusted here and has effect for all callers. So subsequent fixes in this regard are easy.

In general I think in the future more reusable workflows could follow.

[laeubi]

Are you sure this is the right repository for workflows reused by other Eclipse-Project repos?

I think the most suitable place would be https://github.com/eclipse-cbi instead.

do you know if and how this could be done from a workflow or is this only available for bots/apps?

I think you need to write an action for this (that could then be used in a workflow) e.g. the https://github.com/EnricoMi/publish-unit-test-result-action also adds the number of failed tests there. But I think this is really not needed for a first

[sravanlakkimsetti]

Are you sure this is the right repository for workflows reused by other Eclipse-Project repos?

I think the most suitable place would be https://github.com/eclipse-cbi instead.

We do have separate calendar for platform to manage so it in specific to platform project. So we should have this in one of our repositories. We have multiple options here

• .github - has all the common things across all repositories
• eclipse.platform.build.tools - Contains tools required for generating reports and publishing those reports during a build sparingly modified
• eclipse.platform.releng - Contains all the necessary product definitions feature definitions used for platform build. Also has maven publishing scripts
• eclipse.platform.releng.aggregator - repository to hold links to other sourcecode repos and necessary shell/ant scripts to build eclipse platform

These 4 are the best locations to hold necessary code for this task. I do prefer .github since it will be used by all platform repos.
@mickaelistria what do you think?

[laeubi]

We do have separate calendar for platform to manage so it in specific to platform project.

Then the calendar should be a parameter for the workflow/action

[laeubi]

t would be nice to display a descriptive text about the result of the check directly at the corresponding item in the list of performed checks which is displayed for a PR, but I did not figure out how to set that from a workflow.

Maybe this would be better suited to be an Action? It could be a simple JavaScript action:
https://docs.github.com/en/actions/creating-actions/creating-a-javascript-action

or if you need the power of an OS a docker action:
https://docs.github.com/en/actions/creating-actions/creating-a-docker-container-action

[mickaelistria]

With a lot of try and error and searching multiple forums I managed to find a good URL that fits our needs based on htmlembed using the mode=AGENDA and the dates parameter available with it. The latter parameter seems to have the same effect like timeMin and timeMax in the calendar-v3 API (except that it only accepts whole days, but I think this is fine).

Awesome finding! Besides this cosmetic imperfection I think this is ready to be used. How to enable it on all repos concretely? Adding a verifyFreeze.yaml to all repos?

The last question is: Are you sure this is the right repository for workflows reused by other Eclipse-Project repos? From the naming eclipse-platform/eclipse.platform.releng.buildtools could also be a suitable repo.

Yes, maybe. What about https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/tree/master/scripts ?

[HannesWell]

do you know if and how this could be done from a workflow or is this only available for bots/apps?

I think you need to write an action for this (that could then be used in a workflow) e.g. the https://github.com/EnricoMi/publish-unit-test-result-action also adds the number of failed tests there. But I think this is really not needed for a first

Thank you Christoph for the links. Looks like this cannot be done by a magic echo in the bash.
So I agree that the current state is sufficient for a first attempt, especially since I don't want to learn JavaScript just for this now. 😅
But because this is based on a reusable workflow that should be referenced by other repos this can be easily improved subsequently if somebody else wants to step into this. :)

We do have separate calendar for platform to manage so it in specific to platform project. So we should have this in one of our repositories. We have multiple options here

* .github                                            -  has all the common things across all repositories

Isn't the calendar, besides Platform also used for JDT, PDE and Equinox? At least its title indicates this:

Because I also want to reference the reusable workflow in JDT, PDE and Equinox I think eclipse-platform/.github is not the best place for it. Especially because it does not automagically apply the workflow to all repos of this organization just because it is defined in the .github repo (although it would be handy).

@laeubi suggestion (https://github.com/eclipse-cbi) looks also very suitable.
Especially if we later want to create custom GH actions that are used in the build/PRs across multiple Eclipse-projects it seems suitable to place them there, (as it is often required or at least best practice to have one repo per action).
Then we could also place reusable workflows there. On the other hand this workflow in particular is actually only useful for the Eclipse-Platform Projects (Platform, JDT, PDE and Equinox) and not for others (e.g. m2e or tycho, etc.).

With that in mind eclipse.platform.releng.aggregator seems to be a good location because it is somehow the umbrella over the projects affected by this.
However I think @mickaelistria suggestion to place it in eclipse.platform.releng.aggregator/scripts is not feasible because it looks like the rule to place workflows in ./.github/workflows/ also applies for re-used workflows.

[HannesWell]

Awesome finding!

Thanks!

How to enable it on all repos concretely? Adding a verifyFreeze.yaml to all repos?

Exactly and this verifyFreeze.yaml then always just calls the created reusable workflow, as I have written in the second paragraph of my initial-post :) The path then has to be adjusted to the final location of the reusable workflow file.

[mickaelistria]

So eclipse.platform.releng.aggregator/.github/workflows then?

[HannesWell]

So eclipse.platform.releng.aggregator/.github/workflows then?

If the others find this suitable, too, then yes.

[mickaelistria]

Then please move to the eclipse.platform.releng.aggregator, and we'll merge it just after M1 is done.

[HannesWell]

Then please move to the eclipse.platform.releng.aggregator, and we'll merge it just after M1 is done.

Done with eclipse-platform/eclipse.platform.releng.aggregator#206

I'll abandon this PR because I think adding a simple workflow that calles the reusable one should be done in a separate change.