[don't merge] Try out Github Actions over TravisCI

[fearphage]

As a response to a comment about how TravisCI cannot handle this project's size:

coverage report can't be enabled in CI process due project size

This is an attempt to see if a more modern system has similar limitations.

[fearphage]

I'm not sure of the limits in Travis, but here are GitHub's CI limits:

• Job execution time - Each job in a workflow can run for up to 6 hours of execution time. If a job reaches this limit, the job is terminated and fails to complete.
• Workflow run time - Each workflow run is limited to 72 hours. If a workflow run reaches this limit, the workflow run is cancelled.

[JayDi85]

Github gives 2000 free minutes per month.

As example: travis CI builds eats almost 3000 minutes in august (10 mins per build). So there are no space to coverage report (well, maybe once per week only, not for every build).

[fearphage]

Of note, the Travis job is using an ancient version of Ubuntu (Trusty) that was released in 2014.

The oldest version of Ubuntu GitHub Actions support are 18.04.

Start of Travis job:

$ mvn install -DskipTests=true -Dmaven.javadoc.skip=true -B -V
Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z)
Maven home: /usr/local/maven-3.5.2
Java version: 1.8.0_151, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-oracle/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-101-generic", arch: "amd64", family: "unix"
[INFO] Scanning for projects...

Start of GitHub action:

Apache Maven 3.8.2 (ea98e05a04480131370aa0c110b8c54cf726c06f)
Maven home: /usr/share/apache-maven-3.8.2
Java version: 1.8.0_302, vendor: Temurin, runtime: /opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/8.0.302-8/x64/jre
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "5.8.0-1040-azure", arch: "amd64", family: "unix"
[INFO] Scanning for projects...

[fearphage]

Github gives 2000 free minutes per month.

Didn't see that. 😢

Is it possible to speed up the build by running tests in parallel?

[JayDi85]

For your error with miss OpenFX -- you can try to use custom distributin and download zulu package. I don't know is it workable or not.

[JayDi85]

Is it possible to speed up the build by running tests in parallel?

I think it useless for cloud. Most xmage tests are CPU limited. Maybe xmage code optimization can help to improve tests speed, but it hard to find (I'd profile it a few weeks ago and didn't find big bottlenecks).

[JayDi85]

You can build xmage under OpenJDK 11 (#6197) with additional packages after pom-file changes. Look at #6703.

[fearphage]

jdk+fx works, but a single test is failing:

[INFO] Results:
[INFO] 
Error:  Failures: 
Error:    TxtDeckImporterTest.testImportWithBlankLineAboveSideboard:25
[INFO] 
Error:  Tests run: 3620, Failures: 1, Errors: 0, Skipped: 65

I'll look into it more later.

[JayDi85]

Some tests needs database for run (e.g. game and cards related tests). Database creates on first game test run. But it hasn't been created in your use case -- due to parallel run (without tests executing order). Database creates in current folder, so there are will be two folder -- Mage.Verify/db/ for cards verify tests and Mage.Tests/db/ for other tests.

As workaround you can try to run tests by two steps (first step for single game test run -- it will create a database). Second for all tests.

[fearphage]

Even with the tests running in serial, that one test fails on line 25:

mage/Mage.Tests/src/test/java/org/mage/test/decks/importer/TxtDeckImporterTest.java

Lines 20 to 27 in a3ec680

	String[] cards = {"Plains", "Forest", "Island"};
	String[] sideboard = {"Swamp", "Mountain"};
	for (String c : cards) {
	card = CardRepository.instance.findPreferedCoreExpansionCard(c, true);
	assert card != null;
	deck.getCards().add(new DeckCardInfo(card.getName(), card.getCardNumber(), card.getSetCode()));
	}

It still seems like a data issue, but I'm not sure.

Note: The method name (findPreferedCoreExpansionCard) on line 24 is misspelled. Preferred contains three Rs.

[JayDi85]

error on assert card != null; -- so it can't find card in database... Database can be broken (due low memory -- try to increase memory usage) or it runs without database (but it strange -- other tests were finished).

[JayDi85]

Interesting. Github actions works faster (6 mins vs 9 mins).

[fearphage]

Failed to execute goal org.eluder.coveralls:coveralls-maven-plugin:4.3.0:report (default-cli) on project mage-root: I/O operation failed: No coverage report files found -> [Help 1]

I'm not sure what magic of mvn options are required from here. ¯\_(ツ)_/¯ Do I need the clean?

[JayDi85]

jacoco need prepare stages before (to injects to unit tests) and after (to generate final report -- fullest report will be in Mage.Verify). Look at travis related code, original pom file or CV issue with comments about jacoco and sonar integration.

[fearphage]

@JayDi85 This stuff is really a black box to me. Can you help me get this over the finish line?

[ldeluigi]

GitHub Actions shouldn't have computing time limitations for public repos. This means that workflow runs on this repository won't use the quota of the magefree organization

[Alex-Vasile]

I'm going to leave this here as a reference: https://github.com/nektos/act

Would be useful for getting this to work since you can run them locally (and much faster) so you get faster feedback on changes.

[fearphage]

I'm not sure what else I need to do to get this PR over the finish line. I'm not familiar with the tooling and their associated configuration.

Any help would be greatly appreciated.

[Alex-Vasile]

I'm not sure what else I need to do to get this PR over the finish line. I'm not familiar with the tooling and their associated configuration.

Any help would be greatly appreciated.

I have been asking around for help on this as well.

Unfortunately I don't know much about GitHub actions but I'll take a look and see what I can do after setting up the local environment.

[fearphage]

I don't know much about GitHub actions

I believe to fix this you need to know a lot about Java, Jacoco, Maven, and the Coveralls plugin for test coverage. These are all areas where I lack expertise. I believe all the GitHub Actions work is already done, but I'm here to pitch in from that end as needed.

[fearphage]

@Alex-Vasile Any ideas on how to get coveralls to find the appropriate test files?

[Alex-Vasile]

@Alex-Vasile Any ideas on how to get coveralls to find the appropriate test files?

I haven't look into this at all

[ldeluigi]

Coverage data can be displayed in one of these ways on GitHub Actions:

1. generate a website and publish it as build artifact with the upload-artifact action
2. send the data to a third party and use it instead of github
3. Use a badge from shields.io
4. Print it in the super-duper new feature: https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#adding-a-job-summary

[ldeluigi]

cool

[fearphage]

The coveralls service outputs coverage data as PR comments when setup correctly. Here's an example.

The problem I'm trying to resolve now is coveralls is not seeing/receiving all the current coverage data. I don't understand the ins and outs of maven and the likes so I need some help to get that resolved. That's the last piece of this puzzle.