Build and deploy with GitHub Actions

[beatngu13]

To be discussed in tomorrow's innovations meeting.

[modulo11]

Can't we use the same wildcard directly in L50?

[beatngu13]

Not that I know … did some research and found this issue:

actions/upload-release-asset#4

Maintainer (@IAmHughes) suggests this approach.

[modulo11]

I like the approach and only have some minor requests:

• No need to use multiline when just one command is executed
• What about matrix builds?
• Test with and without caching the .m2 folder
• Supply a way to externally change maven args e.g. via env variables like in the travis builds
• Is there a neat way to upload to S3?

[beatngu13]

I like the approach and only have some minor requests:

• No need to use multiline when just one command is executed

This is from official examples like here:

https://github.com/actions/cache/blob/master/examples.md#java---maven

While multiline is indeed not needed, I think it is a bit more readable. But I don't really care as long as it is consistent.

• What about matrix builds?

Supported, but we currently don't need them?

• Test with and without caching the .m2 folder

Hmmm, why? It is already there and faster since we don't have to pull all dependencies all the time?

• Supply a way to externally change maven args e.g. via env variables like in the travis builds

We can use secrets for this.

• Is there a neat way to upload to S3?

There seem to be a bunch of actions, but for what do we need it here?

[enesoezel]

I still have my github actions workflow from the presentation four months ago. I especially wanted to point out the asset upload, because it could be very useful for us in terms of downloading the golden master. Here starting at line 43.

[beatngu13]

@oezelenes thx for pointing to actions/upload-artifact. I don't think it helps in the case of recheck.cli, but may be helpful when it comes to uploading test artifacts such as GMs or the like.

[beatngu13]

@modulo11 without caching requires 30 – 40 s more:

https://github.com/retest/recheck.cli/actions/runs/67976320

[diba1013]

1. What about matrix builds?

   Supported, but we currently don't need them?

   Since we do not ship a JDK currently, at least java 8 and 14? (e.g. my workflow)

2. Supply a way to externally change maven args e.g. via env variables like in the travis builds

   We can use secrets for this.

   Do we still want to do this? If yes, do we need to distinguish build and deploy?

[beatngu13]

Since we do not ship a JDK currently, at least java 8 and 14? (e.g. my workflow)

Java 14 and SonarCloud currently don't mix well (see e.g. here). We could run the analysis only if Java 8 is being used, however, we didn't do this with Travis either. The PR, as it is, is functionally equivalent with what we had before. Therefore, I would suggest to consider a build matrix in a separate step.

Do we still want to do this? If yes, do we need to distinguish build and deploy?

I would experiment with it over time and leave it as it is. It feels to me that using secrets for this purpose is not the right thing to do, but I can't come up with an alternative. Also, in Travis we were using environment variables as well, which are very similar (one could select visibility and they are not encrypted by default).

[diba1013]

Ok, let's try it out.

Please be sure to update the branch protection rules before merging this. Mergify potentially needs a refresh afterwards.

[beatngu13]

@Mergifyio refresh

[mergify]

Command refresh: success