For some days I have this
- build container image is green
- but a BTRFS mount for podman storage failed
It doesn’t look like a serious error as the container image was build successfully but I am not sure if something has to be done here.
GitHub made changes and has now much larger space in the runners /
So you can remove maximize of space jobs from the workflow
Yea I noticed that as well I don’t think its a problem.
thanks! I was wondering about that.
I commented this out. Sped my build up a lot.
.github/workflows/build.yml
# - name: Mount BTRFS for podman storage
# id: container-storage-action
# uses: ublue-os/container-storage-action@911baca08baf30c8654933e9e9723cb399892140
#
# # Fallback to the remove-unwanted-software-action if github doesn't allocate enough space
# # See: https://github.com/ublue-os/container-storage-action/pull/11
# continue-on-error: true
# with:
# target-dir: /var/lib/containers
# mount-opts: compress-force=zstd:2
Aah, ok.
The next question is if I did make mistakes by not paying attention to pull requests which have come in over time.
My custom image github repository was forked from
If I look into image-template/.github/workflows/build.yml at fd08a06d1346d6e85693f3b771c66271e2bb2f97 · ublue-os/image-template · GitHub I see that this part
- name: Mount BTRFS for podman storage
id: container-storage-action
uses: ublue-os/container-storage-action@911baca08baf30c8654933e9e9723cb399892140
# Fallback to the remove-unwanted-software-action if github doesn't allocate enough space
# See: https://github.com/ublue-os/container-storage-action/pull/11
continue-on-error: true
with:
target-dir: /var/lib/containers
mount-opts: compress-force=zstd:2`
has vanished.
I can/will remove this on my side as well.
Question: What is the proper way to deal with those changes? Can I assume that those changes come in via pull requests and I simply have to merge (which I haven’t done in the past)?
I didn’t fork mine, I used it as a template.
@locke496 I would think carefully about merging changes from upstream indiscriminately. Been there - done that myself. While there is value to living on the shoulders of giants so to speak, it is prudent to recognize the amount of additional work you would be taking on to fully understand and approve those changes for use in your project.
Although I suspect you already know that. My intention is just a helpful reminder to think it through a little more. Is merging from upstream really valuable enough to you such that you are willing to take on code reviewing the set of commits in each merge?
Or like @Danathar mentions - just treat what you have as a starting template …
Neither is ideal. Sounds like a judgment call based on personal preferences to me.
I am curious to watch how this conversation develops though.
My wording was wrong. I also used it as a template.
1 Like
I wasn’t quite sure because if I would create a repository from the template today I also would get the current status. Of course, I would have to pay attention to not overwrite my own stuff.
Just my thoughts (I am not an expert here).
No worries, neither am I. I know just enough about GitHub Actions, PRs, etc. to hurt myself. 
I just try to limit the damage to myself and not others!
Thanks for that. When I said “used mine as a template,” FYI, I was meaning that literally, as in used the option to template it instead of forking it. My reading is that makes a big difference.
I am not an expert in custom bluefin images either.
But, I have been through something similar on the day job for a complex app.
It seemed like a good way to keep the team focused on the business problems the app was meant to solve as opposed to the enterprise architecture goo that was mandated.
It was working well. Until the upstream refactored their repo structure. And then we had a much larger set of decisions to make at a time where we really could not absorb the unplanned work. That sort of pain does stick with you.
That is what I remembered when I read your post.
And this from Jorge - Bluefin is undergoing a refactor with some significant changes under the hood
I suspect at some point there will have been enough change that you may opt to start over with a different template - or not.
Either way - you triggered a memory … shiver.
Good luck.
On a side note, I make my images with both BlueBuild and regular Containerfile/build scripts. Knowing both is good. If you use BlueBuild, they take care of a lot of issues, and it’s pretty easy to update BlueBuild’s script to whatever the next version they release.
The only downside to BlueBuild is that their build scripts take significantly longer than the traditional way on GitHub. This only really bothers me when I’m testing stuff. That being said, it also pays to know how to build locally on a system, as often (as in the case of my system) it’s far faster than the runners on GitHub.
1 Like
Yes, I also chose the template way.