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
What do we do ?
A refresh is the process by which, interdependent compilers are built in several cycles to ensure that gcc and glibc are built with the most up to date versions possible. Without performing builds of these cycles, a single build in each of these would result in the latest changes, not being built into the resulting package. While there are ongoing efforts to enable habitat bldr with this functionality, it is still currently necessary to perform a refresh outside of the production bldr environment.
PreRequisites :
Build Order needs to be documented
Refresher Environment should be setup
Branch/Merge Strategy
How do we do ?
The general flow of a refresh occurs in several stages. The flow involves basically 4 stages as mentioned below:
Build Stage 1 :In the first stage we focus on building out what are considered the base plans. Base plans are just like regular core plans, aside from them being key to the ecosystem at large. These packages are used to bootstrap the entire ecosystem from scratch, and they contain the interdependent packages gcc and glibc.
Build Stage 2: Stage two plans are other plans required by chef software. Any failure in this list of packages is considered a failure of the whole refresh process, because a failure in these plans, would mean a failure to build chef software
Build Stage 3:Stage three plans are considered slightly lower risk. Every attempt should be made to build these plans. However, these plans don’t typically have a long list of dependencies and can be troubleshooted outside of the refresh process.
Build Stage 4 : Stage four involves the building of chef software against the refreshed packages. This is considered a precursor to the release of the refresh into stable. It has two purposes, ensuring that software outside of the refresh can be built using it as an integration test, and allowing chef software to build key parts of the infrastructure so that, when the refresh is released we are able to maintain business continuity.
Final Acceptance Criteria : All the Habitat packages are refreshed and the refresh bundle is released in the stable channel. Chef products have been refreshed and uploaded to stable channel.
The text was updated successfully, but these errors were encountered:
What do we do ?
A refresh is the process by which, interdependent compilers are built in several cycles to ensure that gcc and glibc are built with the most up to date versions possible. Without performing builds of these cycles, a single build in each of these would result in the latest changes, not being built into the resulting package. While there are ongoing efforts to enable habitat bldr with this functionality, it is still currently necessary to perform a refresh outside of the production bldr environment.
PreRequisites :
Build Order needs to be documented
Refresher Environment should be setup
Branch/Merge Strategy
How do we do ?
The general flow of a refresh occurs in several stages. The flow involves basically 4 stages as mentioned below:
Build Stage 1 :In the first stage we focus on building out what are considered the base plans. Base plans are just like regular core plans, aside from them being key to the ecosystem at large. These packages are used to bootstrap the entire ecosystem from scratch, and they contain the interdependent packages gcc and glibc.
Build Stage 2: Stage two plans are other plans required by chef software. Any failure in this list of packages is considered a failure of the whole refresh process, because a failure in these plans, would mean a failure to build chef software
Build Stage 3:Stage three plans are considered slightly lower risk. Every attempt should be made to build these plans. However, these plans don’t typically have a long list of dependencies and can be troubleshooted outside of the refresh process.
Build Stage 4 : Stage four involves the building of chef software against the refreshed packages. This is considered a precursor to the release of the refresh into stable. It has two purposes, ensuring that software outside of the refresh can be built using it as an integration test, and allowing chef software to build key parts of the infrastructure so that, when the refresh is released we are able to maintain business continuity.
Final Acceptance Criteria : All the Habitat packages are refreshed and the refresh bundle is released in the stable channel. Chef products have been refreshed and uploaded to stable channel.
The text was updated successfully, but these errors were encountered: