[Initiatives.wiki] Update DevOps with Flatpak
- From: Jordan Petridis <jpetridis src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [Initiatives.wiki] Update DevOps with Flatpak
- Date: Wed, 1 Aug 2018 20:16:57 +0000 (UTC)
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]