Fuse label_new_pr and label_pr workflows
#897
Labels
💻 aspect: code
Concerns the software code in the repository
✨ goal: improvement
Improvement to an existing user-facing feature
good first issue
New-contributor friendly
help wanted
Open to participation from the community
🟩 priority: low
Low priority and doesn't need to be rushed
🧱 stack: mgmt
Related to repo management and automations
⛔ status: blocked
Blocked & therefore, not ready for work
Projects
Milestone
Comments
dhruvkb
added
good first issue
|
This is ⛔ blocked till the monorepo project is completed. |
7 tasks
dhruvkb
pushed a commit
that referenced
this issue
Apr 14, 2023
* Add rawpixel media metric to popularity recalculation logic * Add tests to ensure that DDL matches python logic for popularity steps
This was referenced Oct 2, 2023
|
This issue is still blocked because the monorepo does not include the WordPress/openverse-infrastructure repo which still uses the |
|
With #3443, we decided to abandon the two separate workflows and now PR labelling is handled by the "PR automations" workflow. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Historical context
The task of labelling a new PR is divided into two workflows because of pre-monorepo reasons. Because the Python code to fetch the related issue and detect labels was located in the
WordPress/openverserepo, it had to invoked remotely from all others repos.The
label_new_pr.ymlworkflow was synced to all repositories, while thelabel_pr.ymlworkflow was centralised. The latter was called by the former for all new PRs with info about the PR.Problem
These workflows are extremely coupled and should be unified into one when there is no multi-repo complexity left. Since the labelling Python code would live in the same repo as all PRs the workflow can directly run it for all incoming PRs.
The text was updated successfully, but these errors were encountered: