Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Expose CoverageOutputGenerator's label in a configuration #8736

Closed
iirina opened this issue Jun 27, 2019 · 2 comments
Closed

Expose CoverageOutputGenerator's label in a configuration #8736

iirina opened this issue Jun 27, 2019 · 2 comments
Labels
coverage P3 We're not considering working on this, but happy to review a PR. (No assignee) team-Rules-Server Issues for serverside rules included with Bazel type: feature request

Comments

@iirina
Copy link
Contributor

iirina commented Jun 27, 2019

In the native rules we have the late-bound attribute :lcov_merger which looks at the build configuration to see if coverage is enabled and returns the label of CoverageOutputGenerator or null (see BaseRuleClasses#115).

We need the Starlark rules to be able to define _lcov_merger as a late bound attribute in the same way. For this to happen, the CoverageOutputGenerators label has to be exposed on a class that extends BuildConfiguration.Fragment.

This is helpful for example for rules_go (see #8670), in order for go_test to be compatible with bazel's native test rules (e.g. java_test, cc_test).
@iirina iirina added coverage P3 We're not considering working on this, but happy to review a PR. (No assignee) team-Rules-Server Issues for serverside rules included with Bazel labels Jun 27, 2019
@ulfjack ulfjack mentioned this issue Jul 14, 2021
Closed
@zhenyudg zhenyudg mentioned this issue Sep 2, 2021
Closed
@fmeum fmeum mentioned this issue Nov 29, 2021
Closed
@fmeum
Copy link
Collaborator

fmeum commented Jan 15, 2022 •
edited
Loading

@c-mita I think that I generally know how to resolve this issue, but would need to know which Fragment I should expose the label on. Could you provide guidance here as per #13983 (comment) or point me to someone who could?

@c-mita
Copy link
Member

c-mita commented Jan 27, 2022

I don't know if there is a good fragment at the moment to add this one; the existing ones tend to be language specific. It may be we need to create one.

@fmeum fmeum mentioned this issue Feb 4, 2022
Closed
fmeum added a commit to fmeum/bazel that referenced this issue Mar 8, 2022
@fmeum
Expose CoverageOutputGenerator on a Fragment
0c3a4b6 
This allows Starlark rules to define _lcov_merger as a late-bound Starlark configuration_field in order not to pay the cost of building it when coverage isn't enabled.

Fixes bazelbuild#8736
Fixes bazelbuild#10642

Closes bazelbuild#14724.

RELNOTES: Add coverage configuration fragment, used to expose output_generator label.
PiperOrigin-RevId: 433156089
@fmeum fmeum mentioned this issue Mar 8, 2022
Merged
Wyverald pushed a commit that referenced this issue Mar 8, 2022
@fmeum
Expose CoverageOutputGenerator on a Fragment (#14997)
5e79972 
This allows Starlark rules to define _lcov_merger as a late-bound Starlark configuration_field in order not to pay the cost of building it when coverage isn't enabled.

Fixes #8736
Fixes #10642

Closes #14724.

RELNOTES: Add coverage configuration fragment, used to expose output_generator label.
PiperOrigin-RevId: 433156089
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
coverage P3 We're not considering working on this, but happy to review a PR. (No assignee) team-Rules-Server Issues for serverside rules included with Bazel type: feature request
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Expose CoverageOutputGenerator on a Fragment fmeum/bazel
4 participants
@iirina @lberki @c-mita @fmeum