🐛 Bug Report: plugin-cloudbuild rerun workflow is blocked by CORS error

📜 Description

The plugin @backstage/plugin-cloudbuild is great and loads initial requests for build history without any issues. However, when the Rerun workflow button is pressed, the request is blocked by a CORS error Reason: CORS header ‘Access-Control-Allow-Origin’ missing. This is true in local development as well as our production instance.

👍 Expected behavior

The Rerun workflow button can be used in backstage without being blocked by CORS errors.

👎 Actual Behavior with Screenshots

The builds load, but the rerun workflow button fails:

Requests to /builds are successful, whereas a request to retry a single row’s workflow is blocked by CORS.

👟 Reproduction steps

Click on the Rerun workflow button from the plugin-cloudbuilds builds table.

📃 Provide the context for the Bug.

No response

🖥️ Your Environment

OS: Darwin 21.6.0 - darwin/x64 node: v16.18.1 yarn: 1.22.0 cli: 0.20.0 (installed) backstage: 1.7.0

Dependencies: @backstage/app-defaults 1.0.7, 1.0.8 @backstage/backend-common 0.15.2, 0.16.0 @backstage/backend-plugin-api 0.1.3, 0.1.4 @backstage/backend-tasks 0.3.6, 0.3.7 @backstage/catalog-client 1.1.1, 1.1.2 @backstage/catalog-model 1.1.2, 1.1.3 @backstage/cli-common 0.1.10 @backstage/cli 0.20.0 @backstage/config-loader 1.1.5, 1.1.6 @backstage/config 1.0.4, 1.0.3 @backstage/core-app-api 1.1.1, 1.2.0 @backstage/core-components 0.11.2, 0.12.0, 0.9.5 @backstage/core-plugin-api 1.1.0, 1.0.7 @backstage/dev-utils 1.0.8 @backstage/errors 1.1.3, 1.1.2 @backstage/integration-react 1.1.5, 1.1.6 @backstage/integration 1.3.2, 1.4.0 @backstage/plugin-adr-backend 0.2.2 @backstage/plugin-adr-common 0.2.2 @backstage/plugin-adr 0.2.2 @backstage/plugin-api-docs 0.8.10 @backstage/plugin-app-backend 0.3.37 @backstage/plugin-auth-backend 0.17.0 @backstage/plugin-auth-node 0.2.6 @backstage/plugin-catalog-backend-module-github 0.1.8 @backstage/plugin-catalog-backend 1.5.0 @backstage/plugin-catalog-common 1.0.7, 1.0.8 @backstage/plugin-catalog-graph 0.2.22 @backstage/plugin-catalog-import 0.9.0 @backstage/plugin-catalog-node 1.2.0, 1.2.1 @backstage/plugin-catalog-react 1.2.0, 1.2.1 @backstage/plugin-catalog 1.6.0, 1.6.1 @backstage/plugin-cloudbuild 0.3.11 @backstage/plugin-github-actions 0.5.10 @backstage/plugin-home 0.4.27 @backstage/plugin-org 0.5.10 @backstage/plugin-permission-common 0.7.0, 0.7.1 @backstage/plugin-permission-node 0.7.0 @backstage/plugin-permission-react 0.4.6, 0.4.7 @backstage/plugin-proxy-backend 0.2.31 @backstage/plugin-scaffolder-backend 1.7.0 @backstage/plugin-scaffolder-common 1.2.1 @backstage/plugin-scaffolder 1.7.0 @backstage/plugin-search-backend-module-pg 0.4.1 @backstage/plugin-search-backend-node 1.0.3 @backstage/plugin-search-backend 1.1.0 @backstage/plugin-search-common 1.1.0, 1.1.1 @backstage/plugin-search-react 1.2.0, 1.2.1 @backstage/plugin-search 1.0.3 @backstage/plugin-stack-overflow 0.1.7 @backstage/plugin-tech-radar 0.5.17 @backstage/plugin-techdocs-backend 1.4.0 @backstage/plugin-techdocs-module-addons-contrib 1.0.5 @backstage/plugin-techdocs-node 1.4.1 @backstage/plugin-techdocs-react 1.0.6, 1.0.5 @backstage/plugin-techdocs 1.3.3 @backstage/plugin-todo-backend 0.1.35 @backstage/plugin-todo 0.2.13 @backstage/plugin-user-settings 0.5.0 @backstage/release-manifests 0.0.6 @backstage/test-utils 1.2.1, 1.2.2 @backstage/theme 0.2.16 @backstage/types 1.0.0, 1.0.1 @backstage/version-bridge 1.0.1, 1.0.2

👀 Have you spent some time to check if this bug has been raised before?

• I checked and didn’t find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

Are you willing to submit PR?

No, I don’t have time to work on this right now

[freben]

@ciprianna What they meant was, you need to ensure that the target system returns CORS headers, so that particular thing isn’t something that can be configured in Backstage itself. But that will be hard in this case without a proxy or something, since it’s a hosted cloud system.

[ciprianna]

@freben , thank you for clarifying and for your response. I was checking out the documentation for cloud build, and the retry is supposed to be a POST. So it’s not authorizing correctly because that route isn’t set up as a GET. If I add the method to the fetch request:

async reRunWorkflow(options) {
    await fetch(
      `https://cloudbuild.googleapis.com/v1/projects/${encodeURIComponent(
        options.projectId
      )}/builds/${encodeURIComponent(options.runId)}:retry`,
      {
        method: 'POST',
        headers: new Headers({
          Accept: "*/*",
          Authorization: `Bearer ${await this.getToken()}`,
        })
      }
    );
  }

then it works as expected with Google cloud build. I wonder if this is happening for anyone else, though? Is this only the case for my instance?