The latest channel

The latest channel is updated by a scheduled GitHub workflow that runs every 30 minutes and checks for new, compatible releases of forc and fuel-core.

The latest channel is fuelup's default channel. It provides access to the latest compatible, published releases of forc and fuel-core.

When installing the latest channel, fuelup will refer to the channel-fuel-latest.toml file published within the fuelup repository in the gh-pages branch to determine the set of forc and fuel-core versions to retrieve. The versions in this file are updated by a scheduled GitHub workflow that runs once every 30 minutes and performs the following steps:

  1. Checks for newly published versions of forc and fuel-core.
  2. Tests compatibility of new versions against a set of integration tests.
  3. Selects the latest set of versions that successfully pass the tests.
  4. Publishes the selected versions to the channel-fuel-latest.toml manifest.

Developer Guide

Understanding the latest workflow


Reading the information below is only really necessary if you wish to contribute to the workflows or want a deeper understanding on how channels are updated.

The entrypoint of the scheduled workflow is within index-versions.yml. We run the Rust script compare-versions to collect versions of forc and fuel-core to be tested. These versions are filtered for incompatible versions prior to being used as a JSON string input to test-toolchain-compatibility.yml, where the testing occurs.

In test-toolchain-compatibility.yml, The versions JSON string input is used to init a matrix using the fromJSON expression. We checkout the Sway repo at the given forc version and pull the fuel-core Docker image at the given fuel-core version and run integration tests found in the Sway CI for them.

Note that we only mark versions as incompatible specifically if tests fail, and not if other prior steps fail (eg. we do not want to mark versions as incompatible if there were errors pulling the Docker image)

The upload-artifact action is used to collect the test results from the matrix to be used later in a download-artifact step.

If tests were not skipped and are now done, we finally get to the index-versions job. We download the artifacts that were previously uploaded to be used here. This job will:

  1. upload incompatible versions to gh-pages. These incompatible versions are named in the format incompatible-forc-<FORC_VERSION>@fuel-core-<FUEL_CORE_VERSION>.

  2. update the channel by filtering for the latest versions of forc and fuel-core that passed tests within the matrix by running These are named in the format compatible-forc-<FORC_VERSION>@fuel-core-<FUEL_CORE_VERSION>. Note that these files are not saved or uploaded onto gh-pages - they are only a way for the test-toolchain-compatibility job to share test results with this job.

Debugging the workflow

If you're contributing to the workflows, it might be a good idea to fork the repo and test any changes you've made on a personal repo first.

Some changes you might want to make to allow for easier testing:

  1. You may want to use the push or workflow_dispatch triggers to make testing easier.

  2. You can also exit with 0 or 1 in jobs or steps where you want it to pass/fail.

You may also use nektos/act to run the workflow(s) locally.