You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current custominstallerbuilder ("CIB") documentation does not reflect the latest changes to the process of building new base installers. I'll sketch below what high-level information is helpful to understand the overall build/ship workflow, and what specific steps the documentation should mention.
The pregenerated (g)zip file is called a "base installer", i.e. a Seattle installer without the vesselinfo.This file must be re-generated whenever the Seattle version is updated, but note that updating it is not part of the function or role of the CIB: The CIB only needs the end result which is an updated set of base installers. The installer packaging tools exist for generating base installers.
It doesn't matter to the CIB where (e.g. on which machine, by which user, in which subdir) exactly its base installers are created. What matters is that the base installer files are copied into a preconfigured directory where the CIB expects them.
Setting up CIB for the first time
git clone the CIB repo
Run the buildscripts to generate a Repy runtime for the CIB. (This local runtime is totally independent and separate of the runtimes that are included in a typical Seattle base installer, although it likely uses identical copies of many Seattle files as the base installer contains.)
Configure the CIB Django project.
Configure Apache and mod_wsgi to make the CIB accessible from the Web.
This yields a CIB that does not have base installers yet.
The current custominstallerbuilder ("CIB") documentation does not reflect the latest changes to the process of building new base installers. I'll sketch below what high-level information is helpful to understand the overall build/ship workflow, and what specific steps the documentation should mention.
Preliminaries
The CIB does two interesting things dynamically: It creates a
vesselinfo
file (given a user session), and adds it to a pregenerated (g)zip archive. The resulting archive is a customized installer which is cashed and can be re-downloaded under a static URL.The pregenerated (g)zip file is called a "base installer", i.e. a Seattle installer without the
vesselinfo
.This file must be re-generated whenever the Seattle version is updated, but note that updating it is not part of the function or role of the CIB: The CIB only needs the end result which is an updated set of base installers. The installer packaging tools exist for generating base installers.It doesn't matter to the CIB where (e.g. on which machine, by which user, in which subdir) exactly its base installers are created. What matters is that the base installer files are copied into a preconfigured directory where the CIB expects them.
Setting up CIB for the first time
git clone
the CIB repomod_wsgi
to make the CIB accessible from the Web.This yields a CIB that does not have base installers yet.
Build new base installers
See also https://github.com/SeattleTestbed/installer-packaging/blob/master/README.md . You'd also do this when a new Seattle version should be shipped.
git clone https://github.com/SeattleTestbed/installer-packaging.git
Putting CIB and base installers together
Lastly, copy the base installers into the directory that the CIB expects.
The text was updated successfully, but these errors were encountered: