-
Notifications
You must be signed in to change notification settings - Fork 154
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
[#1630] Rearrange Gradle tasks and their dependencies #1631
[#1630] Rearrange Gradle tasks and their dependencies #1631
Conversation
Is it possible to just remove Actually the entire process is a little weird and should probably be overhauled. Maybe introduce a build everything command, and maybe add checks that the required components exist for each command else build them. For example, |
I think let's discuss this in #1630 to see what solutions we should adopt. Let's not rush into implementation yet. @gerhean Do you mind copying your comment over and to continue the discussion on #1630? |
Now that #1691 has been merged, I'm re-opening this pull request. The However, pure backend tests and systemtests do not need any of the frontend assets. |
build.gradle
Outdated
tasks.run.dependsOn('compileJava'); | ||
|
||
task systemtest(dependsOn: 'zipReport', type: Test) { | ||
task systemtest(type: 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.
This might be a separate discussion but our systemtests currently are more of an integrated pure backend test. In addition to bypassing CLI arguments (as is an issue raised in #1645), we also don't seem to have any tests for the integration of front and backend - specifically the correct replication of template.zip
files.
Should we also be doing frontend-backend integration tests in systemtests as well?
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.
specifically the correct replication of
template.zip
files.
I think this can be settled by changing ConfigSystemTest
to compare the index.html
file since right now it only compares the .json
files. Although this would require someone to 'validate' the html file each time something is changed that changes the expected html
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.
For any changes to ConfigSystemTest
, I think they are best done in a separate PR. However, if index.html
is going to be compared, the dependency on zipReport
should be added back in that PR
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.
I think they are best done in a separate PR
Yes, I agree. I think it's also okay to leave it as-is and add back the dependency if we decide to check frontend build files.
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.
I just want to say that I prefer for zipReport
to be removed completely since it is basically a convoluted way of copying files around, instead of just copying it directly to the output folder.
In my opinion the Java code should not be responsible for copying around the files. That is what gradle is supposed to be for.
Well unless it is supposed to be used as a Jar file?
In any case the index.html
file is more or less constant, I'm not sure if there is really a need to check if it is copied correctly if no changes are done to it.
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.
From what I know, zipReport
would still be needed to ensure that there is a templateZip.zip
file in src/main/resources
so that all the frontend assets in the zip file can be packaged in the jar file when running shadowJar
.
Once a release jar file is downloaded by someone, the backend code is needed to copy the frontend assets inside to the output directory. This enables viewing the report in browser. Gradle is only relevant for users who fork the entire project.
.github/workflows/integration.yml
Outdated
@@ -67,7 +67,7 @@ jobs: | |||
run: ./gradlew lintFrontend | |||
|
|||
- name: Build with Gradle | |||
run: time ./gradlew clean checkstyleMain checkstyleTest test systemTest coverage | |||
run: time ./gradlew clean checkstyleMain checkstyleTest zipReport test systemTest coverage |
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 not including zipReport
actually affect anything? If it's for the later artifact upload perhaps we should create a separate gradle task that explicitly depends on zipReport for this purpose to make it clear that the test is using a zipReport (since the behavior of the tests with and without zipReport is now different)
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.
I put this here because I thought Build preview website
may need it. Initially, zipReport would have been done as compileJava was entirely dependent on it. But in this case, with the general dependency removed, none of the tasks here would have called zipReport.
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.
Yea, it seems like a separate gradle run is done for Build preview website
. Perhaps @dcshzj could confirm that there is no dependency here between the steps.
The executionData for jacocoTestReport are at the end of build.gradle while the jacocoTestReport is configured early on in the file. This hinders any future edits to jacocoTestReport's properties. Let's consolidate executionData inside jacocoTestReport and move jacoco and jacocoTestReport to allow for systemtest and frontendTest to be detected correctly.
Closing and reopening due to |
The following links are for previewing this pull request:
|
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.
LGTM! Correct me if my understanding is wrong, but most of the line changes here are reordering to group related tasks together? The key line changes here is removing the need to run zipReport
in systemTest
and compileJava
which now allows us to run tests and system tests without building frontend.
I've tested the various tasks and it seems to work great. Thanks for doing this.
My original intention was to remove the need to run Another point of note is that for |
Now that you've mentioned it, I've edited the commit message and PR title to reflect the new changes. |
I see! thanks for the explanation. |
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.
LGTM! Looks like the CI tests run a little faster now too
The following links are for previewing this pull request:
|
Fixes #1630
Proposed commit message: