Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Race condition in version information #717

Closed
2 of 5 tasks
domdomegg opened this issue Mar 15, 2023 · 2 comments · May be fixed by akv-platform/setup-node#16
Closed
2 of 5 tasks

Race condition in version information #717

domdomegg opened this issue Mar 15, 2023 · 2 comments · May be fixed by akv-platform/setup-node#16
Assignees
Labels
bug Something isn't working

Comments

@domdomegg
Copy link
Contributor

Description:
When a new node version is released, the list of versions at https://nodejs.org/dist/index.json is updated and the binaries are uploaded at https://nodejs.org/dist/v`VERSION` (e.g. https://nodejs.org/dist/v19.8.1/).

However, the website sits behind a Cloudflare cache and sometimes the data seems out of sync: the API responds saying there is a version, but the binaries are not available.

This then causes setup-node to fail.

Action version:
3.6.0

Platform:

  • Ubuntu
  • macOS
  • Windows

Runner type:

  • Hosted
  • Self-hosted

Tools version:
When using 'latest' or 'current' or 'node'.

Repro steps:

(depends on caching status of node site)

GitHub workflow:

name: Repro
on: push
jobs:
  repro:
    runs-on: ubuntu-latest
    steps:
      - name: Use Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '19.8.1'

Expected behavior:
Not entirely sure here. I think one of:

  1. Try to fallback to the next most recent version.
  2. Throw a clear error explaining the likely problem.

1 feels slightly risky: just because something has failed doesn't mean we should use a different version than the user might be expecting. Then again, the next most recent version might not be too bad. We could also limit this to only be for the case that the latest is unavailable AND it was released in the last day (so we know we're just covering this edge case - and people can't be too upset with a 1 day old version).

I'm leaning away from 2, if this will happen for each node release. It's very much unideal to break everyone's builds testing against the current version when new node versions come out: it makes using setup-node like this near unusable for people who want solid CI. 2 might be reasonable if through working with the nodejs team we can ensure their caching configuration is such that this happens more rarely.

Actual behavior:
Throws an unclear error, especially because of #714

@dmitry-shibanov
Copy link
Contributor

Hello @domdomegg. Thank you for your report. We'll investigate the issue.

@nikolai-laevskii
Copy link
Contributor

@domdomegg Thank you again for creating the issue! setup-node will now give a clear message for cases like this. We decided not to implement fallback for this particular scenario, as we wanted it to remain clear for the end user when his requested version does not install.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants