[Initiatives.wiki] Update DevOps with Flatpak
- From: Carlos Soriano <csoriano src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [Initiatives.wiki] Update DevOps with Flatpak
- Date: Mon, 10 Dec 2018 13:26:06 +0000 (UTC)
commit 657cec562197c44def60a106f7a048f656730a87
Author: Carlos Soriano <csoriano1618 gmail com>
Date: Mon Dec 10 13:26:00 2018 +0000
Update DevOps with Flatpak
DevOps-with-Flatpak.md | 100 +++++++++++++------------------------------------
1 file changed, 25 insertions(+), 75 deletions(-)
---
diff --git a/DevOps-with-Flatpak.md b/DevOps-with-Flatpak.md
index 7dac70d..ce2626a 100644
--- a/DevOps-with-Flatpak.md
+++ b/DevOps-with-Flatpak.md
@@ -5,7 +5,7 @@
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.
-1. Add a docker image, we provide the nightly flatpak sdk.
+1. Add the template we provide
1. Build with flatpak
1. Run the tests, including those that require a display using the mock tool
[xvfb-run](http://manpages.ubuntu.com/manpages/xenial/man1/xvfb-run.1.html).
@@ -15,25 +15,18 @@ stages:
- test
flatpak:
- image: registry.gitlab.gnome.org/gnome/gnome-runtime-images/gnome:master
stage: test
-
variables:
- # Replace with your manifest path
- MANIFEST_PATH: "build-aux/flatpak/org.gnome.AppName.json"
+ MANIFEST_PATH: "build-aux/flatpak/org.gnome.NautilusDevel.yml"
+ MESON_ARGS: "-Dprofile=Devel -Dtests=all"
+ FLATPAK_MODULE: "nautilus"
RUNTIME_REPO: "https://sdk.gnome.org/gnome-nightly.flatpakrepo"
- # Replace with your application name, as written in the manifest
- FLATPAK_MODULE: "app-name"
- # Make sure to keep this in sync with the Flatpak manifest, all arguments
- # are passed except the config-args because we build it ourselves
- CONFIGURE_ARGS: "-Dtests=all"
-
- script:
- - flatpak-builder --stop-at=${FLATPAK_MODULE} app ${MANIFEST_PATH}
- - flatpak build app meson --prefix=/app ${CONFIGURE_ARGS} _build
- - flatpak build app ninja -C _build install
- # Run tests inside the Flatpak env emulating a display
- - xvfb-run -a -s "-screen 0 1024x768x24" flatpak build app ninja -C _build test
+ APP_ID: "org.gnome.NautilusDevel"
+ extends: .flatpak
+ only:
+ - schedules
+ - web
+ - tags
```
### Flatpak bundle for every MR and commit
@@ -43,72 +36,29 @@ The main goal is to create flatpak bundles so people can install them.
1. Create a GitLab artifact to save the generated bundle for two days
1. Use a caching mechanism to reduce build times
-To achieve all that, we will extend the previous CI file.
+To achieve all that, we will extend the previous CI file. The result will be exposed in the MR using a
GitLab feature called Review Apps. Good thing is that is already handled by the template and we just need to
add a "review" stage for using the Review Apps feature.
-Adding the following lines to the `script` section will generate a Flatpak bundle after each build:
-```yaml
-- flatpak-builder --finish-only --repo=repo app ${MANIFEST_PATH}
-# The last positional argument is the name of your application.
-- flatpak build-bundle repo ${BUNDLE} --runtime-repo=${RUNTIME_REPO} org.gnome.AppName
-```
-
-`${BUNDLE}` is a placeholder variable for the resulting file name. It will also be used when defining a
build artifact, so set it up as global variable and not inside the scope of the flatpak job:
-
-```yaml
-# The actual name is usually the name of the application.
-BUNDLE: "app-name.flatpak"
-```
-
-Now we need to save the file on the server. For that we use what is called
[artifacts](https://docs.gitlab.com/ce/user/project/pipelines/job_artifacts.html) in GitLab.
-```yaml
-artifacts:
- paths:
- - ${BUNDLE}
- expire_in: 30 days
-```
-
-And finally we want to expose the build in the MR using GitLab Review Apps. To do so we will add a new stage
`review` and 2 new jobs one of whom will depend on the `flatpak` job defined above. This is just boilerplate
for the most part but there will be 2 fields that you will have to adjusts.
-
-There are 2 `except:` keys with one of the values being `master@GNOME/project-url`. You will need to replace
`project-url` with the path of you module, can be found by looking at the url of the project. For example for
`nautilus`, with project url `gitlab.gnome.org/GNOME/nautilus`, this value is [set][except_master] to
`master@GNOME/nautilus`.
+The bundles will be created for all MRs, which means all branches that do not contain "gnome-*" in their
names and also it won't be created for the master branch.
-This is done so setting up environments for the master branch of the project can be avoided since there will
be no Merge Requests made from it. This is particularly useful since Gitlab Environments are full Docker
environments which takes considerable resources. Note that the CI will still produce and make available
Flatpak bundles from the `master` branch accessible on the CI/job logs, it won't just create a deployment for
it.
+Add the following to the CI file:
```yaml
review:
- stage: review
+ stage: deploy
dependencies:
- - flatpak
- script:
- - echo "Generating flatpak deployment"
- artifacts:
- paths:
- - ${BUNDLE}
- expire_in: 30 days
- environment:
- name: review/$CI_COMMIT_REF_NAME
- url: https://gitlab.gnome.org/$CI_PROJECT_PATH/-/jobs/$CI_JOB_ID/artifacts/raw/${BUNDLE}
- on_stop: stop_review
- except:
- - tags
- # don't run on stable branches
- - /^gnome-\d-\d\d$/
- # No need to run on the upstream master branch either
- - master@GNOME/project-url
+ - 'flatpak devel'
+ extends: '.review'
stop_review:
- stage: review
- script:
- - echo "Stopping flatpak deployment"
- when: manual
- environment:
- name: review/$CI_COMMIT_REF_NAME
- action: stop
- except:
- - tags
- # don't run on stable branches
- - /^gnome-\d-\d\d$/
- # No need to run on the upstream master branch either
- - master@GNOME/project-url
+ stage: deploy
+ extends: '.stop_review'
+
+```
+And on the `stages` section, add a "review" stage. The result of the stage section will be:
+```yaml
+stages:
+ - test
+ - deploy
```
### Saving build and test logs & cache builds
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]