[Initiatives.wiki] Update DevOps with Flatpak



commit e82ecfab6426fe3187a0fdcc6a289fab4c9b8de1
Author: Jordan Petridis <jordanpetridis protonmail com>
Date:   Wed Aug 1 20:16:52 2018 +0000

    Update DevOps with Flatpak

 DevOps-with-Flatpak.md | 23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)
---
diff --git a/DevOps-with-Flatpak.md b/DevOps-with-Flatpak.md
index 94fc5f8..f3cd0b5 100644
--- a/DevOps-with-Flatpak.md
+++ b/DevOps-with-Flatpak.md
@@ -1,5 +1,17 @@
 # Flatpak CI
+## FAQ
+
+### Why not use the flatpak-builder one liner?
+
+`flatpak-builder --keep-build-dirs --repo=repo app org.gnome.Manifest.json`
+
+This almost does what we would want, but not quite. If you build this way it will always try to fetch your 
modules from the source specified in the manifest, but we want to use our local checkout instead. This is 
fine if you only build the `master` branch but MRs need to be able to change the source to their checkout.
+
+To achieve this we use the `--stop-at=module` argument which will build all of the dependencies up to your 
module from the manifest. Then we take over and need to install the application ourselves. This is why your 
config
+s `MESON_ARGS` variable needs to be kept in sync with your module's config options in the manifest.
+
 ### Basic building with CI
+
 The main goal here is to make sure our CI runs for every commit and MR and the project is buildable using 
the same base across GNOME, the Flatpak env.
 
 1. Create a .gitlab-ci.yml file in the git repository. This file will contain the instructions for CI.
@@ -180,17 +192,6 @@ stop_review:
 
 ```
 
-## FAQ
-
-### Why not use the flatpak-builder one liner?
-
-`flatpak-builder --keep-build-dirs --repo=repo app org.gnome.Manifest.json`
-
-This almost does what we would want, but not quite. If you build this way it will always try to fetch your 
modules from the source specified in the manifest, but we want to use our local checkout instead. This is 
fine if you only build the `master` branch but MRs need to be able to change the source to their checkout.
-
-To achieve this we use the `--stop-at=module` argument which will build all of the dependencies up to your 
module from the manifest. Then we take over and need to install the application ourselves. This is why your 
config
-s `MESON_ARGS` variable needs to be kept in sync with your module's config options in the manifest.
-
 # Parallel installation
 For GLib & Gtk+ based apps we need to generate a different dbus id, so different versions can be installed 
and ran alongside. For that, we created the concept of "profiles" in the building phase. This is a bit tricky 
and also needs to be done all at once for the major part.
 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]