CI is broken: workflows reference a missing scripts/build_lib.sh and make targets that don't exist in the repo #38

New issue

Open

opened 2026-05-12 08:06:50 +00:00 by rawan · 1 comment

rawan commented 2026-05-12 08:06:50 +00:00

Member

Copy link

Summary

Every Forgejo Actions workflow in .forgejo/workflows/ sources scripts/build_lib.sh and/or invokes make, but the repository contains neither a scripts/ directory nor a Makefile. As a result build.yaml — which runs on every push — fails immediately, and the tag-triggered build-linux.yaml / build-macos.yaml / release.yaml workflows are also dead.

Evidence

.forgejo/workflows/build.yaml:

- name: Build, test, and check
  run: |
    source scripts/build_lib.sh
    make check test fmt-check
- name: Build release
  run: |
    source scripts/build_lib.sh
    make build

.forgejo/workflows/build-linux.yaml and build-macos.yaml likewise do source scripts/build_lib.sh and call setup_linux_toolchain / build_binaries / publish_binaries / forge_config from it.

But:

$ ls scripts/
ls: cannot access 'scripts/': No such file or directory
$ ls Makefile
ls: cannot access 'Makefile': No such file or directory

There are also no *.nu scripts, despite README.md claiming "All lifecycle management uses Nu shell service scripts only" and "No Makefiles or bash scripts".

Impact

• CI is red on every push; build.yaml cannot pass.
• No release artifacts can ever be produced from tags.
• Contributors get no automated build/test/fmt feedback.

Suggested fix

Pick one and make it consistent across README + workflows:

1. Add the scripts/build_lib.sh helper (with setup_linux_toolchain, build_binaries, publish_binaries, forge_config, bin_dir) and a Makefile with check, test, fmt-check, build targets — i.e. restore what the workflows expect; or
2. Rewrite the workflows to call cargo directly (cargo fmt --check, cargo clippy, cargo test --workspace, cargo build --release --workspace) and drop the scripts/build_lib.sh dependency.

release.yaml already does (2) inline, so option (2) is the smaller change.

## Summary Every Forgejo Actions workflow in `.forgejo/workflows/` sources `scripts/build_lib.sh` and/or invokes `make`, but the repository contains **neither a `scripts/` directory nor a `Makefile`**. As a result `build.yaml` — which runs on every `push` — fails immediately, and the tag-triggered `build-linux.yaml` / `build-macos.yaml` / `release.yaml` workflows are also dead. ## Evidence `.forgejo/workflows/build.yaml`: ```yaml - name: Build, test, and check run: | source scripts/build_lib.sh make check test fmt-check - name: Build release run: | source scripts/build_lib.sh make build ``` `.forgejo/workflows/build-linux.yaml` and `build-macos.yaml` likewise do `source scripts/build_lib.sh` and call `setup_linux_toolchain` / `build_binaries` / `publish_binaries` / `forge_config` from it. But: ``` $ ls scripts/ ls: cannot access 'scripts/': No such file or directory $ ls Makefile ls: cannot access 'Makefile': No such file or directory ``` There are also no `*.nu` scripts, despite `README.md` claiming "All lifecycle management uses Nu shell service scripts only" and "No Makefiles or bash scripts". ## Impact - CI is red on every push; `build.yaml` cannot pass. - No release artifacts can ever be produced from tags. - Contributors get no automated build/test/fmt feedback. ## Suggested fix Pick one and make it consistent across README + workflows: 1. Add the `scripts/build_lib.sh` helper (with `setup_linux_toolchain`, `build_binaries`, `publish_binaries`, `forge_config`, `bin_dir`) and a `Makefile` with `check`, `test`, `fmt-check`, `build` targets — i.e. restore what the workflows expect; **or** 2. Rewrite the workflows to call `cargo` directly (`cargo fmt --check`, `cargo clippy`, `cargo test --workspace`, `cargo build --release --workspace`) and drop the `scripts/build_lib.sh` dependency. `release.yaml` already does (2) inline, so option (2) is the smaller change.

rawan commented 2026-05-12 10:07:40 +00:00

Author

Member

Copy link

Analysis

Every .forgejo/workflows/ file except release.yaml depends on two missing resources:

• scripts/build_lib.sh — sourced at the top of every step, providing shell functions (setup_linux_toolchain, build_binaries, publish_binaries, forge_config, bin_dir)
• Makefile — expected by build.yaml with targets check, test, fmt-check, build

Neither scripts/ nor Makefile exist in the repository. This causes CI to fail on every push and every tag.

release.yaml already sidesteps both dependencies: it calls cargo directly, manages toolchains with rustup target add, and uploads release artifacts via raw curl calls to the Forgejo API. This makes option 2 (rewrite workflows to use cargo directly) the consistent, smaller fix.

Proposed Changes

1. build.yaml — Build and Test (push / manual)

Replace the two source scripts/build_lib.sh / make steps with direct cargo invocations:

- name: Check formatting
  run: cargo fmt --check

