Currently we don't upload the built packages to a Nix binary cache.

Doing so would allow greatly cutting down CI times and mean that pre-built binaries are always available from the cache when a user attempts to build or run any of our packages.

Follow-up to #61, similar to what we have at the sway repo: https://github.com/FuelLabs/sway/blob/master/.github/workflows/markdown-lint.yml

Follow-up to #61 and #66.

cc @adlerjohn, is it possible to allow the GitHub @actions-user special permissions to push to master?

This is how the nightly cron job workflow automates refreshing the set of manifests each night:

It was previously working before transferring the repo, but it looks like the repo protections block the direct push:

Push to branch master
Pushing to https://github.com/FuelLabs/fuel.nix.git
POST git-receive-pack (1626 bytes)
remote: error: GH006: Protected branch update failed for refs/heads/master.        
remote: error: At least 1 approving review is required by reviewers with write access.        
To https://github.com/FuelLabs/fuel.nix.git
 ! [remote rejected] HEAD -> master (protected branch hook declined)
error: failed to push some refs to 'https://github.com/FuelLabs/fuel.nix.git'
Error: Invalid exit code: 1
    at ChildProcess.<anonymous> (/home/runner/work/_actions/ad-m/github-push-action/master/start.js:29:21)
    at ChildProcess.emit (events.js:314:20)
    at maybeClose (internal/child_process.js:1022:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:287:5) {
  code: 1
}
Error: Invalid exit code: 1
    at ChildProcess.<anonymous> (/home/runner/work/_actions/ad-m/github-push-action/master/start.js:29:21)
    at ChildProcess.emit (events.js:314:20)
    at maybeClose (internal/child_process.js:1022:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:287:5)

https://github.com/FuelLabs/fuel.nix/actions/runs/3109748765/jobs/5040255324

Currently the refresh-manifests job only tests on the ubuntu runner before committing the new manifests.

This was fine when the repo was first created, as the flake was only targeted at Linux users. However, now that we aim to use this to distribute binaries for macOS users too, we should ensure all platforms pass to avoid letting platform-specific issues like #64 slip through the cracks.

This might be tricky as we'll want to split the job of running refresh-manifests and testing on all platforms into separate steps, but we need to make the manifests available from the first step to the next without actually committing them 🤔

We do not need rc channels anymore as we already have beta-4 channel active

We should be able to specify a known minimum Rust version in the package patches, rather than using a single Rust version across the entire flake. This is because:

1. Changing the Rust version will invalidate the existing cache for potentially hundreds of packages, requiring rebuilds.
2. It's not always guaranteed that new Rust versions will work with older versions as new soundness issues are addressed, etc.

We should allow for constructing the rust-platform via the rust-overlay per package. We should still try to avoid changing this too frequently in order to avoid needing too many builds of Rust.

One alternative might be to try to read the minimum Rust version from the Cargo.toml for each package, but this would require setting up all the Fuel repos' CI to guarantee that this is always valid. This would also likely complicate scripts/refresh_manifests.sh quite a bit.

One unanswered question: if two packages specify different Rust versions, the generated fuel-dev devShell might potentially bring both Rust versions into scope? Ideally we simply prefer the newer version in this case.

Having a table similar to the packages might make it easier to spot desired devShells.

Currently we only provide a snapshot of master that is pinned by the current state of the flake inputs listed under the flake.lock file.

Ideally we should also provide every published release along with any extra toolchain releases provided by fuelup (e.g. nightly).

The oxalica's rust-overlay achieves this nicely. We should look to it for inspiration.

This might involve using some CI automation to maintain an index of all necessary source inputs for each release.

TODO

• Write a script that can be used to generate a manifest for each package. Each should contain a specific git commit, a pre-computed sha256 hash, the date and time it was created, etc.
  • For published versions, use either git tags or releases from each repo.
  • For nightlies, use the git commit associated with each release:
  • Write all to a single manifest directory in a readable (for debugging), nix-serializable format like rust-overlay's here.
