Implement a periodic workflow verifying the QS against the Quarkus master

[cescoffier]

The implemented workflow runs every 6 hours and verifies the quickstarts against the latest Quarkus (master branch). It builds the native executables using the container policy and runs native ITs.

To ease debugging and to avoid waiting for the next tick, the dispatch event is also enabled. So we can trigger the workflow by issuing a curl command as follows:

curl -X POST -H "Authorization: token $GITHUB_TOKEN" \
          -H "Accept: application/vnd.github.everest-preview+json"  \
         -H "Content-Type: application/json" \
          https://api.github.com/repos/quarkusio/quarkus-quickstarts/dispatches \
         --data '{"event_type": "internal_event"}'

The build reporting uses Github Issues. It creates, closes or adds a comment to an issue named Quickstarts Native Build failed against Quarkus Master. If the issue does not exist it creates it at the first failure. It the issue exist and the build passes, the issue is closed (with a comment). If the build still fails, a comment is added. The comment contains the SHAs of the quickstart and quarkus commits.

At the moment the STM quickstart is ignored. An issue has been found yesterday and is currently being reviewed (quarkusio/quarkus#6553).

IMPORTANT: The build takes almost 3h to run...

[cescoffier]

Forgot to mention that the workflow uses Java 8 as it does the native build.

[cescoffier]

@emmanuelbernard ^

[geoand]

Should we merge this and start getting some results?

We can always improve it if things don't go as planned

[cescoffier]

There is one thing that worries me...
The issue lookup is taking a lot of time because the main quarkus repo has a lot of issues (opened and closed). I was wondering if I should not create the issue manually, and do a lookup by id which would be much faster.

WDYT?

[geoand]

There is one thing that worries me...
The issue lookup is taking a lot of time because the main quarkus repo has a lot of issues (opened and closed). I was wondering if I should not create the issue manually, and do a lookup by id which would be much faster.

WDYT?

I agree, let's just do that instead of risk something timing out and us loosing the report completely

[cescoffier]

Also, with quarkusio/quarkus#6555, we can remove the workaround for STM.

[gsmet]

I added two very small comments.

[cescoffier]

Alright, it's now going to report on quarkusio/quarkus#6588.

[cescoffier]

The CI failed... this is exactly why we need this in because it would report this issue in quarkus.

[geoand]

I will probably copy the general idea of this in order to setup a periodic CI run of the Quarkus Platform (when the pieces are in place which they aren't yet but should be soon).

[geoand]

@cescoffier the quickstart issues should be fixed now, can you rebase the PR?

[cescoffier]

@geoand done.

raised issues have been addressed

[geoand]

@cescoffier We aren't waiting for anything else for this one right? Should we merge and have it start working?

[cescoffier]

Nothing I’m aware of.

…

On 17 Jan 2020 at 12:18 +0100, Georgios Andrianakis ***@***.***>, wrote: @cescoffier We aren't waiting for anything else for this one right? Should we merge and have it start working? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[geoand]

Merging then, thanks!