The fpm binary gets interrupted at the CI (macOS) about fpm HOT 12 CLOSED

I implemented a workaround in #20. The problem with GitHub Actions is that you cannot just restart a single build, you have to restart all the builds. The other issue is that it was already failing a lot with just 3 tests. Once we have hundreds of tests, it might end up failing all the time. For now the workaround implemented in #20 should make the CI robust enough for now. But we'll have to get back to this and fix it.

The reason I spent so much time on this is that I thought I can use "bisection" to create a minimal example that fails, and figure it out. But I failed. Essentially it's extremely unreliable to trigger the bug by submitting 20 commits. Sometimes they all pass, and sometimes they get 4 failures. And I haven't figured out a minimal example that can reliably trigger it in 20 runs. As I start removing things, the failures become less and less frequent.

If #20 doesn't give us reliable CI, then we can switch the macOS build to Azure pipelines or Travis-CI.

But having a reliable CI is a must.

from fpm.

And here it failed in master (https://github.com/fortran-lang/fpm/runs/391281163) after merging #15 that passed. So we have to figure this out.

from fpm.

Is there anybody with a Mac that can reproduce this locally?

from fpm.

I tried it on a macOS yesterday locally, and I can't reproduce it. So we have to Debug it at the CI itself (as I have done in #14), which is quite time consuming.

from fpm.

As reported in #18 (comment), the process gets interrupted with signal 9 (SIGKILL). I suspected that above, but it's nice to have a proof. For some reason macOS kills the fpm process.

from fpm.

This might be a bug at GitHub, so I reported it at https://github.community/t5/GitHub-Actions/GitHub-Actions-on-macOS-randomly-kill-my-test-program/m-p/43526#M5414.

from fpm.

I am trying to reliably reproduce this bug in certik#1.

from fpm.

One approach to fix this is to do cargo test || cargo test. An example where the first one fails, but the second one succeeds is https://github.com/certik/fpm/runs/396031403.

from fpm.

This is precisely the kind of issue I am a bit worried with Rust, that the toolchain is not mature enough and will produce binaries that do not work (but only sometimes!). The closest error that I was able to find is:

golang/go#19734

from fpm.

But this likely has more to do with GitHub Actions than Rust itself. Neither you nor the person from the GitHub Forum could reproduce it locally, correct?

I agree it's very important to have fpm work on all 3 major platforms, but I wonder if it's a bit too early to focus Mac OS work 100% of the time? Why not let it fail sometimes? We can manually trigger the build when it does fail.

from fpm.

I reported it in the Rust community also: https://users.rust-lang.org/t/github-actions-randomly-kill-a-test-program/37255

from fpm.

I think #29 fixed this issue.

from fpm.