fix workflow: skip bot authors and catch assign errors to avoid 403 f…

[QuangAnhLe]

This PR fixes #2374

Implemented changes:

1. Wrapped addAssignees in try/catch
The original 403 doesn't only happen for bots — any author who isn't a collaborator (e.g. a PR from a fork) also triggers a 403 and would fail the workflow. Since this runs on pull_request_target, that red status check could block merge requirements. Now failures are logged as a warning instead of failing the job:

catch (err) {
  console.log(Warning: could not assign ${pr.user.login}: ${err.message});
}

2. Removed the obsolete env var
   ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION: true is a leftover from the github-script@v6 / Node 16 era and isn't needed with @v7 (Node 20).

Minor (already in the diff):

pr.assignees?.length > 0 — safer optional chaining
Added the missing trailing newline

---

Testing instructions

Please add conscise, understandable instructions on how a reviewer can test/verify the functionality of your contribution here:

Test 1 — Human author gets assigned (the main fix)
Open a PR from your branch to main (any title).
Go to the Checks tab → run of Auto Assign PR Author.
Expected:
Job assign-author is ✅ green (previously it crashed with ReferenceError: author is not defined)
Step "Assign PR author if no assignee exists" logs: Assigned quangle to PR #N
Your name appears under Development → Assigned on the PR (or check the Assignees section in the PR sidebar)
Test 2 — Bot author is skipped (the original 403 scenario)
Have a bot open a PR. Easiest options:
Enable Dependabot (Settings → Secrets and dependencies → Dependabot) and let it open an update PR, or
Use any GitHub App with commit access in the repo
Expected:
Job is ✅ green
Log shows: PR author dependabot[bot] is a bot. Skipping assignment.
No 403 error, no assignee set
Test 3 — Existing assignee is not overwritten
Before opening a new PR... actually the assign happens on opened, so: open a new PR, then manually assign someone else and re-run the workflow manually (Actions tab → workflow → Use workflow → Run workflow, select the PR). Since types: [opened] is the only trigger, a manual re-run is the practical way to exercise this branch.
Expected: log shows PR already has assignees. Skipping. and the manual assignee is unchanged.
Test 4 — 403 on non-collaborator (try/catch path)
Requires a PR whose author is not a collaborator:

Fork the repo to a second GitHub account (one you control that is not a collaborator on the main repo).
Push a branch to the fork, open a PR from the fork.
Expected:
addAssignees returns 403 → log shows Warning: could not assign : ...
Job is still ✅ green — this is the key behavior change. Before the try/catch, this exact case would have red-flagged the workflow and could block merge requirements.

---

Checklist for this PR

Make sure everything is checked before merging this PR. For further info please also see
our DoD.

• When running mvn clean test locally all tests pass and build is successful
• PR title is of the form #«issue-id»: «brief summary» (e.g. #921: fixed setup.bat and not feature/921 fixed setup.bat). If no issue ID exists, title only.
• PR top-level comment summaries what has been done and contains link to addressed issue(s)
• PR and issue(s) have suitable labels
• Issue is set to In Progress and assigned to you or there is no issue (might happen for very small PRs)
• You followed all coding conventions
• You have added the issue implemented by your PR in CHANGELOG.adoc unless issue is labelled
  with internal
• You have not changed any dependency in pom.xml files or otherwise if runtime dependencies changed, you have updated our LICENSE.asciidoc
• You have formulated clear instructions on how to test your contribution under "Testing instructions"

[coveralls]

Coverage Report for CI Build 33013403314

Coverage decreased (-0.02%) to 73.609%

Details

• Coverage decreased (-0.02%) from the base build.
• Patch coverage: No coverable lines changed in this PR.
• 1 coverage regression across 1 file.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

1 previously-covered line in 1 file lost coverage.

File	Lines Losing Coverage	Coverage
com/devonfw/tools/ide/version/VersionSegment.java	1	91.08%

---

Coverage Stats

Relevant Lines:	18184
Covered Lines:	13991
Line Coverage:	76.94%
Relevant Branches:	8060
Covered Branches:	5327
Branch Coverage:	66.09%
Branches in Coverage %:	Yes
Coverage Strength:	3.28 hits per line

---

💛 - Coveralls