While working on enhanced logging, I noticed that the control characters
for curl's download log was causing weird issues. This is generally not
something you want in docker logging anyways, so I silenced all
instances of curl I could find. I also noticed that many of those same
curl calls were not set to fail, so I updated that too while I was in
there. More atomicity!
Similar to issues #243.
Enabling PaperWM extension gives this error:
`GLib.FileError: Failed to open file
“/usr/share/gnome-shell/extensions/paperwm@paperwm.github.com/schemas/gschemas.compiled”:
open() failed: No such file or directory`
I'm not sure how to test the fully test this though. I simply edited the
bash script to do Fly-Pie or PaperWM.
recipes with aurora/bluefin as a base image will already have the staging repo present but disabled, meaning wget won't overwrite it.
we don't want to change the repos in the base image in this module, so this backs up the original staging repo, runs the module steps, then restores the original staging repo
* docs(files): Recommend to put files in `/etc/` instead in `
This also modifies build-time part of modules to work with `/etc/` instead of `/usr/etc/`
* docs(files): Revert the `/usr/etc/` & `/etc/` docs
* chore: Revert `signing` module transition due to upstream issue
* docs: Clarify note better regarding /etc
* feat: add nu script that generates build matrix for github action
* chore: push initial version of new github action for testing
* fix: properly close github template sequence
* chore: screw this i'll write the whole build in nu (nu build script started, continue later)
* fix: individual misspellings and such
(yeah, i'm tired)
* fix: containerfile path
* fix: docker arg syntax
* fix: docker build path?
* feat: code structure, buildx, pushing to registry
* fix: tag image properly
* fix: split arguments properly
* fix: use registry properly
* refactor: move docker build to a separate par-each
* feat: correctly tag versioned modules
* feat: cosign signing, better logging
* fix: cosign syntax
* fix: differentiate log types with more expressive colors
* chore: fix cosign syntax in logs
* fix: capture errors, colocate logs while running paraller
* chore: partly revert "fix: capture errors, colocate logs while running paraller"
This reverts commit 9238a0f1d68183e712b567fc50849964cc964c78.
* chore: bring back capture errors, keep order in logs
apparently do --capture-errors is required for nushell to catch external commands errors
* chore: Revert "chore: bring back capture errors, keep order in logs"
These changes didn't do anything...
This reverts commit 020b9a1bce9456f2167397b49aa24a65f6bec8e6.
* fix: properly tag images in PRs and secondary branches
* fix: use tags-variable instead of "tags" string
* chore: change default-flatpaks module folder structure to be versioned
* fix: also log generated tags for versioned modules
* fix: don't add tags meant for latest image for every version of versioned module
* fix: better logging and inline docs
* fix: better logging pt2
* feat: build-unified for building the legacy modules container with just the latest versions
* fix: correct workflow names
* fix: add missing ansi resets
* chore: add nushell extension to recommendations
* fix: update unified job name
Co-authored-by: Gerald Pinder <gmpinder@gmail.com>
* chore: remove matrix output left over from a previous version
---------
Co-authored-by: Gerald Pinder <gmpinder@gmail.com>
Wanting to avoid running unnecessary setup in logs as much as possible.
Unfortunately,
`flatpak remote-add` still runs even if repo exists, as it apparently modifies the URL, no matter if it's the same.
I tried to extract & compare input URL & flatpak URL to mitigate this as an condition, but it doesn't work, as flatpak lists repo URL, while we input flatpakref URLs, which are not the same.
`rpm-ostree` method is not capable of installing yafti's older version of `python3-pydantic` instead of being confused between both system's & yafti's version of that package.
I tried to increase `ublue-os staging` repo priority, where yafti resides, but that doesn't work.
Pip method while not flawless with its hardlinking errors when same system package tries to get installed, it at least finishes yafti install successfully.