- name: Lint
  run: cargo clippy --workspace -- -D warnings

- name: Test
  run: cargo test --workspace

- name: Build
  run: cargo build --release --workspace

Keep the Install system dependencies step (capnproto). Remove the Build, test, and check and Build release steps entirely. Remove the permissions: contents: write line (not needed for CI-only runs).

Specific changes:

• Delete lines 16-30 (the two run sections that source build_lib.sh)
• Add the four new step entries above (or merge into fewer steps)
• Optionally drop contents: write from permissions

2. build-linux.yaml — Tag/Manual Release Build (Linux, cross-compile)

Replace every source scripts/build_lib.sh dependency with inline equivalents, mirroring release.yaml.

build_lib.sh function	Replacement
setup_linux_toolchain "${{ matrix.target }}"	rustup target add ${{ matrix.target }} (already works inside the builder container)
build_binaries "${{ matrix.target }}"	cargo build --release --workspace --target ${{ matrix.target }}
forge_config	Not needed — release upload uses ${{ github.token }} directly, same as release.yaml
bin_dir "${{ matrix.target }}"	Hardcode as target/${{ matrix.target }}/release (cross) or target/release (native)
publish_binaries "${{ matrix.artifact }}"	Inline curl POST per binary, same pattern as release.yaml

Step-by-step changes:

1. Setup toolchain step: replace source scripts/build_lib.sh / setup_linux_toolchain with rustup target add ${{ matrix.target }}
2. Add a Source cargo env preamble before each cargo command (same as release.yaml does)
3. Build step: replace with cargo build --release --workspace --target ${{ matrix.target }}
4. Publish step: replace forge_config / bin_dir / publish_binaries with the same inline curl release-asset-upload pattern from release.yaml. Use BINARIES: "myfs myfs-hub myfs-tool" as an env var. Use ${{ github.token }} instead of secrets.FORGEJO_TOKEN (consistent with release.yaml).
5. Switch FORGEJO_TOKEN to ${{ github.token }}

3. build-macos.yaml — Tag/Manual Release Build (macOS)

Same approach as build-linux.yaml but simpler (no cross-compilation, runs on host):

- name: Build
  run: |
    set -e
    source $HOME/.cargo/env || true
    cargo build --release --workspace
    BIN_DIR="target/release"
    for bin in myfs myfs-hub myfs-tool; do
      if [ ! -f "${BIN_DIR}/${bin}" ]; then
        echo "ERROR: Binary ${BIN_DIR}/${bin} not found"
        exit 1
      fi
      strip "${BIN_DIR}/${bin}"
    done

- name: Publish
  env:
    FORGEJO_TOKEN: ${{ github.token }}
  run: |
    set -e
    BIN_DIR="target/release"
    for bin in myfs myfs-hub myfs-tool; do
      curl -s -X POST \
        -H "Authorization: token $FORGEJO_TOKEN" \
        -H "Accept: application/json" \
        -H "Content-Type: application/x-pie-executable" \
        --data-binary @"${BIN_DIR}/${bin}" \
        "${{ github.server_url }}/api/v1/repos/${{ github.repository }}/releases/${{ steps.create-release.outputs.release_id }}/assets?name=${bin}-darwin-arm64"
    done

Note: build-macos.yaml currently references darwin-arm64 as a hardcoded artifact name. The publish step above preserves that.

4. No changes to release.yaml

It already works correctly. Leave it as-is.

Implementation Notes

• The builder container image (ghcr.io/despiegk/builder:latest) already has Rust toolchain installed — the source $HOME/.cargo/env guard is enough.
• capnproto, musl-dev, musl-tools system deps must remain in the Install system dependencies steps where needed.
• The BINARIES env var "myfs myfs-hub myfs-tool" is derived from release.yaml and the workspace members (myfs-tool, myfs-hub, plus the myfs binary provided by one of the member crates).
• After the workflow changes, update the README.md section about "Nu shell service scripts only" / "No Makefiles or bash scripts" to reflect the actual state (no Makefile, no Nu scripts — just workflows that call cargo directly).
• Option 1 (create scripts/build_lib.sh + Makefile) is NOT recommended — it would add 100+ lines of shell code that duplicate what cargo already does, and would be inconsistent with the pattern in release.yaml.

