Clone the repo and use Docker via ./dockerized <cmd> wrapper.
If you don't want to run ./dockerized build, install
the following dependencies via your favorite package manager:
go
npm (v7.13.0+ with nodejs v16.2.0+)
jq (v1.6+)
ipfs
awk
Managing golang and nodejs versions
There is a .tool-versions file for the asdf version
manager, which the Docker build environment will also use.
Running in Docker
There is a ./dockerize script, you can run it without arguements and be in a
shell with the correct software installed in an Ubuntu 20.04 in a directory
thats mapped to the present working directory
Note that we use host networking so you must run an IPFS daemon locally as the
build process assumes a fairly long-lived ipfs node has the CIDs (we give them
to the collab cluster to pin)
You can also do ./dockerized <COMAND>, for instance:
./dockerized make clean
./dockerized ./dist.sh add-version go-ipfs v0.9.0
./dockerized make publish
Note that you can't use bash in the command, so
./dockerized make clean && ./dist.sh go-ipfs add-version v0.9.0
# Does not work
and
./dockerized "make clean && ./dist.sh go-ipfs add-version v0.9.0"
# Does not work
Usage
Add a new version or a new distribution with ./dist.sh then run make publish to get the new CID to publish as dist.ipfs.io.
Adding a version
Run:
> ./dist.sh add-version <dist><version>
This will add the version to dists/<dist>/versions, set it as the current version in dists/<dist>/current, and build it locally.
Example:
> ./dist.sh add-version fs-repo-99-to-100 v1.0.1
To produce a signed, official build for use in DNSLink at dist.ipfs.io:
Run ./dist.sh add-version locally.
Commit created changes to dists/<dist> and open a PR against ipfs/distributions.
Wait for Github Action to finish PR build. It runs ./dockerized build, then signs macOS binaries and spits out updated root CID at the end.
If everything looks good, write down the CID from the preview link on the PR, and update the DNSlink at dist.ipfs.io.
The optional sub_package argument is used to specify a module within a repo. The script looks to see if the subpackage is tagged separately from the repo by looking for sub_package/version tags. Example:
If the distribution should not show up on the website (e.g. go-ipfs migrations) add a no-site file into the dists/<repo> folder.
Manually create a repo-owner file
Reminder that for submodules the version numbers will look like fs-repo-x-to-y/v1.0.0
Publishing
To produce a CID (<NEW_HASH>) that includes binaries for all versions defined in ./dists/, in the root of the repository, run:
> make publish
This will build any new binaries defined by dist and the website to the releases dir, add it to ipfs and patch it into the existing dag for the published /ipns/dist.ipfs.io.
Versions that are already present on the website will be reused, speeding up the build.
Updated CID (<NEW_HASH>) will be printed at the end. That's the new hash for dists.ipfs.io. We also append it to a file called versions in the repo root (not checked into git).
After the local build is done, make a quick inspection:
Load the dists website in your browser to make sure everything looks right: http://localhost:8080/ipfs/<NEW_HASH>.
Compare <NEW_HASH> with the current dists.ipfs.io to make sure nothing is amiss: ipfs object diff /ipns/dist.ipfs.io /ipfs/<NEW_HASH>
Finally,
Commit your changes and make a PR. Specifically, the changes to dists/<dist>/versions and dists/<dist>/current.
Wait for Github Action on your PR to build signed binaries. <NEW_SIGNED_HASH> will be different than one from local build.
Make a PR with an edit on protocol/infra with <NEW_SIGNED_HASH> you got from the Github Action output and a link to the PR above.
TODO: this step may be automated in the future - see the discussion.
If you have permission, you can just merge the PR, update the DNS, and then immediately, close the issue on ipfs/infrastructure. Ping someone on IRC.
Background
The goal is to generate a file hierarchy that looks like this:
We call this the distribution index, the listing of all distributions, their versions, and platform assets.
Notes on reproducible builds
Running ./dockerized make publish will produce binaries using the same
runtime as CI. The main difference between local build and official CI one is
signing step on platforms such as darwin (macOS).
Signatures are attached at the end of macOS binaries, which means
*_darwin-*.tar.gz produced by CI will have additional bytes when compared
with local build.
请发表评论