-
Notifications
You must be signed in to change notification settings - Fork 274
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
Restrict getOutputSourceDirectorySet() to directories only #523
Conversation
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed (or fixed any issues), please reply here with What to do if you already signed the CLAIndividual signers
Corporate signers
ℹ️ Googlers: Go here for more info. |
@googlebot I signed 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.
I wonder if it was a mistake to do #480, like it was a mistake to have generatedFilesDir. But it looks like this is just for the IDE, and yeah, that shouldn't break.
I like the idea of outputting directly to a Zip file, but it seems strange to do it with this method: protobuf-gradle-plugin/src/main/groovy/com/google/protobuf/gradle/GenerateProtoTask.groovy Line 509 in 8a35d46
Although it does work perfectly after the change in this PR. |
Arg. We're bitten by the travis-ci.org migration. I'm a bit surprised that it only now started failing, but it was still working in August, even though it is claimed to be shut off in June. |
It is a bit awkward to support such a usage, as packaging generated code into JAR/ZIP doesn't seem to be something that should/can be done together with source compilation (the primary goal of this plugin is to automate compilation). It would be best if users do this by themselves separately. Many users like in #478, they use this plugin simply as a management tool for proto and generated code (mostly for languages other than Java family). As supporting this doesn't do harm to existing functionalities, I accepted it. |
@ejona86 Could you help fix Travis? Looks it requires permission from google organization. |
@voidzcy, I can't fix it right now. Instead of migrating to travis-ci.com we've generally been migrating off of travis, like to github actions. That isn't that hard, but isn't "do it in 5 minutes." |
Sent out #525 for CI migration. |
Anything else I can do to push this one through? |
@cilki, there were test failures. The failures are in ProtobufJavaPluginTest, so shouldn't be too hard for you to reproduce and take a look. If the failure doesn't make much sense I can help take a look, but it doesn't seem like a flake at first glance. |
@ejona86 I'll give it a go. The tests were failing for me before I made any changes, so I'll investigate that first. |
@cilki, the Android tests and such can be more annoying, but I thought that one failing test should be easier. If no progress, just report back. |
travis-ci.org is dead and travis-ci.com has no free tier, which means it isn't great for users to test on their own. GH Actions seems a better fit.
This improves the 'testing' GitHub actions workflow in a number of ways: - Use 'gradle-build-action' to invoke Gradle, to optimize caching of Gradle User Home between jobs - Run each test build and the codenarc builds in parallel
- Set a 'CI' env var when running on GitHub actions, and use this to create txt codenarc reports. - Remove some special handling for Travis that is not required on GitHub actions. - Remove the Travis status flag from README.
Upgradle to Gradle 6.9.1 for new Kotlin DSL capabilities. Use better dependency declaration between Groovy/Java. Remove environment variables for action: - CI is set to true in Github action runs anyway. - The memory settings shouldn't be necessary any more.
Empty directories should not matter for source files, so let's ignore them for up-to-date checks as well. This avoids two issues: * Right now, the task will be out-of-date when you add an empty directory to the source folder. There will also be a build cache miss if the only difference between the sources is an empty directory somewhere. * In Gradle 8.0, the task won't skip any more if there are only empty directories in the source folder and no actual files. That is because the behaviour for skipping when empty and up-to-date checking will be more consistent.
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
Indeed some of the test failures were my fault for using Java 11 instead of Java 8. I fixed the actual issue, but rebased in the meantime which seems to have messed some things up. I'll make a new PR. |
#480 allows
outputPath
to be a zip/jar file, but it's not excluded from theSourceDirectorySet
in that case. Therefore, when the source set gets evaluated, it leads to this exception in Gradle 7.2:The fix is to just ignore files when creating the source directory for generated output.