Missing v10.0.0 prebuilt packages for darwin-x64 and linux-arm

[mceachen]

GitHub failed a bunch of builds for that version due to what seems to be a pervasive network outage, and unfortunately the GitHub build pipeline doesn't seem to retry properly.

Any GHA experts out there? Is there a better way to get our pipeline to retry automatically to work around GHA flakiness? As it stands, it's pretty miserable.

[jlarmstrongiv]

Looks like the linux arm still needs to be rebuilt. I wish I had a solution for it too—npm install / npm ci has caused flakiness for me too.

From what I can tell, retrying pipelines is

• not built-in https://stackoverflow.com/questions/71574593/how-to-automatically-retry-github-action-jobs-on-failure
• requires extra boilerplate code https://gist.github.com/philip-gai/e3c02e68a32e8964fa3df2167b15cbff

[jlarmstrongiv]

Hey @mceachen,

I’ve been thinking about the GitHub flakiness for better-sqlite3 for a while now.

One other option is for someone to manually re-run the workflows. While it would be great if GitHub actions had automatic job retries or another way to solve the issue programmatically, I have found that I just normally re-run the workflows myself.

In my project, I use rolling dependency updates, and am notified when one fails, like better-sqlite3. For me, better-sqlite3 always fails because it takes hours for the prebuilds to be built and uploaded, which means I always manually re-run my workflow after the update anyway.

If you are open to granting me contributor rights to re-run workflows, I can check the better-sqlite3 workflows before I re-run my project workflows to ensure that every better-sqlite3 prebuild has completed successfully.

I completely understand if you are uncomfortable with assigning me contributor rights. I pledge to only use it to re-run workflows. Any changes I propose will continue to use your PR process. Unfortunately, I could not find any way to limit contributors to only running GitHub Actions.

Sometimes the easiest solution is a manual one. I would start by re-running this workflow https://github.com/WiseLibs/better-sqlite3/actions/runs/9048872914

[mceachen]

One other option is for someone to manually re-run the workflows

Unfortunately, in the past when I've tried to re-run any failing workflows, they don't seem to actually work--I don't know if it's missing prior task context or something else, but in any event, it seems that the only remedy is to create a new patch release and hope for the best.

As far as contributor rights, know that I've got quite restricted contributor access to this repo--you'd need to talk to @JoshuaWise who is the only admin for this project.

[jlarmstrongiv]

Unfortunately, in the past when I've tried to re-run any failing workflows, they don't seem to actually work--I don't know if it's missing prior task context or something else, but in any event, it seems that the only remedy is to create a new patch release and hope for the best.

Does it work if you re-run all workflows? Or would that cause npm publishing to fail when the version already exists?

If manual re-running the workflows won't solve the issue, then there's no reason to have permissions to do that.

If the manual route is the way we want to try, it may be possible to structure the workflows in a way that they can be re-run. Or, have a script to build and upload the prebuild from a local machine.

If not, maybe using the npm retry action on flaky actions like npm install could help. I'll try it on my project and see if it helps first. That command fails the most often for me.

Should I make a PR for a patch bump for the Linux arm build?

[mceachen]

Should I make a PR for a patch bump for the Linux arm build?

Sure: but I don't have sufficient permissions to merge it.

Also: @jlarmstrongiv @JoshuaWise if there's a way to do prebuilds, and only after that is successful, release the version to npm, that seems like it would be strictly better. Do we just flip the dependencies in the build.yml to make publish needs:prebuild (instead of the other way around)?

[JoshuaWise]

@mceachen Yup, and also add if: ${{ github.event_name == 'release' }} to prebuild. I agree this would be a good change

[mceachen]

Ugh, so, now the windows electron v26 arm build is failing: https://github.com/WiseLibs/better-sqlite3/actions/runs/9490136109/job/26153067563#step:10:527

D:\a\better-sqlite3\better-sqlite3\build\Release\obj\global_intermediate\sqlite3\sqlite3.c(24890,1): error C2099: initializer is not a constant [D:\a\better-sqlite3\better-sqlite3\build\deps\sqlite3.vcxproj]

Do we skip Electron v26? Is there a way to run this GHA job on a box we can shell into to see what's up with line 24890?

FWIW, this seems to be the most recent windows prebuild that passed: https://github.com/WiseLibs/better-sqlite3/actions/runs/8843277421/job/24283338714

Edit: neat, it’ll be fixed in the next release: https://github.com/WiseLibs/better-sqlite3/issues/1192#issuecomment-2164724590

[HyperSprite]

I'm just lurking but I don't know if this releases issues on darwin-x64 is related to flakiness because there hasn't been a single darwin-x64 on 10.x or 11.x.

Also hasn't worked since this PR landed.

[mceachen]

I'm just lurking but I don't know if this releases issues on darwin-x64 is related to flakiness because there hasn't been a single darwin-x64 on 10.x or 11.x.

Also hasn't worked since this PR landed.

Thanks for the link--I expect the two PRs I merged for v11.1.1 should remedy this.

~(Unfortunately, v11.1.1's GHA release failed again due to spotty network errors. I'll see if there's a way to automatically retry)~

v11.1.1 is now released (retrying failed jobs worked!)