Add GitHub Actions for CI

[jamezp]

https://issues.redhat.com/browse/RESTEASY-2561
https://issues.redhat.com/browse/RESTEASY-2564

The first commit fixes tests to work on multiple environments.

The second change adds a GitHub Action and ignores the MicroProfile TCK for Windows

The third commit uses a default 10 second delay when stopping the SunHttpJaxrsServer. This only delays 10 seconds if the server has not successfully stopped in that delay.

[liweinan]

cool :-)

[jamezp]

The failure is a timing issue. It wasn't failing for me on my job runs. It's something we should look at though at some point as timing assumptions are bad in unit/integration tests IMO.

[jamezp]

In the workflow I added continue-on-error: true which allows the other jobs to keep running if one of them fails. However since the other jobs are likely to finish later the action shows the run as passed which means you can't manually re-run the job. Will this be an issue?

[ronsigal]

timing assumptions are bad in unit/integration

One of the reasons the Remoting 2 testsuite took about 5 hours. ;-)

[ronsigal]

Hi @jamezp,

since the other jobs are likely to finish later the action shows the run as passed which means you can't manually re-run the job. Will this be an issue?

I'm not following, probably because I don't know anything about Github Actions. But do you mean we would have to do something nasty like push a bogus commit to get the tests to run again?

[jamezp]

Hi @jamezp,

since the other jobs are likely to finish later the action shows the run as passed which means you can't manually re-run the job. Will this be an issue?

I'm not following, probably because I don't know anything about Github Actions. But do you mean we would have to do something nasty like push a bogus commit to get the tests to run again?

If we want to keep the continue-on-error: true setting yes. If we remove that or set it to false by default then once a job fails all other jobs are stopped and you can restart all jobs. Kind of weird really and hopefully they'll have a solution for that at some point.

[jamezp]

Ah I may have a solution for the continue-on-error issue. I guess it's a good time to test it :)

[liweinan]

looks great!

[asoldano]

@jamezp this looks great. I think I'll merge this, I'm only thinking if/how/when to get rid of the Travis runs. What seems to be missing compared to the Travis CI runs is:

• Javadoc build
• Testing against multiple containers
• Elytron testing
  Do you think we can add do anything for that ?

[asoldano]

As an interim solution, we could get rid of the travis run that's duplicated by one of the new github action runs.

[jamezp]

@asoldano Yes we can add any combination of those. We could either use a matrix if we want to add these options or we could just add a separate workflow for specific features.

[jamezp]

@asoldano Do we want to test the different WildFly version on both OS's? I ask because if we do that we end up with 10 jobs ran per PR. Maybe that's not a huge deal, but just wondering.

I guess either way it would be 8 jobs.

[jamezp]

Okay updated to run JavaDoc builds against Java 8 and 11 on Linux, plus the different versions of WildFly

[jamezp]

The failures seem to be kind of random. I have learned only those with permissions can restart the workflow run so I can't restart it.

[liweinan]

@jamezp yes there are random failures in tests currently.
@asoldano Maybe we can fix them in future gradually.

[jamezp]

@asoldano @liweinan @ronsigal This should now be ready and duplicates what we're doing in TravisCI. It also archives the surefire reports and server.log's for each job in case they need to be inspected when failures occur.

If this looks okay I'll back port this to 4.5 and 3.12 as well. I believe those are the working branches at least. If not let me know which branches it would need to be on.

[liweinan]

@jamezp +1 from my side

[asoldano]

Great, I'm merging this, thanks @jamezp