Add DigitalOcean infrastructure e2e monitoring workflow

[jasbanza]

What is the purpose of the change:

WIP. This PR allows us to do playwright tests on vercel preview links, using DigitalOcean endpoints.

NB: Endpoints need to be manually set for this specific branch in Vercel secrets!

Linear Task

MER-59: Set up DigitalOcean Migration monitoring

Brief Changelog

• There are additional workflows in this branch which are specifically meant to help facilitate automated tests.

Testing and Verifying

• Additional tweaks might be needed as we begin testing.
  • simplify playwright tests as existing ones are still flaky.
• This is a work in progress and this PR will be updated once ready for review.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
osmosis-frontend	Ready	Preview, Comment	Jan 27, 2026 3:02pm

4 Skipped Deployments

Project	Deployment	Review	Updated (UTC)
osmosis-frontend-datadog	Ignored		Jan 27, 2026 3:02pm
osmosis-frontend-dev	Ignored		Jan 27, 2026 3:02pm
osmosis-frontend-edgenet	Ignored		Jan 27, 2026 3:02pm
osmosis-testnet	Ignored		Jan 27, 2026 3:02pm

To fix the issue, add an explicit permissions block that limits the GITHUB_TOKEN to the minimal required scope. From the provided snippet, the jobs only need to read the repository (for actions/checkout) and do not appear to perform any GitHub write operations. A safe minimal configuration is contents: read at the workflow root so it applies to all jobs that don’t override it.

Concretely, in .github/workflows/monitoring-do-e2e-tests.yml, add a top‑level permissions: block after the on: section (e.g., after line 16). This block should specify contents: read. No changes are needed to individual jobs unless some job (not shown) truly needs additional scopes; based on the provided snippet, that is not the case. No imports or external tools are required; this is purely a YAML configuration change within the workflow file.

In general, the fix is to add an explicit permissions: block that grants the minimal necessary access to the GITHUB_TOKEN. This can be done at the workflow root (applies to all jobs) or for individual jobs. Since all visible jobs only need to read repository contents, the minimal safe baseline is permissions: { contents: read }.

The best fix here, without changing functionality, is to define a single workflow-level permissions: block near the top of .github/workflows/monitoring-do-e2e-tests.yml, after the on: section and before env: or jobs:. This will satisfy CodeQL’s complaint about the server-e2e-tests job (and all other jobs), while keeping functionality unchanged, because they only require read access to check out code and use caches/artifacts. No additional methods, imports, or definitions are needed; this is purely a YAML configuration change.

Specifically, in .github/workflows/monitoring-do-e2e-tests.yml, insert:

permissions:
  contents: read

between the on: block (ending at line 16) and the env: block (starting at line 19). No other changes are required.

To fix the problem, explicitly set permissions for the workflow so the GITHUB_TOKEN has only the minimal scopes required. Since the jobs here only read repository contents and upload artifacts, we can safely set contents: read at the workflow level. This documents the requirement and ensures the workflow won’t gain excessive privileges if repo/org defaults change.

The best minimal change is to add a root-level permissions: block near the top of .github/workflows/monitoring-do-e2e-tests.yml, after the on: trigger (or before env: / jobs:). This will apply to all jobs (resolve-do-preview, server-e2e-tests, fe-swap, fe-limit, etc.) that don’t have their own permissions block. No additional imports, methods, or definitions are needed; it’s a pure YAML configuration change.

Concretely:

• Edit .github/workflows/monitoring-do-e2e-tests.yml.
• Insert:

permissions:
  contents: read

at the root level (same indentation as on: and env:), for example between the on: block ending at line 16 and the env: block starting at line 19. This constrains the GITHUB_TOKEN for every job and addresses the CodeQL warning.

In general, to fix this issue you should explicitly define a permissions: block either at the root of the workflow (to apply to all jobs by default) or per-job, and restrict the GITHUB_TOKEN to the least privileges necessary. For workflows that only need to read code and interact with Actions features (like artifacts and cache) but do not push commits, modify releases, or change issues/PRs, contents: read is usually sufficient as a base.

For this specific workflow in .github/workflows/monitoring-do-e2e-tests.yml, none of the shown jobs perform write operations against the GitHub API or repository contents. They use actions/checkout, actions/cache, actions/upload-artifact, run Playwright tests, and call external services (Vercel, Datadog) using secrets. These all function with a read-only contents permission. The simplest, least-invasive fix is therefore:

• Add a top-level permissions: block immediately after the name: (or before on:) that sets contents: read.
• This will apply to all jobs in the workflow, including the fe-limit job at line 135 that CodeQL specifically flagged, without changing any functional behavior.

No new methods, definitions, or imports are needed; it’s just a YAML configuration change.

In general, fix this by adding an explicit permissions: block that scopes the GITHUB_TOKEN to the minimum required. Where jobs only need to read repository contents or metadata, use contents: read. Where a job must modify deployments (like delete-deployments), grant deployments: write for that job only. This documents the workflow’s needs and prevents accidental escalation if org/repo defaults change.

For this workflow, the simplest and least intrusive fix is:

• Add a root-level permissions: block (just below on:) that sets the token to read-only: contents: read.
• Add a job-level permissions: block to delete-deployments that grants the additional deployments: write permission that actions/github-script needs to list, mark inactive, and delete deployments.
• Leave other jobs (e.g., resolve-do-preview, server-e2e-tests, fe-limit, fe-bot-alert) with the inherited read-only permissions, since they do not appear to use write operations on the GitHub API.

Concretely:

• In .github/workflows/monitoring-do-e2e-tests.yml, insert:

  permissions:
    contents: read

  after the on: block (after line 16/18 region, before env:).

• In the delete-deployments job definition (line 221 onwards), insert:

    permissions:
      contents: read
      deployments: write

  immediately under delete-deployments: and before runs-on:. This overrides the workflow default for that job only and grants the minimal required write scope.

No new imports or external libraries are needed, just YAML changes to the workflow.

At a high level, the fix is to define explicit GITHUB_TOKEN permissions for this workflow, reducing them to the minimum needed. The simplest and safest approach is to add a permissions: block at the workflow root that grants read-only access to repository contents and other resources by default, and then override permissions for specific jobs that need additional write scopes.

For this workflow, most jobs are running tests and uploading artifacts; they only need contents: read and id-token: write if they use OIDC (not shown here). The fe-bot-alert job only sends data to Datadog using API keys in secrets and does not call GitHub APIs, so it can use the default read-only permissions. The delete-deployments job uses the GitHub REST API (via actions/github-script) to list deployments and then update and delete them, which require deployments: write. To implement the fix without changing existing behavior, we will:

• Add a workflow-level permissions: block after the on: section, setting contents: read as the default (and you could add other read scopes if needed elsewhere).
• Add a job-level permissions: block under delete-deployments: granting deployments: write (and keeping contents: read), so that this job has the rights it needs while other jobs stay read-only.

All changes are confined to .github/workflows/monitoring-do-e2e-tests.yml in the shown regions: one insertion near the top (after the on: block, around line 16–18), and one insertion under the delete-deployments job (around line 221–223). No new imports or external dependencies are required.