* 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>
* chore(default-flatpaks): Switch to standardized BlueBuild location
Use
`/usr/etc/bluebuild/default-flatpaks`
location instead of
`/usr/etc/flatpaks`
If possible, we should ideally use this location for system modifications:
`/usr/share/bluebuild/default-flatpaks`
While having user modifications in:
`/usr/etc/bluebuild/default-flatpaks`
But it needs to be figured out how the logic will work for separating system & user modifications this way.
I used this logic in unofficial `initramfs-setup` module & it works well, by merging both system & user files into 1 output.
However, this method can create duplicates if user specified it in it's modification, so I mentioned that user should look if the system entry has modifications they need. Perhaps, array diff can be done, which would circumvent this.
So merge this for start.
Only other module which has potential for migrating to standardized BlueBuild config is yafti (more details in other PR I'll do in some time).
* refactor(default-flatpaks): Make default-flatpaks more robust
Document in detail to user how he can change the config in files itself.
Also document what files do in `/usr/share/bluebuild/default-flatpaks` as well.
Refactor flatpak lists detection to be more reliable by excluding words starting with # symbols, whitelines & duplicate entries. Use `comm` for comparing flatpak list to existing flatpaks output instead of using `grep`, as it's easier to use & it's more reliable.
Separate user's & maintainer's modifications better by utilizing read-only `/usr/share/bluebuild/default-flatpaks` directory for maintainers, while for users we would use `(/usr)/etc/bluebuild/default-flatpaks` directory. Reverting to defaults is more reliable as it would avoid users from touching maintainer's modification directly.
I wouldn't modify repo-info.yml doc content, as we restrict it from user's modification & we wouldn't want to potentially ruin yaml parsing just for that.
Only thing that remains is to test this in a VM. And look to potentially make code cleaner.
* draft(default-flatpaks): Avoid install/remove duplicate loop scenario
I have to figure out this part
* draft(default-flatpaks): Avoid install/remove duplicate loop scenario pt.2
* draft(default-flatpaks): Avoid install/remove duplicate loop scenario pt.3
* fix(default-flatpaks): Avoid install/remove duplicate loop scenario
* chore(default-flatpaks): minor grammar adjustment
* draft(default-flatpaks): Account for scenario...
when user sets the same package in install list that is in maintainer's remove list & vice-versa
* fix(default-flatpaks): Account for scenario when user sets the same package in install list that is in maintainer's remove list & vice-versa
* fix(default-flatpaks): Typo in code for combined install list
* chore(default-flatpaks): Remove unnecessary echo
* chore(default-flatpaks): Make directory for user config
* chore(default-flatpaks): Explain user's vs maintainer's flatpak list situation better
* fix(default-flatpaks): Typo in user's configuration for system flatpaks install
* chore(default-flatpaks): There is no need to mkdir parent folder if child folder is created
* chore(default-flatpaks): Make config organization cleaner
Don't use echos for writing configs, use files instead for easier & more intuitive editing.
* fix(default-flatpaks): Copy notification file properly
Made a mistake in variable name
* docs: README fixes
- don't use ambiguous term "live-user"
- capitalize Flatpak
- grammar and phrasing changes
* docs: grammar and phrasing changes in configuration file docs
- replace "maintainer's config" with "image's default config"
- rewrite flatpak list format explanation
* docs: slightly reword local modification section again
* chore(default-flatpaks): Add a missing newline to system flatpak list
---------
Co-authored-by: xynydev
xyny