Failing CI check for devfile-web

[michael-valdron]

Which area this feature is related to?

/kind bug

Which area this bug is related to?

/area ci
/area registry-viewer
/area landing-page

What versions of software are you using?

Node.js project

Operating System and version:

Node.js version: 18

Yarn version: 1.22.19

Project.json:

Web browser

Operating System and version: N/A

Browser name and version: N/A

Bug Summary

Describe the bug:

CI / Main Job PR check is failing on both registry-viewer-e2e:e2e:production and landing-page-e2e:e2e:production tasks of the E2E step due to timing out. The reason for the timeouts is unclear however a new warning about insufficient disk space is likely pointing to the production builds not completing due to reduced disk space in GitHub actions.

To Reproduce:

Expected behavior

Any logs, error output, screenshots etc? Provide the devfile that sees this bug, if applicable

Full Log: https://github.com/devfile/devfile-web/actions/runs/8088608076

Warnings

You are running out of disk space. The runner will stop working when the machine runs out of disk space. Free space left: 26 MB

Error Message in E2E

Timed out waiting for the browser to connect. Retrying...

Timed out waiting for the browser to connect. Retrying again...

The browser never connected. Something is wrong. The tests cannot run. Aborting...

The browser never connected. Something is wrong. The tests cannot run. Aborting...
Warning: We failed processing this video.

This error will not alter the exit code.

TimeoutError: operation timed out
    at afterTimeout (/home/runner/.cache/Cypress/12.6.0/Cypress/resources/app/node_modules/bluebird/js/release/timers.js:46:19)
    at Timeout.timeoutTimeout [as _onTimeout] (/home/runner/.cache/Cypress/12.6.0/Cypress/resources/app/node_modules/bluebird/js/release/timers.js:76:13)
    at listOnTimeout (node:internal/timers:559:17)
    at process.processTimers (node:internal/timers:502:7)

  (Results)

  ┌────────────────────────────────────────────────────────────────────────────────────────────────┐
  │ Tests:        0                                                                                │
  │ Passing:      0                                                                                │
  │ Failing:      1                                                                                │
  │ Pending:      0                                                                                │
  │ Skipped:      0                                                                                │
  │ Screenshots:  0                                                                                │
  │ Video:        false                                                                            │
  │ Duration:     0 seconds                                                                        │
  │ Spec Ran:     app.cy.ts                                                                        │
  └────────────────────────────────────────────────────────────────────────────────────────────────┘

Additional context

Any workaround?

An alternative to keep this to one check is to use an alternative environment that allows for more disk space, i.e. An OpenShift CI prow job.

Suggestion on how to fix the bug

CI / Main Job check is large so splitting this down into different jobs could allot more disk space for the devfile-web builds.

[Jdubrick]

I don't have permissions to rerun the job for the PR where this issue started occuring here but running it on my fork it seems to be passing here with no changes. I'm wondering if there was a lot going on with the runner that day, for a sanity test if either of you has permissions to rerun would you be able to? I just want to be able to confirm if my fork actions are going to be accurate for testing any changes I make to the jobs to fix the issue (or if we use a self hosted runner with more storage)

cc @thepetk @michael-valdron

[thepetk]

I don't have permissions to rerun the job for the PR where this issue started occuring here but running it on my fork it seems to be passing here with no changes. I'm wondering if there was a lot going on with the runner that day, for a sanity test if either of you has permissions to rerun would you be able to? I just want to be able to confirm if my fork actions are going to be accurate for testing any changes I make to the jobs to fix the issue (or if we use a self hosted runner with more storage)

cc @thepetk @michael-valdron

It also needed to be rebased, so I've rebased it and fingers crossed now it passes!

[thepetk]

I don't have permissions to rerun the job for the PR where this issue started occuring here but running it on my fork it seems to be passing here with no changes. I'm wondering if there was a lot going on with the runner that day, for a sanity test if either of you has permissions to rerun would you be able to? I just want to be able to confirm if my fork actions are going to be accurate for testing any changes I make to the jobs to fix the issue (or if we use a self hosted runner with more storage)
cc @thepetk @michael-valdron

It also needed to be rebased, so I've rebased it and fingers crossed now it passes!

Yes I think it might be a bad day for the runner or a backported fix from a dependency (I'd say maybe electron). Now it passes!