fix duplication of docs issues

[emmyoop]

resolves #8746

Problem

Workflow has double generated issues in the other repo

Solution

Ensure the label added in the labeled event is user docs and only run if that's true or the PR is in a merged state with the correct label.

Checklist

• I have read the contributing guide and understand what's expected of me
• I have run this code in development and it appears to resolve the stated issue
• This PR includes tests, or tests are not required/relevant for this PR
• This PR has no interface changes (e.g. macros, cli, logs, json artifacts, config files, adapter interface, etc) or this PR has already received feedback and approval from Product or DX
• This PR includes type annotations for new and modified functions

[codecov]

Codecov Report

All modified lines are covered by tests ✅

Comparison is base (408a789) 86.65% compared to head (f3872b2) 86.65%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #8747   +/-   ##
=======================================
  Coverage   86.65%   86.65%           
=======================================
  Files         176      176           
  Lines       25772    25772           
=======================================
  Hits        22332    22332           
  Misses       3440     3440           

Flag	Coverage Δ
integration	83.41% <ø> (ø)
unit	65.13% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[aranke]

If GitHub passes in these two events in order that:

1. Triggers the labeled if/else branch
2. Triggers the closed if/else branch,
   then two docs issues will be created?

Can we change this logic to check for a docs issue instead, and only create one if it doesn't exist?

[emmyoop]

Can we change this logic to check for a docs issue instead, and only create one if it doesn't exist?

We can't because we don't know what the issue is. The main action flow is:

1. Check if a templated comment exists on the PR
2. If the Comment does not exist open an issue in the designated repo
3. Leave the templated comment on the PR with a link to the newly opened issue

So that takes care of most cases where this is a problem. The reason it generated 2 issues on a PR was because we merged the PR and immediately added a backport label. It triggered this twice (for both closed and labeled) and they ran so close together that neither left the comment before the other checked for a comment. This fix would prevent the labeled trigger from running calling the workflow.

This fix doesn't solve for the case of someone merging a PR and specifically adding the user docs label immediately but I'm not sure there's much we can do about that based on how this kind of state exists in GitHub and wanting the flexibility to be able to add the label before or after a PR is merged. The user docs label is also not generally a label we wait to add until the last second. The backport labels are since they don't trigger when you add them before merge.

[aranke]

Makes sense to me, LGTM!