Add functionality for publishing "dev" and "unstable" packages in Freight #15

New Issue

2021-03-16T14:21:52Z

mhfowler commented

2021-03-16 14:21:52 +00:00

(Migrated from github.com)

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

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

Sign in to join this conversation.