• Construct the packages set using the generated manifests.

This could look a lot like the rust-overlay cronjob.

nix shell github:fuellabs/fuel.nix#beta-4 should be nix shell github:fuellabs/fuel.nix#fuel-beta-4

The mkPackages function and patches.nix both make some assumptions based on the expectation that packages being built are Rust packages. This is fine for all fuel-core, sway and indexer packages, however these assumptions may need to be revisited if we aim to build non-Rust packages (e.g. NPM-based TS/JS stuff) in the future.

In order to enable building non-Rust packages, we should separate manifests by build process (e.g. buildRustPackage, buildNpmPackage, etc), either at the time of manifest creation, or by filtering them after their loaded using lists of names (e.g. one list of Rust package names, another list of NPM package names, etc).

E.g. the first condition under patches.nix should be revisited to ensure it is only applied for Rust-package manifests.

The cache https://mitchmindtree-fuellabs.cachix.org is currently generated and signed manually by @mitchmindtree. Ideally, this process should be automated via CI and signing should be done using a fuel service account key instead of a personal key.

E.g. here https://github.com/FuelLabs/fuel.nix/actions/runs/3634553835/jobs/6132748582#step:5:1043

Might need to explicitly increase the timeout duration for this CI step.

Basically the title. We should not wait for old jobs to finish if a new job is requested

Spotted while working on #61. See this comment.

It seems like the recent addition of the sysinfo crate in FuelLabs/sway#4564 may be causing issues on the macOS build of the latest forc-nightly and possibly some non-determinism.

Today's refresh-manifests job succeeded, however the current CI macos-latest matrix job is missing the cache, and failing with a linker error.

       >   = note: Undefined symbols for architecture x86_64:
       >             "_kCFURLVolumeAvailableCapacityForImportantUsageKey", referenced from:
       >                 _$LT$sysinfo..apple..disk..Disk$u20$as$u20$sysinfo..traits..DiskExt$GT$::refresh::ha090b62f02761b2b in libsysinfo-bfbd6883445a3969.rlib(sysinfo-bfbd6883445a3969.sysinfo.4f5fc5ae-cgu.15.rcgu.o)
       >                 sysinfo::apple::disk::get_disks::h63aaac400a8fb64f in libsysinfo-bfbd6883445a3969.rlib(sysinfo-bfbd6883445a3969.sysinfo.4f5fc5ae-cgu.15.rcgu.o)
       >           ld: symbol(s) not found for architecture x86_64
       >           clang-11: error: linker command failed with exit code 1 (use -v to see invocation)
       >           
       >
       > error: could not compile `forc` due to previous error
       For full logs, run 'nix log /nix/store/vgq1zhv6q43wbgbd5hifm26ab2wikwj9-forc-0.39.1.drv'.
error: 1 dependencies of derivation '/nix/store/jfxshavhlsxkkdfnjdqpxfcyjv1icj6f-fuel-nightly.drv' failed to build

Seems like GitHub recently added M1 hosted runners.

fuelup v0.21.0 adds beta-5 channel. We can take the commit hashes from there to create the new derivation. We should also update docs to point people to the beta-5 derivation by default.

This would give us a couple of benefits:

• Ensure the flake works across all supported platforms.
• Ensure a binary for every supported target is always available from the Nix cache.

It would be nice to have the Sway vs code extension available through either the Fuel flake or the Nix pkg directory.

A reminder to re-add the following job once this upstream issue is resolved:

  nix-flake-check:
    needs: cancel-previous-runs
    runs-on: ubuntu-latest
    steps:
      - uses: actions/[email protected]
      - uses: cachix/install-nix-action@v16
        with:
          nix_path: nixpkgs=channel:nixos-unstable
      - uses: cachix/cachix-action@v10
        with:
          name: mitchmindtree-fuellabs
          authToken: '${{ secrets.CACHIX_AUTH_TOKEN }}'
      - run: nix flake check --no-update-lock-file

