OPDATA-3845: Trigger 'deploy' workflow from release PR

[dskloetc]

OPDATA-3845

Description

When a PR is merged, workflows deploy.yml and upsert-release-pr.yml are run. upsert-release-pr.yml creates/updates the PR to release all changed EAs. deploy.yml publishes docker images of changed EAs and creates/updates a PR in infra-k8s to deploy those images.

Both workflows independently run yarn changeset version to determine which EAs have changed and what their new versions will be.

This PR removes running yarn changeset version from deploy.yml by triggering based off of the PR created by upsert-release-pr.yml (detected by MASTERLIST.md being in the PR). This way it doesn't need to run yarn changeset version separately to determine the changed EAs and their versions because that's already done to create the release PR.

The point of this is to work towards being able to create release PRs, not only for all changed EAs but also for individual EAs or a subset of changed EAs. With the changes from this PR, such an individual/subset release PR would trigger publishing docker images and creating the infra-k8s PR exactly for those EAs planned for release, without having to duplicate logic to do so for the selected EAs.

In order not to interfere with the infra-k8s PRs currently created for the full releases, and in order to test this PR, infra-k8s PRs created from this workflow will be created with a branch name with an extra suffix unless the trigger PR is on the branch used for full releases.

One problem is that the is an environment restriction that prevents us from running the deploy.yml workflow on unprotected branches. Because we don't actually need the code from the release PR (but only the list of adapters) we work around this by triggering the workflow on the main branch from another workflow that determines which adapters to use.

Changes

1. Change deploy.yml workflow to
   1. stop triggering on merges
   2. take a list of adapters as input instead of calculating the changed adapters via a "mock release"
   3. take a branch suffix as input to use for the infra-k8s PR
   4. remove now unnecessary cleanup code
2. Add a deploy_from_pr.yml workflow that
   1. triggers on release PRs
   2. determines the changed adapters from the PR (rather than from changeset files)
   3. triggers the deploy.yml workflow passing the determined list of adapters
   4. additionally pass a suffix if the release PR is not the one created by upsert-release-pr.yml
3. Change .github/scripts/changed-adapters.sh to allow passing a predetermined list of adapters to be able to get the adapter data in the same format.

Steps to Test

1. I tested the deploy_from_pr.yml workflow by adding an echo in front of the dispatch command.
   The result can be seen here: https://github.com/smartcontractkit/external-adapters-js/actions/runs/18781536416/job/53588747900
2. The deploy.yml is hard to test because it should only run from protected branches.
3. I'll wait until after the next release to merge this PR and then test immediate and address any issues.

Quality Assurance

• If a new adapter was made, or an existing one was modified so that its environment variables have changed, update the relevant infra-k8s configuration file.
• If a new adapter was made, or an existing one was modified so that its environment variables have changed, update the relevant adapter-secrets configuration file or update the soak testing blacklist.
• If a new adapter was made, or a new endpoint was added, update the test-payload.json file with relevant requests.
• The branch naming follows git flow (feature/x, chore/x, release/x, hotfix/x, fix/x) or is created from Jira.
• This is related to a maximum of one Jira story or GitHub issue.
• Types are safe (avoid TypeScript/TSLint features like any and disable, instead use more specific types).
• All code changes have 100% unit and integration test coverage. If testing is not applicable or too difficult to justify doing, the reasoning should be documented explicitly in the PR.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 0efa793

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR