Workflow Run Set PR labels not adding labels to Pull Requests

[SAUMILDHANKAR]

Overview

As a developer, I want all my workflow runs to be successful. For this issue, we will identify and fix the error which causes the Workflow Run Set PR labels to fail.

Details

Workflow Run Set PR labels is not adding labels to some of the pull requests. We need to fix this bug so that the labels from the issue can be added to their linked pull requests automatically.

Action Items

• Review set pr labels yml file and set pr label js
• Identify why some PRs such as Refactor of Wins Page Button #2918, Converted blank issue template to a form issue! #2899, Issue # 1498 #2969 didn't get the label from their linked issue. (For these issues, the labels on PRs had to be added manually, see comment1 and comment2)
• Replicate the scenario in your own repo, make the code changes and ensure that labels are added on all pull requests automatically.
• Make sure existing functionalities are not impacted by this code change.
• Finally, make a pull request to fix the issue.

Resources/Instructions

set pr labels yml file
set pr label js file
Related prs where this issue was encountered: #2918, #2899, #2969
Sample workflow failure: https://github.com/hackforla/website/actions/runs/1904313617

[github-actions]

Hi @tunglinn, thank you for taking up this issue! Hfla appreciates you :)

Do let fellow developers know about your:-
i. Availability: (When are you available to work on the issue/answer questions other programmers might have about your issue?)
ii. ETA: (When do you expect this issue to be completed?)

You're awesome!

P.S. - You may not take up another issue until this issue gets merged (or closed). Thanks again :)

[tunglinn]

Availability: 6 hours/Friday, Sunday, Monday
ETA: 7/4/2022

[tunglinn]

Progress: Understanding how Github actions work, duplicated repo into a private repo for testing.
Blockers: Unable to test actions in private repo.
Availability: M-Th (6 hours/each)
ETA: 7/11

[tunglinn]

I'm unable to access the action logs from the mentioned PRs (log retention is capped at 90 days for public repositories).
Overall, I found that PR label workflow fails to trigger along with the pull request instructions. I believe that the issue is not solely in the PR label workflow.

Here's a more detailed report of the mentioned issues:

For #2918, PR label and PR request instruction workflow wasn't run on the creation of the PR.
PR label was run on two other occasions:

on a commit (b4ae447) that comes from a different PR that the user reviewed

when someone removed a label and edited PR

Next, #2899 is not a true failure example. My understanding is the user manually added the labels during the creation of the PR

because the labels are added by the user before the Add Pull Request Instructions comment.

and the PR labels workflow did trigger.

Finally, for #2969, it looks like both the PR labels and PR request instructions workflow did not trigger if you check the "Checks" tab in the PR.

This is under the "Checks" tab of the issue.

Patterns found:

For both 2918 and 2969, there was a different user in an earlier commit. I will look into other PRs with similar commit histories.

and

None of the workflows triggered when PR was opened even though it should have according to this code.

from pr-instruction.yml

from set-pr-labels.yml

I found some recent PRs where github-actions did not add labels.

7/6/2022 - when PR was created, did not link issue
7/5/2022 - looks like the user manually added labels during PR creation, so not true failure
6/30/2022 - looks like the user manually added labels during PR creation, so not true failure

[tunglinn]

Found #3318, where a commit from a different user is added into the PR.

triggered both PR labels and PR request instructions workflow

PR labels are good, but the PR request instructions comment doesn't exist

Lint SCSS is always triggered on pull requests being synchronized. One potential solution is to add synchronize to the types of events that triggers the PR labels and request instruction workflow.

Next steps will be recreating and testing in private repository.

[tunglinn]

Found a few PR with same issue with logs still intact!
#3087 - false alarm, it seems like none of the workflow ran because there was a merge conflict of some sort merge conflict that Jessica mentioned.

Workflows don't run if there is a merge conflict

#3116 - false alarm, the merge branch isn't correct, workflows do not run unless they are for gh-pages, feature-homepage-launch, or feature-tech-dropdown

[tunglinn]

Hi all,
I'd like to test workflows on #2969.
I'd like to remove a label, and then edit the PR to trigger the workflow. Bonnie and I discussed this and seems harmless. Also, there is some precedent as Saumil did it in #2918.
Please let me know if this will cause problems.

[tunglinn]

Did some testing in existing PRs. I removed a label, updated the top PR comment, which should trigger the PR label workflow to re-add the label.

When testing in an already merged pull request #3291, the PR label action is able to be triggered.

However #2969 and #2918 did not trigger the PR label action.

I tested #2905, a PR from the same time as the two above. The workflow did trigger.

I thought that the workflow only triggers if the branch the PR is pulling from still exists.

But #2970 has a deleted branch, yet it triggers PR label action.

#2943 doesn't trigger. The from branch is greyed out, which is different from deleted branches in which you can click but brings you to a 404 error page.

[JessicaLucindaCheng]

@tunglinn I noticed this pr doesn't have labels on it and has Fixes #3316 so the automation should have put labels on it. The pr is #3340

[tunglinn]

@JessicaLucindaCheng I think it's because there's a merge conflict. I mentioned a case similar to this in this comment #2933 (comment). Do we want it to run even if there's a merge conflict?

Another piece of evidence is that Lint SCSS didn't run either.

[tunglinn]

I've been unable to replicate the bug.

Is it possible that it was a bug on the server side (GHA)?
https://www.githubstatus.com/ mentions some degraded performance around the time of the PRs with this bug.

[tunglinn]

Team has decided to close this issue and write up a decision report.

Decision report has my findings and recommended steps to take if the bug does appear again.