StarlingX/Build

= StarlingX Build Sub-project =

Team Information

 * Project Lead:Mike Matteson 
 * Technical Lead: Scott Little 
 * Contributors: Davlet Panech ; Jason Norton ; Anthon Nowell ;Mark Asselstine ;

Weekly Call
Every other week 7:30am PST (eg: Nov 2, 2021) https://meet.jit.si/starlingx-build

Project notes https://etherpad.openstack.org/p/stx-build

Team Objective / Priorities

 * Responsible for the StarlingX build system

Starling X Mirror
Ongoing development of a StarlingX Mirror has begun in partnership with CENGN. The overall vision and requirements for this mirror was presented by Brent Rowsell at the weekly build meeting call on October 2nd, 2018 (see the slides here). The specification for the mirror function itself can be found here. This will be followed by other specifications to flush out the build and the installer. Work related to the development of the mirror can be found here.

To see what the mirror contains, please see here.

To find a nightly build, please see here. Nightly builds will be retained for 14 days and the build artifacts for these will be retained for 7 days.

To find the 2018.10.0 release build, please see here.

A cadence of release and milestone builds is being proposed here. This will be discussed on the mailing list.

Use Cases for Stxb
I am an organization who is considering StarlingX. I want to download the latest release build of StarlingX to evaluate it.
 * Case 0A [Use prebuilt ISO]

I am an individual looking to get started with StarlingX. I want to do a build of the latest code without worrying about having to set up infrastructure (local mirror, etc). I just want to build the product and have an output I can load onto a system.
 * Case 0B [Basic build]:

I am an organization with a site who is working with StarlingX. I want to provide a local mirror of artifacts for my employees so they don’t have to download from the Internet. I want to create an automated job which I will run daily to update my mirror. The artifacts downloaded are to be posted to a network file share on which I have write permissions. I do not want to re-download any artifacts which I already have downloaded.
 * Case 1 [Provide/sync a local mirror]:

I am a developer within an organization which has provided a local mirror of artifacts on a network file share. I want to build StarlingX using the local mirror for any artifacts. The mirror will contain all binary rpms along with their corresponding src rpm, such that if no changes all the building of an ISO would be done from the mirror rpms, no actual local rpm build required unless it changes
 * Case 2 [Build using a local mirror]:

I am a developer who has already performed a build with artifacts I have downloaded (case 0B). I want to perform a rebuild using the latest upstream content.
 * Case 3 [Rebuild with sane downloads and rebuild package list]:
 * Requirement 3A: The rebuild shall not re-download any artifacts which have not been updated.
 * Requirement 3B: The rebuild shall download any artifacts which have been updated or added.
 * Requirement 3C: The rebuild shall not re-build any content which has not changed since previous build
 * Requirement 3D: The rebuild shall re-build any content which has changed since previous build

I am a developer who wants to make a change to an existing package within StarlingX. I want to build StarlingX with my change in place to test it. I do not want to perform a git commit or upstream my change at this time.
 * Case 4 [Build with a local change to existing package]:

I am an organization who produces a product based on StarlingX. I want to add my own proprietary package to the ISO. I want to build the StarlingX ISO with my package included on the disk and installed on all nodes. The package is available as a prebuilt binary RPM on the build machine’s file system and has no additional package dependencies.
 * Case 5 [Build with a new binary package]:

I am an organization who produces a product based on StarlingX. I want to add my own proprietary package to the ISO. I want to build my package within the StarlingX framework. The source code is available in a locally accessible git.
 * Case 6 [Build with a new source package]:

I am a developer at an organization. I share a build machine with multiple other users. Furthermore, I work on several different branches/workspaces of StarlingX concurrently. I want to log into the build machine using two separate shells, each working in a separate workspace. I do not want to have to edit files in my home or system directory to select the new workspace, as this would imply that only one user/workspace can be active at a time.
 * Case 7 [Multi-user/multi-workspace]:

I am a developer at an organization which produces StarlingX. A customer has reported a potential bug which they observed on the 2018.10 release build of StarlingX. I want to perform a build of r/2018.10 branch of StarlingX (rather than master) to start to debug the issue
 * Case 8 [Branch support]:

I am an organization who produces a StarlingX build nightly as an automated job. I want to provide my build artifacts to developers for build avoidance.
 * Case 9 [Build avoidance - organization]:

I am a developer at an organization which produces a StarlingX nightly build. When I build my system, and I have not changed a package since my organization last did a nightly build, I want to use the pre-built version of the package rather than compile it myself.
 * Case 10 [Build avoidance – developer]:

I am a developer at an organization which produces a StarlingX based product. I have made changes to a package to fix a bug. I want to produce a patch/update to the release ISO which will include the updated rpm.
 * Case 11 [Patching]:


 * Unstated requirements:
 * I should be able to perform all of the above without root access on the build machine
 * I want to be able to work on a local copy of the source code, not have to go into a container to modify or work on code
 * I would prefer if I was able to do the above on a native CentOS machine without using docker containers, but I think that ship has sailed 

Tags
All story board stories and launchpad bugs created for this team should use the tag "stx.build".

Team Work Items

 * Story Board
 * All
 * Active Stories
 * Merged Stories
 * Active Release - stx.6.0
 * Active Stories
 * Launchpad Bugs
 * All
 * Open Bugs
 * Fixed Bugs
 * Active Release - stx.6.0
 * Open Bugs

Status

 * See etherpad