Missing v10.0.0 prebuilt packages for darwin-x64 and linux-arm about better-sqlite3 HOT 7 OPEN

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

from better-sqlite3.

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.

from better-sqlite3.

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

from better-sqlite3.

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.

from better-sqlite3.

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?

from better-sqlite3.

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)?

from better-sqlite3.

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

from better-sqlite3.