Post AWS72SpLJFCeRoCNwu by dthompson@toot.cat
 (DIR) More posts by dthompson@toot.cat
 (DIR) Post #AWNsVVHQzZKaVbt6Xo by civodul@toot.aquilenet.fr
       2023-06-05T14:23:26Z
       
       0 likes, 2 repeats
       
       “From development environments to continuous integration—the ultimate guide to software development with Guix”https://guix.gnu.org/en/blog/2023/from-development-environments-to-continuous-integrationthe-ultimate-guide-to-software-development-with-guix/#Guix #CI
       
 (DIR) Post #AWS72R2NxmRotgHm08 by dthompson@toot.cat
       2023-06-05T14:33:22Z
       
       0 likes, 0 repeats
       
       @civodul this is awesome! I haven't yet explored making a channel within a project repo, but I want to try that soon. Looks very useful.Noticed a small typo: "run jobs n a Docker image"If I could offer an alternative take on Gitlab CI setup: Use 'guix pack' to produce an image that has just the dependencies needed to build and run the project. This trades flexibility for speed. The CI jobs don't have to redundantly download the same dependencies over and over because they are already there. However, the image needs to be periodically updated with a fresh build when dependencies are modified. We use this approach for guile-hoot because we don't want the overhead of running a substitute server but we need both a custom built Guile and V8 and it would take hours to know if your branch is green if CI had to build those each time.
       
 (DIR) Post #AWS72RqiwciJPnpySm by korkeala@fosstodon.org
       2023-06-07T06:59:24Z
       
       0 likes, 0 repeats
       
       @dthompson @civodul This looks is a nice approach, thanks for sharing! Do you know if there is a way to optimize the container image size? For example when I've made containers with pack command to have only OpenJDK 17 package, the resulting image size is over 500 mb. Then I've seen some OpenJDK 17 container images based on debian slim have size around 200 mb.
       
 (DIR) Post #AWS72SpLJFCeRoCNwu by dthompson@toot.cat
       2023-06-07T09:18:08Z
       
       0 likes, 0 repeats
       
       @korkeala @civodul Guix package graphs tend to have more nodes than their Debian equivalent. You can use 'guix graph' to get a sense of what's going on and then investigate if those references are really necessary or an accident. Guix scans build artifacts looking for /gnu/store references to build the runtime dependency graph. Sometimes build systems generate files with extraneous references. I generated a guix pack for a Qt program recently and noticed that mariadb, postgresql, and CUPS, among others, were being pulled in even though they definitely weren't being used. Maybe I'll investigate why sometime. What I really want though is some way to do tree shaking to get rid of unnecessary things. I don't need texinfo manuals in my container images, for example.
       
 (DIR) Post #AWS72TbYPzlerKkt60 by civodul@toot.aquilenet.fr
       2023-06-07T15:33:00Z
       
       1 likes, 1 repeats
       
       @dthompson @korkeala  Also, the ‘guix size’ command is a profiler: you can run ‘guix size qtbase’, say, to see what’s taking up space among ‘qtbase’ and its run-time dependencies.Then the game consists in finding packages that “shouldn’t be there” and removing them.
       
 (DIR) Post #AWSi5CA7QEcxw259UW by civodul@toot.aquilenet.fr
       2023-06-07T19:58:30Z
       
       1 likes, 0 repeats
       
       @korkeala @dthompson  I just found another unnecessary run-time dependency for qtbase: https://issues.guix.gnu.org/63948So yeah, there’s room for optimization.  :-)