'Welcome new contributors' workflow is failing

[BenHenning]

Check for duplicates

• I have searched for similar issues before opening a new one.

Description

Reproduction steps

Create a PR and run CI, or try to run the workflow manually through the 'Actions' tab.

Priority

This is causing a CI failure for all PRs. While not strictly a huge issue since we can just welcome contributors manually, it's mainly an issue because it encourages broken windows theory and not expecting the precedence of CI always passing.

Stack trace

Run actions/first-interaction@v3
  with:
    repo-token: ***
    pr-message: Welcome! It looks like this is your first pull request in Blockly, so here are a couple of tips:
  - You can find tips about contributing to Blockly and how to validate your changes on our [developer site](https://developers.google.com/blockly/guides/contribute/core#making_and_verifying_a_change).
  - All contributors must sign the Google Contributor License Agreement (CLA). If the google-cla bot leaves a comment on this PR, make sure you follow the instructions.
  - We use conventional commits to make versioning the package easier. Make sure your commit message is in the [proper format](https://developers.google.com/blockly/guides/contribute/get-started/commits) or [learn how to fix it](https://developers.google.com/blockly/guides/contribute/get-started/commits#fixing_non-conventional_commits).
  - If any of the other checks on this PR fail, you can click on them to learn why. It might be that your change caused a test failure, or that you need to double-check the [style guide](https://developers.google.com/blockly/guides/contribute/core/style_guide).
  Thank you for opening this PR! A member of the Blockly team will review it soon.
  
    repo_token: ***
Running actions/first-interaction!
file:///home/runner/work/_actions/actions/first-interaction/v3/dist/index.js:27041
		        throw new Error(`Input required and not supplied: ${name}`);
		              ^

Error: Input required and not supplied: issue_message
    at Object.getInput (file:///home/runner/work/_actions/actions/first-interaction/v3/dist/index.js:27041:17)
    at run (file:///home/runner/work/_actions/actions/first-interaction/v3/dist/index.js:34844:38)
    at file:///home/runner/work/_actions/actions/first-interaction/v3/dist/index.js:34917:1
    at ModuleJob.run (node:internal/modules/esm/module_job:371:25)
    at async onImport.tracePromise.__proto__ (node:internal/modules/esm/loader:669:26)
    at async asyncRunEntryPointWithESMLoader (node:internal/modules/run_main:101:5)

Node.js v24.5.0
`

Screenshots

No response

Browsers

No response

[BenHenning]

My guess is that something changed within GitHub and it broke actions/first-interaction@v3.

[BenHenning]

Relevant issue: actions/first-interaction#365.

[BenHenning]

actions/first-interaction#368 and other issues reveal there's kind of a whole lot of issues going on with that workflow. This all started in #9323 when there was a major version bump to v3. That worked fine but the author of the action pushed a breaking minor version (3.1.0) which updated underneath us due to pinning only the major version. Usually this is not an issue in the GitHub Actions ecosystem, but it is in this case due to the problematic push of the action and no follow-up fix yet.

Downgrading should resolve the problem.

[BenHenning]

The plot thickens. @maribethb tried to determine if #9448 is working by creating a temporary PR on my fork which already has it merged into develop, and it failed (BenHenning#13):

Running actions/first-interaction!
Skipping...Not an Issue/PR Event

That brought me to this issue:

actions/first-interaction#345

Apparently pull_request_target wasn't supported until v3.1.0 which we can't use. 🙃

I am now confused why this ever worked since we've only ever used pull_request_target. Perhaps v2 of the action worked correctly with pull_request_target. I will need to try to move back to v2 and see if that actually works.

[BenHenning]

Ah I see. #9274 is actually when it broke. The action started having issues basically when it was upgraded to TypeScript (the author seems to have made a lot of mistakes with that migration, including several breaking changes) which was in v2. v2 to v3 was a short time period (and then for v3.1), but v1 was around for a while. We actually need to move back to v1 pre-TypeScript until the action's issues are all addressed.

[maribethb]

Tbh given the other work we have and the transition timeline we're working under, I'd just disable/delete this workflow for now, as we might want to switch to a different action provider given the issues.