...
Info |
---|
Add your comments directly to the page. Include links to any relevant research, data, or feedback. |
Page Properties | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||
|
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: | |||||||
---|---|---|---|---|---|---|---|---|
Description | Utilize simp-metadata as a data and build tool | Continue using simp-core to build SIMP ISOs | ||||||
Pros and cons | Quicker, easier builds Ability to build nightlies Can be automated in a Gitlab pipeline Can utilize forked/local metadata for development Multi-use tool for developers and customers Can do everything simp-core currently does with ability to add more deliverables Learning curve for the new tool Would need a full testing cycle to test a build before accepting this as the build tool | Currently known/accepted build process Works as expected Limited in it's abilities No easy way to add deliverables No easy way to automate builds or build nightlies No structure for managing previous release data Somewhat unstable/broken at times | ||||||
Votes | 0 | 0 | ||||||
Estimated cost |
|
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
...