-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build(ci): Basic Gradle workflow to build on Github #5134
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
further extracting jobs (if desired) can be done as a follow-up
- name: Unit Tests | ||
run: ./gradlew unitTest | ||
- name: API Documentation | ||
run: ./gradlew javadoc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would it make sense to extract those into dedicated jobs, too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm, if we get the job dependencies with reuse going then yes, otherwise I would not blow up the job count as this job with multiple steps is still faster than the other two…
- name: Static Code Analysis | ||
run: ./gradlew check -x test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would it make sense to split into mandatory (checkstyle) and not mandatory (spotbugs, pmd) ones here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could - depends a bit on what we want to see in Github and/or how we view the build results.
Currently, we're more interested in the binary ❌ / ✔️ than anything else
At least locally, the integration tests were successful with cf0d2ae |
Hm, I have no clue about the failing tests 😔 In https://github.com/MovingBlocks/Terasology/actions/runs/6066596499/job/16457362691?pr=5134
In https://github.com/MovingBlocks/Terasology/actions/runs/6066441235/job/16457033053
In https://github.com/MovingBlocks/Terasology/actions/runs/6066440639/job/16457031736
|
|
Jenkins is working at the moment, so I don't think we have a need to get this merged. Two different pipelines at the same time don't make much sense, thus, closing this PR. |
Contains
A Github workflow to build, test, and analyze the code.
Uses Gradle Build Scans for reporting, see https://docs.gradle.com/enterprise/gradle-plugin/#connecting_to_scans_gradle_com (automatically accepted for CI runs, but no for local runs).
How to test
gradlew distForLauncher --scan
still prompts for user agreementCurrently the
integration-test
step is failing with varying test cases, while they are working on Jenkins…Additional Tasks