Using BlueBuild Stages
https://github.com/weatheredian/wyvernOS/actions/runs/19301679128/job/55197625175
I'd like to build a program from source and include it in my final bluebuild image. (seems like the Stages method is the way to go)
I'm having a hard time understanding/parsing the documentation for stages specifically. I have my stage to build a package called gr-gsm - they have published build instructions (and a dockerfile, but i'd prefer to learn how to do the build from source, as i have a number of other packages for which I'll need to do so)
https://osmocom.org/projects/gr-gsm/wiki/Installation
https://gitea.osmocom.org/sdr/gr-gsm/src/branch/master/tests/dockerfiles/Ubuntu_20_04.docker#
When my build runs, it seems to fail due to the directory structure of the build. I git clone the repo, then if i try to cd into the new directory, it still shows "/" for my current working directory. I've also linked a failing build showing this behaviour.
Does anyone have an example that seems similar? or advice for my specific case? I'm still new the bluebuild and immutable stuff, so i may be missing something obvious.
thanks!
GitHub
added dir printouts to grgsm build · weatheredian/wyvernOS@8440f3c
bluebuild OS. Contribute to weatheredian/wyvernOS development by creating an account on GitHub.
22 Replies
you will need to use Containerfile syntax for stages
so instead of cd, you would use WORKDIR and such
oh! that makes sense. i'll give it a shot now, thanks!
np! personally i prefer using a separate job+Containerfile for clean builds then copy it into my bluebuild job:
- https://github.com/askpng/couchpotato/blob/main/files/xremap/Containerfile
- https://github.com/askpng/couchpotato/blob/main/.github/workflows/build-xremap.yml
tbf, the stages doc also uses cd:
but i think it only applies to that particular snippet line, so you'll need to use && so that the cd-ed dir affects the rest of the commands in that line
oh thats an interesting quirk. i'll work on modularizing and run another test
oops forgot to link the copy snippet: https://github.com/askpng/couchpotato/blob/main/recipes/phase/xremap.yml
GitHub
couchpotato/recipes/phase/xremap.yml at main · askpng/couchpotato
Contribute to askpng/couchpotato development by creating an account on GitHub.
but yeah that works fine for me since the binaries i need arent updated often (or at all 😭) so scheduling them once a month is not a problem
okay, just to make sure im following (reading your files now) do you not have to deal with including extra runtimes? i dont see it in your build.
it looks like im downloading a ton of extra stuff and deleting it. is that what your section here is doing?
looking at the copy snippet, are you building the xremap as a seperate image in the same repo? havent seen that before. if im understanding correctly, you build the image from the xremap container file, then call the 'built' container in your main build? thanks for the help, i appreciate it
for that image in particular i don't really mind the runtimes and whatnot because it's a small image. the Free disk space step is just there but i don't think it actually deletes anything even in my image job lol
yes, i build xremap and flex-launcher in separate jobs within the same repo, and for both i don't really care about maximizing build space since in the case of these two packages they're pretty small
and yes again, i use the xremap and flex-launcher jobs only for building them. then, i push only the relevant packages to the result image and then pull it using the copy module within the actual image recipe
do keep in mind that you will need to experiment with your build results yourself, because your build result may vary. for me xremap only results in /usr/bin/xremap and flex-launcher results in /usr/local/bin/flex-launcher and /usr/local/share/flex-launcher/* or something, yours will likely be different
yeah thats fair. thanks again. im gonna play around some more with the containerfile method, most of the pacakges im interested in have containerfiles linked so if i can just use them, i'll be set. i hadnt considered pushing each of my packages seperately to its own image and doing the overlay that way, but that seems like a safe way to go
good luck!
i used to do in-recipe build myself, and of course installing deps and then removing them, but i hated it
yeah when i tried that way, i think i ran into issues with dependencies, old package with weird dependencies and whatnot. maybe it'll work for some but i'd rather have a 'universal' way for me to have some reproducability
So each entry in
snippets runs in it's own shell so cd doesn't carry over to the next instruction
That might be what you're running into
It helps if you just put everything in a script in files/scripts and call that directly using the scripts property. That way everything you do is contained in said scriptAnd the module file
oh sure. that makes sense. thanks!
i'll give the script and the images both a shot 👍
Yeah, you are free to create your own separate images. The stages method just makes it so that it builds the software while building your image
So if you have multiple recipes using that stage, each recipe build is going to build that software which could duplicate work and be less efficient
noted. so its more efficient, if im building a few recipes, to build an image once, then reference it later, rather than from a script/stage?
Yes, but there's more moving parts to take care of
So it's a trade-off
right. definitely noticed that. seems like a fair trade off i guess. thank you both for the help - i'm going to try one of each maybe? im not sure yet if i'll be building mulitiple recipes with this repo, so i dont know if its worth the extra hassle to do it through images. but maybe... i had considered doing a lite/heavy for the system so it could be useful there