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
All major 'features' of pi-topOS (considering any change applied on top of Raspberry Pi OS as a 'feature') are currently handled in the OS build pipeline. However, this is a very static implementation that can be hard to track effectively.
If we say that the pi-topOS build pipeline handles everything to do with installing pt-os and setting up for onboarding (such as changing the state of systemd services), we can separate out all other actions into a command that can be run at any time.
This does a number of things:
Simplifies OS build pipeline steps
Creates infrastructure to effectively check if someone's system is correctly set up (and provide opportunities for things such as automatically applying fixes)
Allows us to define and apply new default system states after release
Specification proposal:
pi-top os-config --system
This would be the first version of this command, and would ensure that each action is correct (similar to how ansible can only apply changes when needed).
Potentially later on we could even have the onboarding config able to be applied from this command:
pi-top os-config --init
as well as specify steps:
pi-top os-config --boot_config on --motd on --volume off
We can also add new options, such as bash aliases.
The text was updated successfully, but these errors were encountered:
All major 'features' of pi-topOS (considering any change applied on top of Raspberry Pi OS as a 'feature') are currently handled in the OS build pipeline. However, this is a very static implementation that can be hard to track effectively.
If we say that the pi-topOS build pipeline handles everything to do with installing
pt-os
and setting up for onboarding (such as changing the state of systemd services), we can separate out all other actions into a command that can be run at any time.This does a number of things:
Specification proposal:
This would be the first version of this command, and would ensure that each action is correct (similar to how ansible can only apply changes when needed).
Potentially later on we could even have the onboarding config able to be applied from this command:
as well as specify steps:
We can also add new options, such as bash aliases.
The text was updated successfully, but these errors were encountered: