Add github workflow to automatically test PRs and commits on github

[Ayowel]

trafficstars

This workflow automatically builds AsciidocFX when a new PR is issued. I added an install4j job but unfortunately could not test it. I will be adding unit tests when creating future PRs for asciidocfx#519 and thought that having direct feedback on the build's status from within Github without forcing each fork to setup its own CI could prove usefull.

See https://github.com/Ayowel/AsciidocFX/pull and https://github.com/Ayowel/AsciidocFX/actions for a build example

[rahmanusta]

Currently we are using travis ci, but we can move to github workflow.

• Workflow should support
• • Compiling, running tests
• • Building runnable artifacts for Mac, Windows and Linux
• • • Currently, we are using install4j (I can share with you the license key), it is free for open-source projects, but we can consider to use jpackage

[Ayowel]

* * Compiling, running tests

Supported, as can be seen in the PR

* * Building runnable artifacts for Mac, Windows and Linux

Should be supported as install4J builds cross-platform. I need to test it though.

* * * Currently, we are using install4j (I can share with you the license key), it is free for open-source projects, but we can consider to use jpackage

Jpackage does not build cross-platform and github does not provide a windows execution environment, so not really an option :/

---

I had more thought of this as a bonus for development/integration rather than a replacement for travis. Looking at the travis file, what is needed:

For maintainance:

• [X] Compile code
• [X] Test code
• [X] Publish/share test metrics (codecov)
• [X] Build cross-platform installers (might already work, to test)

For releases:

• [X] Pushing to S3 ? (with https://github.com/marketplace/actions/s3-sync - I will probably need your help when i get there)
• [X] Creating new releases ? (with https://github.com/marketplace/actions/gh-release and/or https://github.com/marketplace/actions/release-drafter)

[Ayowel]

@rahmanusta I am at a point where I need a licence key to continue. How do you want to send it ? To avoid notification spam, I'm working on a different branch on my fork (feature/github-workflow-release) and will merge once the workflow is ready

[rahmanusta]

@rahmanusta I am at a point where I need a licence key to continue. How do you want to send it ? To avoid notification spam, I'm working on a different branch on my fork (feature/github-workflow-release) and will merge once the workflow is ready

Can you reach me out an email and I’ll send you the license key? My email: [email protected]

[Ayowel]

Can you reach me out an email and I’ll send you the license key? My email: [email protected]

Done, The mail's title is [AsciidocFX] install4J license key, sent at 22:21 GMT+0

Jpackage does not build cross-platform and github does not provide a windows execution environment, so not really an option :/

Looks like I lied https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources . Moving to Jpackage might be feasible, albeit somewhat tricky. I probably won't even try.

[Ayowel]

This should be it.

As discussed via mail

• There is a single workflow with two builds
  • The workflow can be started from github's web interface (if the tracked/main branch is one contains the workflow file)
  • The first build runs on each push/PR, executes the tests (if any), and pushes the results to codecov (free and automatically available for public projects)
  • The second build runs on each tag or after being configured for a run in the web interface and creates a release draft - it requires the configuration of github secrets
• The changelog's format moved from asciidoc to markdown to provide better integration with github's release description format

Configuration

Create an install4j secret environment in github and configure the following secrets:

• INSTALL4J_SIGNING_KEY: The base64 signing key to use for mac releases
• MAC_KEYSTORE_KEY: The password of the signing key (if any)
• INSTALL4J_LICENSE_KEY: The install4j license key to use
• AWS_S3_BUCKET
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• AWS_REGION

Additional notes

• The release process generates no-JRE builds again. This was dropped without explanation when updating to install4j 8 in 7e2fa00e6d7a35430596220be80ccf8185d3afff
• Updated install4j to use 9.0.4 instead of 9.0.2 (this is now a build parameter so that updates can be more easily tested/used)
• install4j's configuration now uses local versionless paths by default when looking for resources
• Files that appeared to be unused have been removed, if some are useful do tell me so that I revert the change:
  • .travis.yml (superseded by .github/workflows/maven.yml)
  • code_sign.p12.enc is now provided as a github secret (INSTALL4J_SIGNING_KEY)
  • MODULES.adoc unused in the repository. Added with java12 and updated when preparing release 1.7.4 (test/debug artifact ?)
  • index.html was redundant with index.adoc and does not seem to be used
  • install-jdk.sh added in d41689c264f66bbb00422a41fbb2f8b52e708eb9 for no apparent reason and unused in the repository (test/debug artifact ?)