Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Info

Add your comments directly to the page. Include links to any relevant research, data, or feedback.

Page Properties
label


Status
Status
colourYellow
titleIn Progress
Impact

Status
colourRed
titleHIGH

Driver~557058:da6320c4-4cb9-4d7b-8742-0dfa95644ddd 
Approver
Contributors
Informed
Due date
Outcome


Background

Our goal is to utilize simp-metadata as the data structure and build tool for SIMP to allow for quicker, automated builds, as well as provide easier access to build information for developers and customers.

...

For development purposes, assuming you have already cloned simp-metadata to your own personal Github, you can copy X release to a new Y release, update component versions and remove/add components for Y release, and test the builds. This can be done locally on your machine, or in a container if you choose to use Docker. This allows for easy development and testing without the need for extra branches, or changes to the SIMP owned repository. Nightly YAML files are created automatically, making nightly builds easy to generate, and with all "official" builds (testable nightlies, pre-release builds, and final builds) being built in a Docker container on the download server, all files will be available for download as soon as the pipeline is complete (All files would be placed into dev/unstable folders until verifying that we are ready to release them).

The gitlab pipeline will look like this: https://gitlab.onyxpoint.com/brandon.riden/simp-meta-release/pipelines/70852 (No actual build data, but output in stages shows what each stage does). We contain environment checks, RPM check/build/sign/verify, tarball check/build, deliverable prep, deliverable build, test, and deploy stages. We would be able to add any deliverable builds and automated tests directly to the pipeline if and when needed. The manual RPM verify stage ensures that there is still manual interaction (for now) when RPMs are built and signed, before utilizing them in the actual build. 

simp-metadata would also be added to all releases of SIMP, allowing customers to utilize the tool. This will be useful if they want to know what changes were made between releases to see if they want to update, or (in future command additions) provide us with information for support. 

Options considered


Option 1:Option 2:
DescriptionUtilize simp-metadata as a data and build toolContinue using simp-core to build SIMP ISOs
Pros and cons

(plus) Quicker, easier builds

(plus)Image Modified Ability to build nightlies

(plus)Image Modified Can be automated in a Gitlab pipeline

(plus)Image Modified Can utilize forked/local metadata for development

(plus)Image Modified Multi-use tool for developers and customers

(plus)Image Modified Can do everything simp-core currently does with ability to add more deliverables

(minus) Learning curve for the new tool

(minus)Image Modified Would need a full testing cycle to test a build before accepting this as the build tool

(plus) Currently known/accepted build process

(plus)Image Modified Works as expected

(minus) Limited in it's abilities

(minus)Image Modified No easy way to add deliverables

(minus)Image Modified No easy way to automate builds or build nightlies

(minus)Image Modified No structure for managing previous release data

(minus)Image Modified Somewhat unstable/broken at times

Votes00
Estimated cost
Status
colourRED
titleLARGE

Action items

  •  Full Test Cycle on an ISO built using simp-metadata
  •  Deprecate simp-core build tools
  •  Update open-source rubygem-simp-metadata to add build tools and updates
  •  Build Gitlab pipeline for builds

...