fix(workflow): create-uiux-issue — remove invalid assignee, guard labels against 422

[Copilot]

The create-uiux-issue workflow was missing from this repo; the reference implementation would fail with 422 Validation Failed on every PR merge due to an invalid assignees: ['copilot'] and unconditional use of labels that may not exist.

Changes

• New workflow .github/workflows/create-uiux-issue.yml — fires on pull_request: closed targeting master, gated by github.event.pull_request.merged == true
• Removed assignees — copilot is not a valid repo collaborator; field is omitted entirely with an explanatory comment
• Robust label application — pre-flight getLabel call per desired label; only labels that already exist in the repo are passed to issues.create; missing labels emit core.warning and are skipped rather than aborting

for (const label of desiredLabels) {
  try {
    await github.rest.issues.getLabel({ owner, repo, name: label });
    existingLabels.push(label);
  } catch (err) {
    if (err.status === 404) {
      core.warning(`Label "${label}" not found in repo — skipping.`);
    } else { throw err; }
  }
}

• Least-privilege permissions — issues: write + contents: read only

Original prompt

Goal

Fix the GitHub Actions workflow that creates a UI/UX issue on PR merge so that it no longer fails due to invalid assignee/labels.

Repository

Apply changes in: mishravivek-ms/SpringbootSampleCode
Base branch: master

What to change

Update the workflow file:

• .github/workflows/create-uiux-issue.yml

Problems to address

1. The workflow uses actions/github-script to create an issue and sets assignees: ['copilot']. This commonly causes a 422 Validation Failed error because copilot is usually not an assignable GitHub username in the repo.
2. The labels ['ui/ux', 'copilot'] may also fail if labels do not exist or cannot be applied.

Required fix

• Remove the assignees: ['copilot'] field.
• Make label application robust:
  • Either remove labels entirely, or
  • Add logic to apply only labels that exist (preferred), so issue creation never fails because of missing labels.

Acceptance criteria

• Workflow YAML remains valid.
• When a PR is merged into the base branch configured in the workflow, the job creates an issue successfully without failing due to assignees/labels.
• Add brief inline comments explaining why assignees was removed and how labels are handled.

Notes

• Keep existing behavior: only run when the PR is merged (not merely closed).

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: can you check my action log ?

Assistant: Your GitHub Actions run 23312628944 in mishravivek-ms/agenticworkflow_GHCP does not contain any failing jobs.

So there isn’t an “action log for a failure” to diagnose for that run—everything in that run completed without a job marked as failed.

If you want, paste the run URL (full link) or tell me:

• which job name/step name you think is problematic, or
• a different run ID that actually failed,

and I’ll check that specific run/job and summarize the error.

User: https://github.com/mishravivek-ms/agenticworkflow_GHCP/actions/runs/23312628944/job/67803673555 can you please check what is failure reason ?

Assistant: That job didn’t fail due to an error— it was cancelled.

• Job: 67803673555
• Run: 23312628944
• Status: cancelled
• Reason shown: Check with id 67803673555 was cancelled

So there won’t be a meaningful “failure reason” in the logs (no stack trace / failing step), because GitHub stopped the job before it completed.

Common causes of a cancelled job:

1. You (or a maintainer) clicked Cancel workflow / Cancel job in the UI.
2. A newer run of the same workflow auto-cancelled the older one (when concurrency is configured with cancel-in-progress: true).
3. The workflow was cancelled by another job/step via the GitHub API / gh run cancel.
4. Repository/org policy or timeout cancelled it.

If you share:

• the workflow file name (e.g., .github/workflows/ci.yml) or paste the concurrency: section,
• or link the newer run that replaced it (if any),
  I can tell you which of the above is most likely in your case.

User: I can see The run was canceled by @copilot-swe-agent[bot]. ? how to fix ?

Assistant: If the UI says “The run was canceled by @copilot-swe-agent[bot]”, that means a GitHub App/bot acting on your repo had permission to cancel workflow runs and did so. This is usually caused by one of these:

1. Concurrency auto-cancel

• Your workflow has a concurrency: block with cancel-in-progress: true.
• When a newer run starts, GitHub cancels the older one. The “actor” can show up as a bot/app that initiated/triggered the newer run or interacted with the run.

2. The bot explicitly cancels runs

• Some automation (Copilot coding agent / SWE agent workflow, a script using gh run cancel, or GitHub API) cancels runs intentionally (e.g., to avoid wasting minutes when a newer attempt is running).

How to fix (most common)

A) Disable auto-cancel in concurrency

Check your workflow YAML under .github/workflows/*.yml for something like:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

Change to:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: false

Or remove the concurrency: block entirely if you don’t need it.

B) If Copilot SWE agent is canceling runs as part of its automation

If you have Copilot coding-agent / SWE-agent automation enabled in the repo/org, you can prevent it from canceling runs by tightening token permissions:

In your workflow, set least-privilege permissions (this often blocks cancellation via API):

permissions:
  actions: read
  contents: read

(If you need checkout + PR operations, we can tailor permissions, but avoid actions: write unless required.)

C) Ensure the job isn’t being canceled by a newer run

Look at the Actions page: if you see a newer run started shortly after, then this is almost certainly concurrency behavi...

This pull request was created from Copilot chat.

---

⌨️ Start Copilot coding agent tasks without leaving your editor — available in VS Code, Visual Studio, JetBrains IDEs and Eclipse.