Currently, we still check builds for each package, but the nix flake check is useful for quickly checking the validity of the flake itself for all targets.

For the last couple of days macos ci steps seems to be failing because of an upgrade done to macos-latest image. Luckily upstream is already have the fix merged and released.

When running nix build .#fuel-core, we currently get as far as the ethers-middleware before compilation fails. The error appear to be related to use of an EthEvent derive macro:

Compiling ethers-middleware v0.13.0
error[E0433]: failed to resolve: use of undeclared crate or module `ethers`
   --> /build/fuel-core-vendor.tar.gz/ethers-middleware/src/transformer/ds_proxy/factory.rs:114:52
    |
114 |     #[derive(Clone, Debug, Default, Eq, PartialEq, EthEvent)]
    |                                                    ^^^^^^^^ use of undeclared crate or module `ethers`
    |
    = note: this error originates in the derive macro `EthEvent` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0433]: failed to resolve: use of undeclared crate or module `ethers`
   --> /build/fuel-core-vendor.tar.gz/ethers-middleware/src/transformer/ds_proxy/factory.rs:114:52
    |
114 |     #[derive(Clone, Debug, Default, Eq, PartialEq, EthEvent)]
    |                                                    ^^^^^^^^ not found in `ethers::core::abi`
    |
    = note: this error originates in the derive macro `EthEvent` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider importing this enum
    |
35  |     use ethers_core::abi::ParamType;
    |
help: if you import `ParamType`, refer to it directly
    |
114 -     #[derive(Clone, Debug, Default, Eq, PartialEq, EthEvent)]
114 +     #[derive(Clone, Debug, Default, Eq, PartialEq, EthEvent)]
    | 

error[E0433]: failed to resolve: use of undeclared crate or module `ethers`
   --> /build/fuel-core-vendor.tar.gz/ethers-middleware/src/transformer/ds_proxy/factory.rs:117:9
    |
117 |         #[ethevent(indexed)]
    |         ^ not found in `ethers::core::abi`
    |
help: consider importing this trait
    |
35  |     use ethers_core::abi::Tokenizable;
    |
help: if you import `Tokenizable`, refer to it directly
    |
114 -     #[derive(Clone, Debug, Default, Eq, PartialEq, EthEvent)]
114 +     #[derive(Clone, Debug, Default, Eq, PartialEq, )]
    | 

error[E0433]: failed to resolve: use of undeclared crate or module `ethers`
   --> /build/fuel-core-vendor.tar.gz/ethers-middleware/src/transformer/ds_proxy/factory.rs:119:9
    |
119 |         #[ethevent(indexed)]
    |         ^ not found in `ethers::core::abi`
    |
help: consider importing this trait
    |
35  |     use ethers_core::abi::Tokenizable;
    |
help: if you import `Tokenizable`, refer to it directly
    |
114 -     #[derive(Clone, Debug, Default, Eq, PartialEq, EthEvent)]
114 +     #[derive(Clone, Debug, Default, Eq, PartialEq, )]
    | 

error[E0433]: failed to resolve: use of undeclared crate or module `ethers`
   --> /build/fuel-core-vendor.tar.gz/ethers-middleware/src/transformer/ds_proxy/factory.rs:121:9
    |
121 |         pub proxy: Address,
    |         ^^^ not found in `ethers::core::abi`
    |
help: consider importing this trait
    |
35  |     use ethers_core::abi::Tokenizable;
    |
help: if you import `Tokenizable`, refer to it directly
    |
114 -     #[derive(Clone, Debug, Default, Eq, PartialEq, EthEvent)]
114 +     #[derive(Clone, Debug, Default, Eq, PartialEq, )]
    |

And so on.

