Versions after 3.1171.0 not found in npm registry

[baparham]

It appears that versions after 3.1171.0 have not been published to, or are not showing up in the npmjs registry (https://www.npmjs.com/package/electron-releases)

From what I can tell looking at the actions, we've been failing to publish to NPM for a few releases, the latest being https://github.com/electron/releases/actions/runs/3291946158/jobs/5426728196#step:4:235

the last successful release workflow seemed to be https://github.com/electron/releases/actions/runs/3267548016/jobs/5372859060

What do you think about only pushing the bump commit and tag after publishing to NPM succeeds so the repo and npm don't diverge? I guess this may mean that NPM won't have the latest versions included of Electron, but that's no worse than the current situation, only that perhaps it would more quickly highlight that error to the team.

[baparham]

a couple stack overflow answers suggest it may be that the workflow needs an npm login first, but that doesn't explain why it's worked previously and is all of the sudden failing. Perhaps this is what this line in the release script is accomplishing already

[MarshallOfSound]

Some recent infrastructure changes may have invalidated a collection of npm access tokens.

E.g. https://github.com/electron/electron-api-historian/issues/59

Tbh this probably won't be fixed until next week at least

[baparham]

Thanks, that explains it!

[baparham]

Hey Samuel @MarshallOfSound , do you have any updates on if those npm tokens are getting refreshed and updated?

[baparham]

ping

[MarshallOfSound]

I'll be honest fixing this is high-effort and low-priority (this package has zero dependents on npm). Part of the reason it's not working is that we made the choice to require 2FA for all npm packages in the electron project. We have a system for using 2FA on CI but for something like this that publishes at a relatively high-frequency that's a lot of maintainer burden.

What's your specific usecase for this package that isn't served by the other ways we publish release metadata?

[baparham]

Thanks for the details, I can understand how that would be a challenge with the frequency this package is updated. Right now I'm using the direct git release link, but it makes it challenging to update the version with yarn automatically.

I'm trying to put together the soon to be one and only dependent in NPM, haha. I use electron-releases as a base to further query the chromium repo to determine what versions of compiled dependencies that tag of Chromium, and therefore, Electron depends on. The information I use for a specific Electron tagged release is pretty much just the deps object and nothing else:

{
  deps: {
    version: "...",
    chrome: "..",
    node: "...",
    v8: "...",
    uv: "...",
    zlib: "...",
    openssl: "..."
  }
}

I suppose I can look and see where this package gets those bits of metadata and bypass this package and go directly to the source, so I'll investigate that for now while I continue to use the git release tarballs in my package.json.

[MarshallOfSound]

https://artifacts.electronjs.org/headers/index.json is the number one source of truth, it's a single JSON file behind our artifact CDN so it's behind behind by a few seconds at most at any one point. It's what powers things (via some intermediate caching layers) like https://releases.electronjs.org

[baparham]

is that behind authentication? I can't see to access it :-(

[baparham]

<Error>
<Code>BlobNotFound</Code>
<Message>The specified blob does not exist. RequestId:45fd717a-601e-0099-77ef-03a0d2000000 Time:2022-11-29T12:36:24.7402370Z</Message>
</Error>

[erickzhao]

@baparham try https://electronjs.org/headers/index.json

[baparham]

perfect, thank you!

I have a suitable workaround for now, and this seems to have too low ROI to fix, so I'll close. Thanks for all the details and help finding the data I needed.