fuelup adopts a simplified version of rustup channels . Currently, the latest, nightly, and beta channels are published and serve as a source of distribution of Fuel toolchain binaries.
| Channel | Source | Integration Tested | Update Frequency | Available |
|---|---|---|---|---|
| latest | published bins | ✔️ | checked every 30 minutes | ✔️ |
| nightly | master branch | ➖ | nightly (1:00 AM UTC) | ✔️ |
| beta-3 | published bins | ➖ | only when necessary | ✔️ |
beta-3 channel The beta-3 channel is a published TOML file describing the toolchain that is compatible with our beta-3 testnet . This toolchain should be used to interact with and build on the testnet. The components to be installed can be found here .
nightly channel The nightly channel is a published TOML file describing successful builds of the master branch of forc and fuel-core for the day.
These builds are released in the sway-nightly-binaries repository and the workflows in that repo start building them every day at 00:00 UTC.
The nightly channel within fuelup is updated by a scheduled GitHub workflow that runs every day at 01:00 UTC, after builds have finished.
Note that nightlies might fail to build, in which case it is possible that the nightly toolchain may not be available for that day.
You should use nightly if you want the latest changes to master that have not been officially released yet.
Keep in mind that compatibility between forc and fuel-core is not guaranteed here, and you should expect unstable features to break.
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:
latest workflow Note
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:
upload incompatible versions to gh-pages. These incompatible versions are named in the format incompatible-forc-<FORC_VERSION>@fuel-core-<FUEL_CORE_VERSION>.
update the channel by filtering for the latest versions of forc and fuel-core that passed tests within the matrix by running index-versions.sh. 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.
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:
You may want to use the push or workflow_dispatch triggers to make testing easier.
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.