https://blue-build.org/ logo
Powered by
Using BlueBuild Stages
# questions
m
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!
a
message has been deleted
m
you will need to use Containerfile syntax for stages
so instead of cd, you would use WORKDIR and such
m
oh! that makes sense. i'll give it a shot now, thanks!
m
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:
Copy code
stages:
  - name: helix
    from: docker.io/library/rust
    modules:
      - type: script
        snippets:
          - apt-get update && apt-get install -y git # Install git
          - git clone https://github.com/helix-editor/helix.git # Clone the helix repo
          - cd helix && RUSTFLAGS="-C target-feature=-crt-static" cargo install --path helix-term # Use cargo to install
          - mkdir -p /out/ && mv $CARGO_HOME/bin/hx /out/hx && mv runtime /out/ # Move bin and runtime
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
m
oh thats an interesting quirk. i'll work on modularizing and run another test
m
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
m
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? https://cdn.discordapp.com/attachments/1438190065733074995/1438202863326204016/image.png?ex=6916064b&is=6914b4cb&hm=36dd962dffe5683b0d466cf4b8d816aa581ebc2983582c3effd75dcdffb9f533& https://cdn.discordapp.com/attachments/1438190065733074995/1438202863850360993/image.png?ex=6916064b&is=6914b4cb&hm=dca032d78c556b2a4ba47532737a4f60ffcae264ded0e8bae87219d78b5f6c0e&
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
m
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 https://cdn.discordapp.com/attachments/1438190065733074995/1438206628166897674/image.png?ex=691609cc&is=6914b84c&hm=3df5006223711eb6fa2d87b78bd13bf2435bbe989b2cb19701b2ccfa8bed25bd&
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
m
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
m
good luck!
i used to do in-recipe build myself, and of course installing deps and then removing them, but i hated it
Copy code
- type: script
    snippets:
      # flex-launcher - clone & build
      - git clone https://github.com/complexlogic/flex-launcher.git /tmp/flex-launcher && mkdir -p /tmp/flex-launcher/build
      - cd /tmp/flex-launcher/build
      - cmake /tmp/flex-launcher -DCMAKE_BUILD_TYPE=Release && make install
      - rm -r /tmp/flex-launcher
m
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
g
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 script
m
oh sure. that makes sense. thanks!
i'll give the script and the images both a shot 👍
g
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
m
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?
g
Yes, but there's more moving parts to take care of
So it's a trade-off
m
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
PreviousNext
Powered by