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
{{ message }}
This repository has been archived by the owner on Jun 7, 2022. It is now read-only.
So while doing development, I've been cheating a bit, in terms of using freight.
Sometimes, I use rsync to copy over code to the vps that hasn't been merged into master yet (or may not even be fully tested), and then I increment the version number and use peach_package_builder to build packages from this code, by not passing the -d command (so that the local code is used for the build).
This is useful to me sometimes, because then I can apt-get install the package onto my pi. Or use new code for building an image (which uses apt-get during image building).
But its cheating, because if we were "live" and had a bunch of people using peach cloud out there, it wouldn't be good to publish unstable packages like that,
and when someone runs "apt-get update" or "peach-config update" they would actually pull down the unstable packages!
I'm not sure what the best solution is.
For a lot of development, I can rsync pacakges directly to the pi and test them like that (separate from Freight). But sometimes it seems nice to be able to build something as a freight package and test that it actually works in its package form. For testing one can also build the .deb without adding to freight, and then manually download and install the .deb. This is a bit slow though .
Three possible solutions:
a "dev" freight repo, or a way to publish to freight that indicates its a dev package and most PROD deployments dont get this package yet
perhaps some scripts which make building debs and downloading them to the rpi easier somehow
in peach-config, when we update, we actually only update to a new peach-system version when there is a release. in this model, we can be updating different packges all kinds, but users will only ever pull the new changes, when we officially release a new peach-system version, which has version numbers for all the other packages pinned to it
just some things I'm thinking about.. not really sure .. for now I may continue cheating sometimes
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
So while doing development, I've been cheating a bit, in terms of using freight.
Sometimes, I use rsync to copy over code to the vps that hasn't been merged into master yet (or may not even be fully tested), and then I increment the version number and use peach_package_builder to build packages from this code, by not passing the -d command (so that the local code is used for the build).
This is useful to me sometimes, because then I can apt-get install the package onto my pi. Or use new code for building an image (which uses apt-get during image building).
But its cheating, because if we were "live" and had a bunch of people using peach cloud out there, it wouldn't be good to publish unstable packages like that,
and when someone runs "apt-get update" or "peach-config update" they would actually pull down the unstable packages!
I'm not sure what the best solution is.
For a lot of development, I can rsync pacakges directly to the pi and test them like that (separate from Freight). But sometimes it seems nice to be able to build something as a freight package and test that it actually works in its package form. For testing one can also build the .deb without adding to freight, and then manually download and install the .deb. This is a bit slow though .
Three possible solutions:
just some things I'm thinking about.. not really sure .. for now I may continue cheating sometimes
The text was updated successfully, but these errors were encountered: