openedx-webhooks only considers repo-specific info for labeling and rejects manual overrides

[itsjeyd]

Epic

#134: Improving OSPR Management

Story

"As an OSPR manager, I want

1. openedx-webhooks to add the core contributor label to all OSPRs coming from CCs, and
2. the ability to override the bot's decisions if necessary

... so that the presence or absence of the core contributor label on an OSPR correctly reflects the author's status."

Full description

Follows up on #155.

The automation implemented in #155 seems to work as expected for some repositories (e.g. ones where the author of an OSPR is a CC for the parent repository).

However, it doesn't seem to be adding the core contributor label to an OSPR -- at least not reliably -- if the author is a CC but doesn't have CC status on the parent repository of the OSPR.

In this situation, attempting to add the core contributor label manually results in the bot removing the label right away:

The purpose of this ticket is to update the behavior of the bot to add the core contributor label based on global CC status, and to allow users with relevant permissions (such as OSPR managers) to add the label manually if necessary.

Examples

PRs where the automation worked as expected:

• chore: add strict type annotations on the entire codebase code-annotations#169
• fix: redirect to account MFE when using any legacy account URL edx-platform#36894

PRs that should have gotten the core contributor label but didn't:

• feat: remove waffle flags for managing course outline sidebar frontend-app-learning#1713
• feat: move sequence navigation to plugin slot frontend-app-learning#1716

Behavioral specifications

N/A

Documentation updates & improvements criteria

Left to the assignee's appreciation

Relevant repositories

• https://github.com/openedx/openedx-webhooks

Review timeline

Flexible

[itsjeyd]

@mphilbrick211 FYI ⬆

[xitij2000]

@itsjeyd This is a bit surprising. My assumption was that the data the webhook uses is global. Perhaps this PR was simply using obsolete data in case of a new CC? In any case it should not remove a manually added CC label. So that should be fixed.

[xitij2000]

@itsjeyd I've created a PR to fix the issue of the webhook removing the label, in this PR. As for the other issue, I'm not entirely sure what's going on there.

My understanding is that the webhook runs in an environment where it is a provided a file that has all the information about all CCs. However, my assumption was that this file has a record of the global CC status, not the pre-repo CC status.

So the issues in that case might just be due to the file not being entirely up to date.

[itsjeyd]

@xitij2000 Thanks for the details, I'll keep an eye out for cases where the bot's decisions don't seem to line up with available info about CC status. If we can get more data, maybe that will reveal a pattern.

No need to block openedx/openedx-webhooks#368 on that, though. It'll be good to get back the ability to manually add/remove the core contributor label sooner rather than later.

[itsjeyd]

@xitij2000 I came across a new batch of cases today where the bot rejected the core contributor label:

• test: Add Node 24 to CI matrix frontend-build#660
• build: Upgrade to Node 24 frontend-build#661
• test: Remove support for Node 20 frontend-build#662
• Peter kulko/node22 upgrade test frontend-build#663
• test: Add Node 24 to CI matrix frontend-app-learning#1752
• build: Upgrade to Node 24 frontend-app-learning#1753
• test: Remove support for Node 20 frontend-app-learning#1754

Some notes:

• The initial examples for this behavior (cf. ticket description) came from https://github.com/openedx/frontend-app-learning, but here we can see that the issue affects https://github.com/openedx/frontend-build, too. So it doesn't seem to be repo-specific.
• Today's examples all came from PKulkoRaccoonGang, while the initial examples came from ihor-romaniuk (so the issue doesn't seem to be author-specific either).
• Both authors have had CC status since long before the initial implementation of the labeling automation was merged on May 14 of this year. They were added to the program in June 2024 and August 2024, respectively. So it's starting to seem unlikely that the issue

  might just be due to the [source file containing CC information] not being entirely up to date.

CC @feanil, in case you have any input to share here.

[xitij2000]

@itsjeyd I think it might make sense to use the committers team as a source of truth in this case, rather than relying on the values in the CSV file. That approach is unfortunately quite opaque. I don't know what's in it so I can't validate if the issue is coming from the file or from the code or elsewhere.

[itsjeyd]

@xitij2000

I think it might make sense to use the committers team as a source of truth in this case, rather than relying on the values in the CSV file.

That might be a good alternative.

@feanil What would we lose by doing that? I.e. does the CSV file contain any relevant info that we wouldn't be able to get when using the committers team as a source of truth?

CC @mphilbrick211