mirrors/CC-Tweaked
1
0
Fork 0
mirror of https://github.com/SquidDev-CC/CC-Tweaked synced 2024-11-10 20:09:58 +00:00
Code Issues Releases Wiki Activity
7b6caf76e4
CC-Tweaked/.github/workflows/main-ci.yml

93 lines
2.1 KiB
YAML
Raw Normal View History

Goodbye Travis, I'm with GH Actions now
2019-09-27 07:56:53 +00:00
name: Build
A little experiment with GitHub actions Let's give this a go.
2019-09-14 08:16:13 +00:00
Update CI to also run on PRs
2019-09-30 14:37:52 +00:00
on: [push, pull_request]
A little experiment with GitHub actions Let's give this a go.
2019-09-14 08:16:13 +00:00
jobs:
build:
Lint bios and the rom (#321) We now use illuaminate[1]'s linting facilities to check the rom and bios.lua for a couple of common bugs and other problems. Right now this doesn't detect any especially important bugs, though it has caught lots of small things (unused variables, some noisy code). In the future, the linter will grow in scope and features, which should allow us to be stricter and catch most issues. As a fun aside, we started off with ~150 bugs, and illuaminate was able to fix all but 30 of them, which is pretty neat. [1]: https://github.com/SquidDev/illuaminate
2019-12-03 23:26:13 +00:00
name: Build
A little experiment with GitHub actions Let's give this a go.
2019-09-14 08:16:13 +00:00
runs-on: ubuntu-latest
steps:
Fix a whole bunch of GH action issues - Switch over to the Gradle GH action. Not expecting massive changes, but might provide some better caching. - Bump some GH action versions. - Fix a Java 8 compatability issue in our build scripts.
2022-10-22 20:21:33 +00:00
- name: Clone repository
uses: actions/checkout@v3
A little experiment with GitHub actions Let's give this a go.
2019-09-14 08:16:13 +00:00
Fix a whole bunch of GH action issues - Switch over to the Gradle GH action. Not expecting massive changes, but might provide some better caching. - Bump some GH action versions. - Fix a Java 8 compatability issue in our build scripts.
2022-10-22 20:21:33 +00:00
- name: Set up Java
uses: actions/setup-java@v3
A little experiment with GitHub actions Let's give this a go.
2019-09-14 08:16:13 +00:00
with:
Merge branch 'mc-1.16.x' into mc-1.18.x I dare say there's going to be some bugs with this. I was as careful as I could be, but yikes it was nasty.
2022-10-25 21:36:21 +00:00
java-version: 17
Fix a whole bunch of GH action issues - Switch over to the Gradle GH action. Not expecting massive changes, but might provide some better caching. - Bump some GH action versions. - Fix a Java 8 compatability issue in our build scripts.
2022-10-22 20:21:33 +00:00
distribution: 'temurin'
A little experiment with GitHub actions Let's give this a go.
2019-09-14 08:16:13 +00:00
Fix a whole bunch of GH action issues - Switch over to the Gradle GH action. Not expecting massive changes, but might provide some better caching. - Bump some GH action versions. - Fix a Java 8 compatability issue in our build scripts.
2022-10-22 20:21:33 +00:00
- name: Setup Gradle
uses: gradle/gradle-build-action@v2
Cache the gradle dependency cache This'll preserve the FG and general module cache. Note, this doesn't include gradle wrappers, but that's normally pretty fast to download.
2020-02-08 11:17:45 +00:00
with:
Fix a whole bunch of GH action issues - Switch over to the Gradle GH action. Not expecting massive changes, but might provide some better caching. - Bump some GH action versions. - Fix a Java 8 compatability issue in our build scripts.
2022-10-22 20:21:33 +00:00
cache-read-only: ${{ !startsWith(github.ref, 'refs/heads/mc-') }}
Cache the gradle dependency cache This'll preserve the FG and general module cache. Note, this doesn't include gradle wrappers, but that's normally pretty fast to download.
2020-02-08 11:17:45 +00:00
Add a pre commit hook to lint code This uses pre-commit [1] to check patches are well formed and run several linters on them. We currently do some boring things (check files are syntactically valid) as well as some project-specific ones: - Run illuaminate on the Lua files - Run checkstyle on Java [1]: https://pre-commit.com/
2021-04-28 20:24:27 +00:00
- name: Disable Gradle daemon
run: |
mkdir -p ~/.gradle
echo "org.gradle.daemon=false" >> ~/.gradle/gradle.properties
A little experiment with GitHub actions Let's give this a go.
2019-09-14 08:16:13 +00:00
- name: Build with Gradle
Run integration tests in-game Name a more iconic duo than @SquidDev and over-engineered test frameworks. This uses Minecraft's test core[1] plus a home-grown framework to run tests against computers in-world. The general idea is: - Build a structure in game. - Save the structure to a file. This will be spawned in every time the test is run. - Write some code which asserts the structure behaves in a particular way. This is done in Kotlin (shock, horror), as coroutines give us a nice way to run asynchronous code while still running on the main thread. As with all my testing efforts, I still haven't actually written any tests! It'd be good to go through some of the historic ones and write some tests though. Turtle block placing and computer redstone interactions are probably a good place to start. [1]: https://www.youtube.com/watch?v=vXaWOJTCYNg
2021-01-09 19:50:27 +00:00
run: |
Add a pre commit hook to lint code This uses pre-commit [1] to check patches are well formed and run several linters on them. We currently do some boring things (check files are syntactically valid) as well as some project-specific ones: - Run illuaminate on the Lua files - Run checkstyle on Java [1]: https://pre-commit.com/
2021-04-28 20:24:27 +00:00
./gradlew assemble || ./gradlew assemble
./gradlew downloadAssets || ./gradlew downloadAssets
Use a Gradle plugin to download illuaminate Previously illumainate required manual users to manually download it and place it in ./bin/. This is both inconvenient for the user, and makes it hard to ensure people are running the "right" version. We now provide a small Gradle plugin which registers illuaminate as a ependency, downloading the appropriate (now versioned!) file. This also theoretically supports Macs, though I don't have access to one to test this. This enables the following changes: - The Lua lint script has been converted to a Gradle task (./gradle lintLua). - illuaminateDocs now uses a task definition with an explicit output directory. We can now consume this output as an input to another task, and get a task dependency implicitly. - Move the pre-commit config into the root of the tree. We can now use the default GitHub action to run our hooks. - Simplify CONTRIBUTING.md a little bit. Hopefully it's less intimidating now.
2022-09-11 13:11:32 +00:00
./gradlew build
Run integration tests in-game Name a more iconic duo than @SquidDev and over-engineered test frameworks. This uses Minecraft's test core[1] plus a home-grown framework to run tests against computers in-world. The general idea is: - Build a structure in game. - Save the structure to a file. This will be spawned in every time the test is run. - Write some code which asserts the structure behaves in a particular way. This is done in Kotlin (shock, horror), as coroutines give us a nice way to run asynchronous code while still running on the main thread. As with all my testing efforts, I still haven't actually written any tests! It'd be good to go through some of the historic ones and write some tests though. Turtle block placing and computer redstone interactions are probably a good place to start. [1]: https://www.youtube.com/watch?v=vXaWOJTCYNg
2021-01-09 19:50:27 +00:00
Add a system for client-side tests (#1219) - Add a new ClientJavaExec Gradle task, which is used for client-side tests. This: - Copies the exec spec from another JavaExec task. - Sets some additional system properties to configure on gametest framework. - Runs Java inside an X framebuffer (when available), meaning we don't need to spin up a new window. We also configure this task so that only one instance can run at once, meaning we don't spawn multiple MC windows at once! - Port our 1.16 client test framework to 1.19. This is mostly the same as before, but screenshots no longer do a golden test: they /just/ write to a folder. Screenshots are compared manually afterwards. This is still pretty brittle, and there's a lot of sleeps scattered around in the code. It's not clear how well this will play on CI. - Roll our own game test loader, rather than relying on the mod loader to do it for us. This ensures that loading is consistent between platforms (we already had to do some hacks for Forge) and makes it easier to provide custom logic for loading client-only tests. - Run several client tests (namely those involving monitor rendering) against Sodium and Iris too. There's some nastiness here to set up new Loom run configurations and automatically configure Iris to use Complementary Shaders, but it's not too bad. These tests /don't/ run on CI, so it doesn't need to be as reliable.
2022-11-18 23:57:25 +00:00
- name: Run client tests
run: ./gradlew runGametestClient # Not checkClient, as no point running rendering tests.
Allow client tests to fail I give this commit a 50% chance of failing for other GH Actions related reasons. Nobody ever gets CI commits right on the first try.
2022-11-25 20:44:44 +00:00
# These are a little flaky on GH actions: its useful to run them, but don't break the build.
continue-on-error: true
Add a system for client-side tests (#1219) - Add a new ClientJavaExec Gradle task, which is used for client-side tests. This: - Copies the exec spec from another JavaExec task. - Sets some additional system properties to configure on gametest framework. - Runs Java inside an X framebuffer (when available), meaning we don't need to spin up a new window. We also configure this task so that only one instance can run at once, meaning we don't spawn multiple MC windows at once! - Port our 1.16 client test framework to 1.19. This is mostly the same as before, but screenshots no longer do a golden test: they /just/ write to a folder. Screenshots are compared manually afterwards. This is still pretty brittle, and there's a lot of sleeps scattered around in the code. It's not clear how well this will play on CI. - Roll our own game test loader, rather than relying on the mod loader to do it for us. This ensures that loading is consistent between platforms (we already had to do some hacks for Forge) and makes it easier to provide custom logic for loading client-only tests. - Run several client tests (namely those involving monitor rendering) against Sodium and Iris too. There's some nastiness here to set up new Loom run configurations and automatically configure Iris to use Complementary Shaders, but it's not too bad. These tests /don't/ run on CI, so it doesn't need to be as reliable.
2022-11-18 23:57:25 +00:00
Make builded Jar downloadable (#332)
2020-01-01 00:08:31 +00:00
- name: Upload Jar
Run core tests on Windows/OSX too We've a couple of Windows-specific tests here which I've not actually run on Windows for years. It feels worth doing properly.
2022-12-04 18:41:19 +00:00
uses: actions/upload-artifact@v3
Make builded Jar downloadable (#332)
2020-01-01 00:08:31 +00:00
with:
name: CC-Tweaked
Update project paths in our utility build scripts
2022-11-10 09:12:28 +00:00
path: projects/forge/build/libs
Make builded Jar downloadable (#332)
2020-01-01 00:08:31 +00:00
Use a Gradle plugin to download illuaminate Previously illumainate required manual users to manually download it and place it in ./bin/. This is both inconvenient for the user, and makes it hard to ensure people are running the "right" version. We now provide a small Gradle plugin which registers illuaminate as a ependency, downloading the appropriate (now versioned!) file. This also theoretically supports Macs, though I don't have access to one to test this. This enables the following changes: - The Lua lint script has been converted to a Gradle task (./gradle lintLua). - illuaminateDocs now uses a task definition with an explicit output directory. We can now consume this output as an input to another task, and get a task dependency implicitly. - Move the pre-commit config into the root of the tree. We can now use the default GitHub action to run our hooks. - Simplify CONTRIBUTING.md a little bit. Hopefully it's less intimidating now.
2022-09-11 13:11:32 +00:00
- name: Upload coverage
Run core tests on Windows/OSX too We've a couple of Windows-specific tests here which I've not actually run on Windows for years. It feels worth doing properly.
2022-12-04 18:41:19 +00:00
uses: codecov/codecov-action@v3
Add problem matchers for Github actions - Add a basic problem matcher for illuaminate errors. - Add a script (tools/parse-reports.py) which parses the XML reports generated by checkstyle and junit, extracts source locations, and emits them in a manner which can be consumed by another set of matchers. This should make it a little easier to see problems for folks who just rely on CI to test things (though also, please don't do this if you can help it).
2021-05-17 16:31:58 +00:00
- name: Parse test reports
run: ./tools/parse-reports.py
if: ${{ failure() }}
Run tests with coverage - Use jacoco for Java-side coverage. Our Java coverage is /terrible (~10%), as we only really test the core libraries. Still a good thing to track for regressions though. - mcfly now tracks Lua side coverage. This works in several stages: - Replace loadfile to include the whole path - Add a debug hook which just tracks filename->(lines->count). This is then submitted to the Java test runner. - On test completion, we emit a luacov.report.out file. As the debug hook is inserted by mcfly, this does not include any computer startup (such as loading apis, or the root of bios.lua), despite they're executed. This would be possible to do (for instance, inject a custom header into bios.lua). However, we're not actually testing any of the behaviour of startup (aside from "does it not crash"), so I'm not sure whether to include it or not. Something I'll most likely re-evaluate.
2020-05-11 14:41:39 +00:00
Add a pre commit hook to lint code This uses pre-commit [1] to check patches are well formed and run several linters on them. We currently do some boring things (check files are syntactically valid) as well as some project-specific ones: - Run illuaminate on the Lua files - Run checkstyle on Java [1]: https://pre-commit.com/
2021-04-28 20:24:27 +00:00
- name: Run linters
Use a Gradle plugin to download illuaminate Previously illumainate required manual users to manually download it and place it in ./bin/. This is both inconvenient for the user, and makes it hard to ensure people are running the "right" version. We now provide a small Gradle plugin which registers illuaminate as a ependency, downloading the appropriate (now versioned!) file. This also theoretically supports Macs, though I don't have access to one to test this. This enables the following changes: - The Lua lint script has been converted to a Gradle task (./gradle lintLua). - illuaminateDocs now uses a task definition with an explicit output directory. We can now consume this output as an input to another task, and get a task dependency implicitly. - Move the pre-commit config into the root of the tree. We can now use the default GitHub action to run our hooks. - Simplify CONTRIBUTING.md a little bit. Hopefully it's less intimidating now.
2022-09-11 13:11:32 +00:00
uses: pre-commit/action@v3.0.0
Run core tests on Windows/OSX too We've a couple of Windows-specific tests here which I've not actually run on Windows for years. It feels worth doing properly.
2022-12-04 18:41:19 +00:00
build-core:
strategy:
fail-fast: false
matrix:
include:
- name: Windows
uses: windows-latest
- name: macOS
uses: macos-latest
name: Test on ${{ matrix.name }}
runs-on: ${{ matrix.uses }}
steps:
- name: Clone repository
uses: actions/checkout@v3
- name: Set up Java
uses: actions/setup-java@v3
with:
java-version: 17
distribution: 'temurin'
- name: Setup Gradle
uses: gradle/gradle-build-action@v2
with:
cache-read-only: ${{ !startsWith(github.ref, 'refs/heads/mc-') }}
- name: Run tests
run: |
./gradlew --configure-on-demand :core:test
- name: Parse test reports
Support renaming files directly without copying/deleting In classic squid tradition: 20% code, and 80% test logic. Closes #962. Alas, whoever reported this has deleted their account, so they can't even be happy about it :(.
2022-12-04 21:59:30 +00:00
run: python3 ./tools/parse-reports.py
Run core tests on Windows/OSX too We've a couple of Windows-specific tests here which I've not actually run on Windows for years. It feels worth doing properly.
2022-12-04 18:41:19 +00:00
if: ${{ failure() }}
Reference in New Issue Copy Permalink