Curiously, when entering the fuel-core developer shell (i.e. nix develop .#fuel-core) the build completes successfully.

It would be worth investigating whatever crate provides the EthEvent derive macro.

The fuel-indexer packages are no longer building due to the use of a git branch in their build process to get WASM support working. I have a WIP attempt at adding output hashes here, but it errors out due to an "error inheriting version from workspace root".

error: builder for '/nix/store/58vmn7n7wda25ypbn2a15yf5vinihdwl-forc-index-0.3.0.drv' failed with exit code 101;
       last 10 log lines:
       >   failed to update replaced source registry `crates-io`
       >
       > Caused by:
       >   failed to parse manifest at `/build/cargo-vendor-dir/fuels-signers-0.36.1/Cargo.toml`
       >
       > Caused by:
       >   error inheriting `version` from workspace root manifest's `workspace.package.version`
       >
       > Caused by:
       >   failed to find a workspace root
       For full logs, run 'nix log /nix/store/58vmn7n7wda25ypbn2a15yf5vinihdwl-forc-index-0.3.0.drv'.

For now I'm going to filter out fuel-indexer pkgs following 2023-02-22, but will add an end date to this filter once indexer switches back to crates.io deps.

This has been added to fuelup and needs to be added to here also FuelLabs/fuelup#454

This would be useful for dropping into test-net compatible dev environments.

These will likely need to be specified manually within mkPackages.

Alternatively, we could make define a pkgsets.nix that declares these sets with name and pkg versions. E.g.

{
    # Fuel beta-1 test net.
    beta-1 = {
        # ...
    };

    # Fuel beta-2 test net.
    beta-2 = {
        forc = "0.31";
        forc-client = "0.31";
        forc-explore = "0.28";
        forc-fmt = "0.31";
        fuel-core = "0.14.1";
        # ...
    };

    # ...
}

These sets could be used to select the latest compatible patch release for each package for each set, and provide a fuel-<set> package set for each (e.g. fuel-beta-1, fuel-beta-2, etc).

Follow-up to #53, see #53 for details.

Potentially as a result of #81 since that's the only change that has landed since they were working.

I'm unable to use any of the devShells on a fresh install of NixOS due to the following error:

error: undefined variable 'forc-explore-nightly'

       at /nix/store/bh2bzdnjwa139j60a532w4f2ji2myp48-source/flake.nix:209:11:

          208|           forc-client-nightly
          209|           forc-explore-nightly
             |           ^
          210|           forc-fmt-nightly
(use '--show-trace' to show detailed location information)

We will default to use either mine or Kaya's machine for this. If their machine is down for any reason then the backup machine should be used.

Relevant resources: https://nixos.org/guides/cross-compilation.html
I think crossSystem argument set to aarch64-darwin running on a macos-latest runner should work.
sway repo has an example of building Rust packages (without Nix) for aarch64-darwin.

Currently we only provide a fuel-dev development shell. This is useful for working on the fuel tools, but does not provide the tools themselves.

We should also provide a fuel devShell that provides all fuel tools under one shell (e.g. fuel-core, forc, all forc plugins, etc). This would be useful for users building Sway applications.

We may also want to add a dedicated devShell here as I think fuel-indexer might have lots of environment dependencies related to dbs, wasm, etc.

following the installation steps and then trying to build the sway repo results in:

sway % cargo build
error: package `fuels v0.44.0` cannot be built because it requires rustc 1.70.0 or newer, while the currently active rustc version is 1.68.0
Either upgrade to rustc 1.70.0 or newer, or use
cargo update -p [email protected] --precise ver
where `ver` is the latest version of `fuels` supporting rustc 1.68.0

forc-crypto is missing from the nix flake, we should add it as it is an "officially" distributed tool now.

We recently moved from offering latest channels as default to offering beta channels from fuelup, we should aim to keep things coherent and make fuel.nix docs point out to latest beta network by default. If someone is copy pasting quick start they should get the latest beta network as they do now for fuelup.

As of #61, we publish the new book to gh-pages, though we still need to enable nix.fuel.network.

I'm not sure if the fuellabs.github.io/fuel.nix link should start working automatically at some point, but we might want to ensure this link works going forward too?

Motivation

The Determinate Systems nix-installer tool provides an opinionated and much simpler installation process that nicely aligns with the way fuel.nix encourages using Nix.

Namely, it enables the flakes and nix-command features by default, provides a much more concise installation plan description, and also offers non-interactive installation options. The tool is built in Rust, and also plans to provide the tool as a library, which also makes Nix a strong candidate as a basis for fuelup.

Implementation

In a single command, users can install Nix and enable our binary cache with something like the following:

curl --proto '=https' --tlsv1.2 -sSf -L https://install.determinate.systems/nix | sh -s -- install --extra-conf "extra-substituters = https://mitchmindtree-fuellabs.cachix.org" --extra-conf "extra-trusted-public-keys = mitchmindtree-fuellabs.cachix.org-1:UDUQvwjM3wRCZe1chrgqAehb3M0M5x9qjpEwJwPn7Ik="

I've been unable to confirm this works yet as the --extra-conf flags are currently not working (on nix-installer v0.8.0) due to DeterminateSystems/nix-installer#427, however this has since been fixed in DeterminateSystems/nix-installer#456 and should become available as a part of the upcoming v0.8.1 release.

Once this version is released and the installation process can be confirmed to succeed on a fresh Ubuntu VM along with fetching the latest fuel binaries from successfully from cache, we should update the README with this recommended approach.

There should be 1 book where developers can go to find information about how to get forc & fuel-core installed instead of having separate books for fuel.nix and fuelup.

For some reason, binaries for every system are being built from source when given all of the proper links to the cache. This means long install times for nix profile install, defeating the purpose of the cache.

Figure out why the cache isn't being used and update documentation so users won't experience long install times.

Rocksdb takes up the majority of the fuel-core dev build times. If we could use a dylib for rocksdb that would greatly improve the developer flow.

The build script for rocksdb looks for an env var ROCKSDB to be set to the path of where to link rocksdb from, otherwise it will build it from sources.

Build script: https://github.com/rust-rocksdb/rust-rocksdb/blob/v0.19.0/librocksdb-sys/build.rs#L363

The version of rocksdb we need to load appears to be configured here:
https://github.com/rust-rocksdb/rust-rocksdb/blob/v0.19.0/librocksdb-sys/build_version.cc#L12

An added benefit is that we would likely no longer require clang to be installed in the dev shell if we don't need to build rocksdb from source.

Credit to @freesig for this idea of using nix to help with build caching!

the link in here https://github.com/FuelLabs/fuel.nix doesn't work

@mitchmindtree mentioned that nix flake show can tell us which packages would be changed by refresh-manifest.sh.

We could add this to PRs to show this output to help us catch any issues with patch changes.

In the last successful refresh-manifests action, this step (which only runs on ubuntu-latest, see #70) introduces the forc-nightly version that has been failing on macos-latest CI recently (see #64).

I would have expected the refresh-cache step that follows to have failed, however on closer inspection the macos-latest fuel-nightly job that followed fetches everything directly from cache and doesn't rebuild anything despite the new manifests.

This indicates that the refresh-cache job is likely using master in the state it was in when the whole workflow began and not the new state of master that was committed by the preceding refresh-manifests job.

This explains why we didn't see any CI failure until the next night's refresh-manifests pass where the refresh-cache step did fail.

It's likely best to address this as a part of #70.

The final steps of #6.

Update script/refresh-manifests.sh to also generate nightlies. Use a similar approach to published versions, but rather than selecting the commit via git tag, for each supported date, select the first commit that precedes midnight for each date.

This would give us an idea of whether fuel.nix could be a viable replacement for fuelup in CI, in terms of latency to install forc.

I tried to compile fuel-core using the fuel-core-dev shell, but I get the following error. Am I missing something?

Just a reminder that a while back we turned off the requirement for 1 review approval in order to allow the nightly refresh-manifests to commit directly to master.

We should find some way to re-enable it while permitting the github actions user to continue to push directly to master if possible.

@sdankel mentioned she found this option which might be useful for enabling this: