-
Notifications
You must be signed in to change notification settings - Fork 691
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
Make jar_app_layer._classpath_as_file public #1947
Make jar_app_layer._classpath_as_file public #1947
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.
I think this looks good. The problems with the Mac runner as known of but I'm not sure what causes them. If your team uses macs this may be something worth looking into but I don't think this will cause any regressions.
It looks like some of the non-hermetic tests are breaking because an upstream dep changed:
|
Retriggered the build and looks like we're back to just the macos builds failing. |
@jakemcc , sorry for the delay. Unfortunately, I don't have access to mac hardware so I've disabled the newly failing tests on mac. I'll fix any issues that come up from this change. |
Sorry for the delay. I recently pushed a PR to disable the newly broken tests in CI here: a351a3f If you rebase past this one things should be good. Very sorry about the inconvenience this has caused you! |
This is being done to make this attribute public so that callers can specify it.
e7a008c
to
ff17515
Compare
No worries. Thanks for sticking with it and helping out! |
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Callers of
jar_app_layer
can not specify_classpath_as_file
.What is the new behavior?
Yes. It changes the
jar_app_layer._classpath_as_file
private attribute to a public attributejar_app_layer.classpath_as_file
. This allows callers to override the default value ofFalse
when applying thejar_app_layer
rule.The PR also make the callers of
jar_app_layer
expose an optionalclasspath_as_file
argument so that folks can passthrough the argument tojar_app_layer
.Some details of why someone would want to do this can be found in the Bazel slack
Does this PR introduce a breaking change?
Given that the
classpath_as_file
was private before, folks couldn't pass it in before so I would think that changing from private to public is a non-breaking change. The other changes to the various jvm*_image
macros keep the previous behavior as the default.Other information