external-plugin: add label to PR if a test with a certain label has been changed

[dhiller]

Outcome

Automatically highlight a PR where a test with a certain label is touched.

Note: owners-label plugin can only apply labels to matching glob expressions, it doesn't care about test labels.

Use case

if a [Conformance] test is changed, we want to apply a label to the PR (suggestion: kind/conformance)

Implementation

Create external-plugin similar to other project-infra implementations that reacts on GitHub pull_request events.

Initial implementation will add the label if any test holding source label is changed, and remove the label if no change inside the PR for any test holding source label is detected.

Notes:

• label can also appear in parent Ginkgo nodes, so we should use the test outline to detect the label match
• detection of test changes via ast is a bonus - meaning detecting changes in sub-level, as in library calls (libvmi etc) or other called code.

Config:

kubevirt/kubevirt:
- test_target: '[Conformance]'
  label: kind/conformance
...

/kind enhancement
/area automation

FYI @fossedihelm @brianmcarey

Links:

• source code external-plugins
• image builds
• kubernetes manifests
• secrets deployment

[dhiller]

@dosubot looking at the links in the issue description, can you provide some examples on how the different prow external-plugins we have are implemented and deployed?

[dosubot]

The implementation and deployment of external-plugins in the project-infra repository follow a structured process. Here are some examples based on the existing plugins:

1. Implementation:

   • External plugins like rehearse, botreview, and phased are implemented to handle specific GitHub events such as pull_request and issue_comment. For instance, the rehearse plugin is designed to manage job rehearsals and reviews by triggering on these events ^[1].
   • The plugins are configured to apply labels or perform actions based on changes detected in pull requests. For example, the needs-rebase plugin applies labels when a pull request needs rebasing ^[1].

2. Deployment:

   • Deployment is triggered by changes in specific directories related to the external plugins. For example, changes in external-plugins/.* will trigger the pull-project-infra-test-external-plugins job ^[2].
   • Each deployment job is configured as a presubmit job, which is not always run but triggered by changes in specified directories. The job runs a container using a specific image and executes scripts to test the plugins ^[2].
   • Secrets play a crucial role in deployment by providing necessary authentication and configuration data, such as GitHub tokens and GCS service account credentials, which are managed in the secrets_dir ^[3].

These examples illustrate the structured approach to implementing and deploying external-plugins in the project-infra repository, ensuring they are triggered and executed correctly based on specific events and changes.

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other}

[dhiller]

@dosu the above issue aims at changing a label on a PR if a specific test implemented with onsi/ginkgo framework is changed. Do you have a suggestion on how to implement this?

[dosubot]

To implement a system that changes a label on a PR when a specific test using the onsi/ginkgo framework is changed, you can follow these steps:

1. Test Outline Generation: Use the ginkgo outline command to generate JSON outlines of the test files. This will help identify the structure and labels of the tests, including those in parent Ginkgo nodes.

2. Label Detection: Utilize the test-label-analyzer tool to analyze the generated outlines and detect tests with specific labels, such as [Conformance]. This tool can match test names or explicit Ginkgo labels using regular expressions ^[1].

3. AST Parsing for Changes: Implement an Abstract Syntax Tree (AST) parser to detect changes in the test files. This can help identify modifications at a sub-level, such as changes in library calls or other code dependencies. The PackageHash utility in the project-infra repository can be adapted for this purpose, as it already includes mechanisms to detect changes in Go test files ^[2].

4. GitHub Event Handling: Create an external plugin similar to existing ones in the project-infra repository. This plugin should listen for pull_request events and use the information from the test outline and AST parsing to determine if a test with the target label has been changed.

5. Label Application: If a change is detected in a test with the specified label, the plugin should apply the corresponding label to the PR (e.g., kind/conformance). If no such changes are detected, ensure the label is removed if it was previously applied.

6. Configuration: Define the configuration for the plugin in a YAML file, specifying the repository, test target label, and the label to apply. This configuration will guide the plugin's behavior.

By following these steps, you can automate the process of labeling PRs based on changes to specific tests, enhancing the workflow and ensuring relevant changes are highlighted.

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other}

[kubevirt-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[kubevirt-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle rotten

[dhiller]

/remove-lifecycle rotten

[kubevirt-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale