| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Avoiding a condition that has a negation tends to be a bit simpler
for humans to understand.
|
| | |
|
| |
|
|
|
| |
There used to be a check that prevented deployments with names different
to the system. I don't know why this was, but I don't think we need it.
|
| |
|
|
|
|
|
|
|
|
|
| |
We currently build all architectures at once during the release process,
however for our CD pipeline we operate with one CD pipeline per
architecture.
This is not just useful for the CD pipeline work though, as it allows
one organisation to handle releases for x86, where the infrastructure
may be located in the cloud, and one organisation to handle ARM systems,
which may be located in an office.
|
| | |
|
| |
|
|
|
|
|
|
| |
The script used to chdir into the release directory before running morph
deploy. Unfortunately, this didn't work because deployments are run from
the top of the definitons repository.
So now the release directory is included in the path to be deployed.
|
|
|
These scripts are a rewrite of scripts/do-release.py and
scripts/distbuild-cluster. The biggest difference is that they split
the tasks of building the things that are to be released, and uploading
them to git.baserock.org / download.baserock.org, where do-release.py
combines both (and distbuild-cluster only builds chunk/stratum/system
artifacts, not the release images). The new scripts are also configurable
using command line options or a configuration file rather than requiring
editing of the source.
These changes will allow, for example, a CI job that builds a release,
but doesn't upload it to download.baserock.org.
The new scripts are coupled with a change to the release process, which
will be documented as a change to the release process page on
wiki.baserock.org.
The 14.29 release of Baserock was done with slightly different versions
of these scripts to make it feasible to upload things over multiple
network connections.
|