## Analysis Every `.forgejo/workflows/` file except `release.yaml` depends on two missing resources: - `scripts/build_lib.sh` — sourced at the top of every step, providing shell functions (`setup_linux_toolchain`, `build_binaries`, `publish_binaries`, `forge_config`, `bin_dir`) - `Makefile` — expected by `build.yaml` with targets `check`, `test`, `fmt-check`, `build` Neither `scripts/` nor `Makefile` exist in the repository. This causes CI to fail on every push and every tag. `release.yaml` already sidesteps both dependencies: it calls `cargo` directly, manages toolchains with `rustup target add`, and uploads release artifacts via raw `curl` calls to the Forgejo API. This makes option 2 (rewrite workflows to use `cargo` directly) the consistent, smaller fix. ## Proposed Changes ### 1. `build.yaml` — Build and Test (push / manual) Replace the two `source scripts/build_lib.sh` / `make` steps with direct `cargo` invocations: ```yaml - name: Check formatting run: cargo fmt --check - name: Lint run: cargo clippy --workspace -- -D warnings - name: Test run: cargo test --workspace - name: Build run: cargo build --release --workspace ``` Keep the `Install system dependencies` step (capnproto). Remove the `Build, test, and check` and `Build release` steps entirely. Remove the `permissions: contents: write` line (not needed for CI-only runs). **Specific changes:** - Delete lines 16-30 (the two `run` sections that source `build_lib.sh`) - Add the four new step entries above (or merge into fewer steps) - Optionally drop `contents: write` from `permissions` ### 2. `build-linux.yaml` — Tag/Manual Release Build (Linux, cross-compile) Replace every `source scripts/build_lib.sh` dependency with inline equivalents, mirroring `release.yaml`. | `build_lib.sh` function | Replacement | |---|---| | `setup_linux_toolchain "${{ matrix.target }}"` | `rustup target add ${{ matrix.target }}` (already works inside the builder container) | | `build_binaries "${{ matrix.target }}"` | `cargo build --release --workspace --target ${{ matrix.target }}` | | `forge_config` | Not needed — release upload uses `${{ github.token }}` directly, same as `release.yaml` | | `bin_dir "${{ matrix.target }}"` | Hardcode as `target/${{ matrix.target }}/release` (cross) or `target/release` (native) | | `publish_binaries "${{ matrix.artifact }}"` | Inline curl POST per binary, same pattern as `release.yaml` | **Step-by-step changes:** 1. `Setup toolchain` step: replace `source scripts/build_lib.sh` / `setup_linux_toolchain` with `rustup target add ${{ matrix.target }}` 2. Add a `Source cargo env` preamble before each cargo command (same as `release.yaml` does) 3. `Build` step: replace with `cargo build --release --workspace --target ${{ matrix.target }}` 4. `Publish` step: replace `forge_config` / `bin_dir` / `publish_binaries` with the same inline curl release-asset-upload pattern from `release.yaml`. Use `BINARIES: "myfs myfs-hub myfs-tool"` as an env var. Use `${{ github.token }}` instead of `secrets.FORGEJO_TOKEN` (consistent with `release.yaml`). 5. Switch `FORGEJO_TOKEN` to `${{ github.token }}` ### 3. `build-macos.yaml` — Tag/Manual Release Build (macOS) Same approach as `build-linux.yaml` but simpler (no cross-compilation, runs on host): ```yaml - name: Build run: | set -e source $HOME/.cargo/env || true cargo build --release --workspace BIN_DIR="target/release" for bin in myfs myfs-hub myfs-tool; do if [ ! -f "${BIN_DIR}/${bin}" ]; then echo "ERROR: Binary ${BIN_DIR}/${bin} not found" exit 1 fi strip "${BIN_DIR}/${bin}" done - name: Publish env: FORGEJO_TOKEN: ${{ github.token }} run: | set -e BIN_DIR="target/release" for bin in myfs myfs-hub myfs-tool; do curl -s -X POST \ -H "Authorization: token $FORGEJO_TOKEN" \ -H "Accept: application/json" \ -H "Content-Type: application/x-pie-executable" \ --data-binary @"${BIN_DIR}/${bin}" \ "${{ github.server_url }}/api/v1/repos/${{ github.repository }}/releases/${{ steps.create-release.outputs.release_id }}/assets?name=${bin}-darwin-arm64" done ``` Note: `build-macos.yaml` currently references `darwin-arm64` as a hardcoded artifact name. The publish step above preserves that. ### 4. No changes to `release.yaml` It already works correctly. Leave it as-is. ## Implementation Notes - The builder container image (`ghcr.io/despiegk/builder:latest`) already has Rust toolchain installed — the `source $HOME/.cargo/env` guard is enough. - `capnproto`, `musl-dev`, `musl-tools` system deps must remain in the `Install system dependencies` steps where needed. - The `BINARIES` env var `"myfs myfs-hub myfs-tool"` is derived from `release.yaml` and the workspace members (`myfs-tool`, `myfs-hub`, plus the `myfs` binary provided by one of the member crates). - After the workflow changes, update the `README.md` section about "Nu shell service scripts only" / "No Makefiles or bash scripts" to reflect the actual state (no Makefile, no Nu scripts — just workflows that call cargo directly). - Option 1 (create scripts/build_lib.sh + Makefile) is NOT recommended — it would add 100+ lines of shell code that duplicate what cargo already does, and would be inconsistent with the pattern in `release.yaml`.

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

development

development_38-fix-ci-workflows

development_39-fix-mapdb-stub

development_40-fix-docker-build

new-arch

main

v0.0.3

v0.0.2

v0.0.1

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

geomind_code/my_fs#38

No description provided.