[kunalKumar-13]

Answering the question in #60 — "shouldn't there be an automatic fallback to build from source, and if so why isn't that working?"

There is one, and it is gated on macOS:

if (process.platform === 'darwin' && arch === 'arm64') {

So on an ARM64 Linux runner it never runs. fpm publishes no linux-arm64 asset — confirmed against the v0.13.0 release, which has linux-x86_64, macos-arm64, macos-x86_64 and windows-x86_64 and nothing else — so all six URLs the action tries return 404, on real hardware:

404  fpm-0.13.0-linux-arm64
404  fpm-0.13.0-linux-arm64-gcc-10 .. gcc-14

and the action stops with Error while trying to fetch fpm - please check that a version exists at the above release url, which points at the version rather than at the missing architecture.

What this changes

install.sh makes no assumption about the platform beyond a POSIX shell and a Fortran compiler — no uname, no OS branching — it bootstraps from the single-file fpm-0.8.0.F90 and builds the requested version with it. The same fallback that serves macOS ARM64 serves Linux ARM64, so the gate is widened to cover it and the messages now name the platform they are running on instead of hardcoding macOS and brew.

It also adds a return after that setFailed. Execution carried on to path.dirname(fpmPath) with fpmPath still undefined, so the real reason was buried under a second, unrelated error — visible in the screenshot on the issue:

The "path" argument must be of type string. Received undefined

Verification

Run on an Ubuntu 26.04 aarch64 VM by executing the action itself, not a simulation of it:

	result
main	exit 1, no fpm, both errors above
this branch	exit 0, No pre-built linux-arm64 binary found, falling back to building from source, fpm installed and added to path at ~/.local/bin

The installed binary is ELF 64-bit LSB pie executable, ARM aarch64, reports Version: 0.13.0, alpha, and fpm new demo --app && fpm run prints hello from project demo.

macOS ARM64 is unaffected — checked on an arm64 Mac, where fpm-0.13.0-macos-arm64-gcc-12 still downloads and the fallback is never reached.

The new Test-linux-arm64 job covers this on ubuntu-24.04-arm. I kept it out of the main matrix and pinned it to one version, because each run compiles fpm and multiplying it across the seven versions would be a lot of CI time for the same signal — happy to fold it into the matrix instead if you would rather have the coverage.

Note this does not remove the need for fortran-lang/fpm#1282; a published linux-arm64 binary would still be faster than building. This makes the runner work in the meantime.

Fixes #60

[bonachea]

Thanks for working on this!

Some minor suggestions for improvement on the implementation..

[bonachea]

It looks like you've cloned the entire job, mostly for the purpose of adding a single job to the matrix. This is probably unnecessary, as it's likely better to just add the single job and keep the rest of the job step factored.

You can do this using the jobs.<job_id>.strategy.matrix.include syntax. The code you want in the step above is something like this:

--- a/.github/workflows/test-workflow.yml
+++ b/.github/workflows/test-workflow.yml
@@ -10,10 +10,17 @@ jobs:
       matrix:
         os: [ubuntu-latest, macos-14, macos-15, windows-latest]
         fpm-version: ["v0.9.0", "v0.10.1", "v0.11.0", "v0.12.0", "v0.13.0", "latest", "current"]
         node-version: ["24.x"]
 
+        include:
+          # There is no linux-arm64 release asset, so every download in the action fails
+          # on this runner and only the build-from-source fallback can install fpm. Kept
+          # as a separate job with one version, because each run compiles fpm. See #60.
+          - os: ubuntu-24.04-arm
+            fpm-version: "v0.13.0"
+
     steps:
       - name: Checkout
         uses: actions/checkout@v5
 
       - name: Use Node.js ${{ matrix.node-version }}

[bonachea]

Hopefully this step is not actually necessary?

The Ubuntu2404-Arm64 runner already includes:

GNU Fortran: 12.4.0, 13.3.0, 14.2.0

The MacOS system setup step above to install gcc@12 is to fix a missing library dependency needed by the fpm binary on the macos runners, it has (almost) nothing to do with building from source.

[bonachea]

Why is this still conditional on platform?

IIUC If the binary downloads above already failed, that means we either build from source here or the entire action is going to fail.

IMO remove the platform gating entirely here. That makes the action more future-proof against changes in the fpm binary assets.

Suggested change

if ((process.platform === 'darwin' || process.platform === 'linux') && arch === 'arm64') {

[kunalKumar-13]

Thanks — all three taken, and the matrix one was clearly right; I'd cloned the job rather than thinking about include.

Folding into the matrix. Done, with one addition to your diff: I had to restate node-version in the include entry. ubuntu-24.04-arm isn't in the os list, so the entry can't be merged into an existing combination without overwriting os, and GitHub instead creates a new combination carrying only the keys named in the entry. matrix.node-version would have been empty for that job and actions/setup-node would have got a blank version. Restating it is the smallest fix; flagging it because it's easy to miss.

The gfortran step. You're right, gone. I'd pattern-matched it off the macOS step without checking the runner image, and as you say that one is about a runtime library the released binary links against, not about building. Ubuntu2404-Arm64 ships 12.4.0, 13.3.0 and 14.2.0 already.

The platform gate. Also gone. Your reasoning holds: by the time we reach that branch every download has failed, so the gate could only convert a possible success into a certain failure. And installFromSource already fails with a clear message when it can't find a usable gfortran, so removing the gate doesn't make a bad platform any more confusing than it was.

One thing to flag, since it's the one place I didn't simply follow the suggestion. Folding the job also removed its fpm new demo --app && fpm run step, which was the only thing proving the source-built binary actually executes — without it the arm64 job only shows the action exited 0. Rather than special-casing a step for one matrix entry, I added fpm --version for every combination:

      - name: Check that fpm runs
        run: fpm --version

That does mean 28 existing jobs now run a check they didn't before. I think that's a fair trade for a one-line universal smoke test, but it's your call — happy to gate it to the arm64 entry, or restore the fuller demo build there, if you'd rather keep the change narrow.

[bonachea]

LGTM! Thanks for the improvements!

To clarify, I'm not a maintainer of this action, I'm the user who originally reported the problem in #60. But I'm very happy to see a potential fix!

Now we need workflow approval and review from a maintainer, perhaps @perazz ?

[kunalKumar-13]

Thanks — and thanks for pushing back on the first version, the matrix suggestion in particular was clearly the right shape.

Confirming the state so a maintainer knows exactly what's needed rather than having to work it out: the Test workflow has two runs against this branch, both sitting at action_required:

completed / action_required   Test   2026-09-07T20:07
completed / action_required   Test   2026-09-10T21:42

So nothing has actually executed yet — this is the first-time-contributor gate, not a failure. Someone with write access needs to approve the run before there's any CI signal at all, and that includes the new ubuntu-24.04-arm matrix entry, which is the whole point of the change and the one job I can't verify locally.

I won't re-ping since you've already tagged @perazz. Happy to rebase or split it if that makes review easier.

[bonachea]

So nothing has actually executed yet — this is the first-time-contributor gate, not a failure. Someone with write access needs to approve the run

I agree a maintainer of this repo needs to approve the workflow before the pull_request event will run CI.

before there's any CI signal at all, and that includes the new ubuntu-24.04-arm matrix entry, which is the whole point of the change and the one job I can't verify locally.

This part is inaccurate: the CI has already run on your branch within your Github fork for the push action, where we can see the new entry is working as intended.

[kunalKumar-13]

You're right, and I should have looked at my own fork's runs before saying that. Thanks for the correction.

The push run does cover it, and it covers more than I'd credited — the ARM64 job exercises the whole path end to end:

21:42:45  No pre-built linux-arm64 binary found, falling back to building from source
21:49:17  Run fpm --version
21:49:17  Version:     0.13.0, alpha

So on ubuntu-24.04-arm every download fails, installFromSource runs, and about six and a half minutes later there is a working fpm on PATH. That is the change working, not just compiling — which is what the Check that fpm runs step was added for.

One thing that is genuinely still unverified, and I don't want to overstate this one either: only v0.13.0 runs on ARM, deliberately, since each ARM job builds from source. The old-version guard (< v0.9.0 → setFailed) has no ARM coverage. It's shared with the macOS ARM64 path that was already there and I didn't change its logic, only its message, so I left it at one entry rather than adding six more source builds to every run. Happy to add a v0.8.x ARM entry if you'd rather see that branch exercised too.

The pull_request runs still need a maintainer to approve them, but that's a formality now rather than the only signal.

[bonachea]

OK someone approved the pull_request action on Sept 11, which completed successfully, including the new Linux+ARM job.

Now we just need someone with repo write access to press the "Merge" button.

@perazz would you please do the honors? 😃

[perazz]

LGTM except the above comment, than you @kunalKumar-13 @bonachea

[bonachea]

@kunalKumar-13 why did you close this PR unmerged?

I believe the user-facing need addressed by this PR remains this unresolved, and this appears to be the correct approach...

[kunalKumar-13]

sorry, shouldn't have closed this, reopening. @perazz no known issue with older versions on arm, i only ran 0.13.0 there to keep ci short since every arm job builds from source. i'll add it to the matrix and see if the older ones build.

[bonachea]

LGTM!

@perazz please confirm this PR now satisfies your expressed concern?