[ci] Skip license check during test as shallow clone doesn't have eno… #529
Conversation
…ugh data for that
| @@ -44,7 +44,7 @@ jobs: | |||
| key: ${{ matrix.os }}-m2-${{ hashFiles('**/pom.xml') }} | |||
| restore-keys: ${{ matrix.os }}-m2 | |||
| - name: Build with Maven | |||
| run: mvn -B -V -e "-Dstyle.color=always" verify | |||
| run: mvn -B -V -e "-Dstyle.color=always" verify -D"license.skip=true" | |||
There was a problem hiding this comment.
I think it's really important that CI check to verify files are properly licensed. There probably wouldn't be errors if we dropped license-maven-plugin-git, since as far as I can tell, that's only used to populate a few optional copyright fields that might be used inside the license header template... but we have no reference to any of those variables in our license header template.
This reverts the change in #529 and restores the processing of licenses as part of CI tasks. However, drop the optional processing of git information to populate unused variables for the license header template.
|
@hazendaz Looking back at the previous GH Actions builds at https://github.com/revelc/formatter-maven-plugin/actions, I don't really see any failures caused by this. So, I'm not sure what is being fixed here. Nevertheless, I do think it's possible to avoid the processing of git information for the license checks. See #530 |
This reverts the change in #529 and restores the processing of licenses as part of CI tasks. However, drop the optional processing of git information to populate unused variables for the license header template.
|
@ctubbsii Output was throwing errors that it could not run jgit portion. I believe because the clone is shallow its always been that way and not likely noticed often but as would be the case here, it was not neven needed. We did this with a number of other projects where timestamp mattered but the slew of stack traces were not wanted. scm plugin has issues as well as they recently shallow cloned it which causes that same issue in licensing. |
|
@ctubbsii So follow up, it was not an issue with failures but noise :) |
…ugh data for that