brl/gnome-shell
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
wip/smcv/issue2538
gnome-shell/.gitlab-ci.yml

138 lines
3.6 KiB
YAML
Raw Permalink Normal View History

ci: Build Extensions flatpak bundle GNOME apps use (or are encouraged to use) flatpak in their CI setup[0], so do that for the Extensions app as well and get: - test building the flatpak - produce a bundle for download and testing - publish the build in gnome-nightly [0] https://gitlab.gnome.org/GNOME/Initiatives/wikis/DevOps-with-Flatpak https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1133
2020-03-19 17:20:27 +00:00
include: 'https://gitlab.gnome.org/GNOME/citemplates/raw/master/flatpak/flatpak_ci_initiative.yml'
ci: Add minimal continuous integration Building gnome-shell is tricky due to the tight coupling with mutter, but until we figure out the best way forward, we can at least perform some basic syntax checking on the javascript bits. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/367
2019-01-28 02:34:48 +00:00
stages:
gitlab-ci.yml: Add check for issue or MR URL This adds a pipeline stage for merge requests that checks that the commit message contains an URL to either a issue or a merge request. This means that for merge requests without corresponding issues will always fail initially, as the merge request URL is not known until after it is created. This is still arguably better than accidentally merging merge requests without URLs. Taken from https://gitlab.gnome.org/GNOME/mutter/merge_requests/440. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/410
2019-02-13 19:34:07 +00:00
- review
ci: Add build stage So far we are only performing a basic syntax check on javascript sources; it's time to test the C code as well. As mutter is tightly coupled, we bite the bullet and build it as well, either using a matching branch (if it exists), or current master. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/408
2019-02-12 16:53:42 +00:00
- build
ci: Add test stage We never gained a proper test suite, but run at least the tests we have. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/408
2019-02-12 21:39:47 +00:00
- test
ci: Build Extensions flatpak bundle GNOME apps use (or are encouraged to use) flatpak in their CI setup[0], so do that for the Extensions app as well and get: - test building the flatpak - produce a bundle for download and testing - publish the build in gnome-nightly [0] https://gitlab.gnome.org/GNOME/Initiatives/wikis/DevOps-with-Flatpak https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1133
2020-03-19 17:20:27 +00:00
- deploy
ci: Add minimal continuous integration Building gnome-shell is tricky due to the tight coupling with mutter, but until we figure out the best way forward, we can at least perform some basic syntax checking on the javascript bits. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/367
2019-01-28 02:34:48 +00:00
variables:
ci: Build Extensions flatpak bundle GNOME apps use (or are encouraged to use) flatpak in their CI setup[0], so do that for the Extensions app as well and get: - test building the flatpak - produce a bundle for download and testing - publish the build in gnome-nightly [0] https://gitlab.gnome.org/GNOME/Initiatives/wikis/DevOps-with-Flatpak https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1133
2020-03-19 17:20:27 +00:00
BUNDLE: "extensions-git.flatpak"
ci: Add minimal continuous integration Building gnome-shell is tricky due to the tight coupling with mutter, but until we figure out the best way forward, we can at least perform some basic syntax checking on the javascript bits. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/367
2019-01-28 02:34:48 +00:00
JS_LOG: "js-report.txt"
ci: Check that pot file is generated correctly This is to guard against the now infamous xgettext bug[0]. [0] https://savannah.gnu.org/bugs/?50920#comment5 https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/408
2019-02-09 03:51:00 +00:00
POT_LOG: "pot-update.txt"
ci: Add minimal continuous integration Building gnome-shell is tricky due to the tight coupling with mutter, but until we figure out the best way forward, we can at least perform some basic syntax checking on the javascript bits. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/367
2019-01-28 02:34:48 +00:00
ci: Add build stage So far we are only performing a basic syntax check on javascript sources; it's time to test the C code as well. As mutter is tightly coupled, we bite the bullet and build it as well, either using a matching branch (if it exists), or current master. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/408
2019-02-12 16:53:42 +00:00
.only_default: &only_default
only:
- branches
- tags
- merge_requests
gitlab-ci.yml: Add check for issue or MR URL This adds a pipeline stage for merge requests that checks that the commit message contains an URL to either a issue or a merge request. This means that for merge requests without corresponding issues will always fail initially, as the merge request URL is not known until after it is created. This is still arguably better than accidentally merging merge requests without URLs. Taken from https://gitlab.gnome.org/GNOME/mutter/merge_requests/440. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/410
2019-02-13 19:34:07 +00:00
check_commit_log:
ci: Switch to mutter's v3 docker image As we start depending on newer stuff, switch to an image that is based on a more recent base image to minimize the pain a bit. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/792
2019-10-29 01:09:46 +00:00
image: registry.gitlab.gnome.org/gnome/mutter/master:v3
gitlab-ci.yml: Add check for issue or MR URL This adds a pipeline stage for merge requests that checks that the commit message contains an URL to either a issue or a merge request. This means that for merge requests without corresponding issues will always fail initially, as the merge request URL is not known until after it is created. This is still arguably better than accidentally merging merge requests without URLs. Taken from https://gitlab.gnome.org/GNOME/mutter/merge_requests/440. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/410
2019-02-13 19:34:07 +00:00
stage: review
ci: Ensure we clone a deep enough history for commit review It seems gitlab changed something recently in the default clone depth which made MRs with >10 commits to obscurely fail in the review stage. As per https://docs.gitlab.com/ee/ci/yaml/#shallow-cloning, bump it to 100 to allow bigger MRs. https://gitlab.gnome.org/GNOME/mutter/merge_requests/551
2019-04-24 10:24:12 +00:00
variables:
GIT_DEPTH: "100"
gitlab-ci.yml: Add check for issue or MR URL This adds a pipeline stage for merge requests that checks that the commit message contains an URL to either a issue or a merge request. This means that for merge requests without corresponding issues will always fail initially, as the merge request URL is not known until after it is created. This is still arguably better than accidentally merging merge requests without URLs. Taken from https://gitlab.gnome.org/GNOME/mutter/merge_requests/440. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/410
2019-02-13 19:34:07 +00:00
script:
- ./.gitlab-ci/check-commit-log.sh
only:
- merge_requests
ci: Add minimal continuous integration Building gnome-shell is tricky due to the tight coupling with mutter, but until we figure out the best way forward, we can at least perform some basic syntax checking on the javascript bits. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/367
2019-01-28 02:34:48 +00:00
js_check:
ci: Use custom image for JS checks Running dnf to update and install additional packages every time the job is executed slows down the CI pipeline. Avoid this by using another custom images for JS source checks. In addition to the js shell we use for the existing syntax check, also include eslint for future jobs and some extension-specific tooling to make the image more useful to extension authors. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/408
2019-02-13 04:49:37 +00:00
image: registry.gitlab.gnome.org/gnome/gnome-shell/extension-ci:v1
ci: Merge 'source_check' stage into 'review' GNOME apps use 'review' for the CI stage that generates and exports a flatpak bundle after a successful build, so they need some other name for anything that is checked before building; that's how we ended up with the somewhat awkward 'source_check' stage (inherited from Polari). But since the commit log check added a 'review' stage that runs pre-build, use that for all checks that are performed before the build stage. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
2019-07-23 22:29:15 +00:00
stage: review
ci: Add minimal continuous integration Building gnome-shell is tricky due to the tight coupling with mutter, but until we figure out the best way forward, we can at least perform some basic syntax checking on the javascript bits. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/367
2019-01-28 02:34:48 +00:00
script:
- find js -name '*.js' -exec js60 -c -s '{}' ';' 2>&1 | tee $JS_LOG
- (! grep -q . $JS_LOG)
ci: Add build stage So far we are only performing a basic syntax check on javascript sources; it's time to test the C code as well. As mutter is tightly coupled, we bite the bullet and build it as well, either using a matching branch (if it exists), or current master. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/408
2019-02-12 16:53:42 +00:00
<<: *only_default
ci: Add minimal continuous integration Building gnome-shell is tricky due to the tight coupling with mutter, but until we figure out the best way forward, we can at least perform some basic syntax checking on the javascript bits. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/367
2019-01-28 02:34:48 +00:00
artifacts:
paths:
- ${JS_LOG}
when: on_failure
ci: Add build stage So far we are only performing a basic syntax check on javascript sources; it's time to test the C code as well. As mutter is tightly coupled, we bite the bullet and build it as well, either using a matching branch (if it exists), or current master. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/408
2019-02-12 16:53:42 +00:00
ci: Add eslint job to review stage We have now reduced the number of eslint errors enough to add it to the CI pipeline. There are still plenty of errors left though, so we cannot simply run eslint and fail on any errors. So instead, run it through a fancy script that: - generates an eslint report using the "regular" configuration - generates an eslint report using the "legacy" configuration - creates a combined report with errors common to both configurations When the pipeline is running for a branch or tag, the final report is printed out and the job succeeds (we know there are errors left); when the pipelne is running for a merge request, we fail if any errors are reported for the lines modified/added by the MR. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
2019-06-30 11:05:04 +00:00
eslint:
image: registry.gitlab.gnome.org/gnome/gnome-shell/extension-ci:v1
stage: review
script:
- ./.gitlab-ci/run-eslint.sh
<<: *only_default
artifacts:
paths:
- reports
when: always
ci: Check that files with translatable strings are listed in POTFILES Also known as "Piotr Drąg Bot". We will soon make sure that files processed by xgettext don't use template strings. To make that check as adequate as possible, ensure that no source code files are missing from POTFILES. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1016
2020-02-18 18:05:47 +00:00
potfile_check:
image: registry.gitlab.gnome.org/gnome/gnome-shell/extension-ci:v1
stage: review
script:
- ./.gitlab-ci/check-potfiles.sh
<<: *only_default
ci: Prohibit template strings in translatable files Sadly, xgettext's dealing with template strings is abysimal, so we had to stop using them in files with translatable strings. Make sure we don't accidentally sneak in template strings again(*) and enforce that rule in a CI job. (*) easy "mistake", considering how much nicer they are than String.prototype.format() https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1016
2020-02-18 16:08:23 +00:00
no_template_check:
image: registry.gitlab.gnome.org/gnome/gnome-shell/extension-ci:v1
stage: review
script:
- ./.gitlab-ci/check-template-strings.sh
<<: *only_default
ci: Add build stage So far we are only performing a basic syntax check on javascript sources; it's time to test the C code as well. As mutter is tightly coupled, we bite the bullet and build it as well, either using a matching branch (if it exists), or current master. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/408
2019-02-12 16:53:42 +00:00
build:
ci: Switch to mutter's v3 docker image As we start depending on newer stuff, switch to an image that is based on a more recent base image to minimize the pain a bit. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/792
2019-10-29 01:09:46 +00:00
image: registry.gitlab.gnome.org/gnome/mutter/master:v3
ci: Add build stage So far we are only performing a basic syntax check on javascript sources; it's time to test the C code as well. As mutter is tightly coupled, we bite the bullet and build it as well, either using a matching branch (if it exists), or current master. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/408
2019-02-12 16:53:42 +00:00
stage: build
before_script:
- .gitlab-ci/checkout-mutter.sh
- meson mutter mutter/build --prefix=/usr -Dtests=false
- ninja -C mutter/build install
script:
ci: Turn on -Werror Now that all compiler warnings are fixed, let's try to keep it that way by making warnings fatal during CI. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/709
2019-09-10 14:02:44 +00:00
- meson . build -Dbuiltype=debugoptimized -Dman=false --werror
ci: Add build stage So far we are only performing a basic syntax check on javascript sources; it's time to test the C code as well. As mutter is tightly coupled, we bite the bullet and build it as well, either using a matching branch (if it exists), or current master. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/408
2019-02-12 16:53:42 +00:00
- ninja -C build
- ninja -C build install
<<: *only_default
ci: Add test stage We never gained a proper test suite, but run at least the tests we have. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/408
2019-02-12 21:39:47 +00:00
artifacts:
expire_in: 1 day
paths:
- mutter
- build
test:
ci: Switch to mutter's v3 docker image As we start depending on newer stuff, switch to an image that is based on a more recent base image to minimize the pain a bit. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/792
2019-10-29 01:09:46 +00:00
image: registry.gitlab.gnome.org/gnome/mutter/master:v3
ci: Add test stage We never gained a proper test suite, but run at least the tests we have. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/408
2019-02-12 21:39:47 +00:00
stage: test
ci: Set XDG_RUNTIME_DIR for tests Mutter's backend code depends on it being set. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/691
2019-08-25 15:52:49 +00:00
variables:
XDG_RUNTIME_DIR: "$CI_PROJECT_DIR/runtime-dir"
ci: Run tests through dbus-run-session Something changed recently in the test initialization code, causing the test-theme invocation to fail. Make sure there is a D-Bus session by running the tests through dbus-run-session to get them going again. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/796
2019-10-30 18:15:26 +00:00
NO_AT_BRIDGE: "1"
ci: Add test stage We never gained a proper test suite, but run at least the tests we have. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/408
2019-02-12 21:39:47 +00:00
before_script:
- ninja -C mutter/build install
script:
ci: Run tests through dbus-run-session Something changed recently in the test initialization code, causing the test-theme invocation to fail. Make sure there is a D-Bus session by running the tests through dbus-run-session to get them going again. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/796
2019-10-30 18:15:26 +00:00
- dbus-run-session -- xvfb-run meson test -C build --no-rebuild
ci: Add test stage We never gained a proper test suite, but run at least the tests we have. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/408
2019-02-12 21:39:47 +00:00
<<: *only_default
artifacts:
expire_in: 1 day
paths:
- build/meson-logs/testlog.txt
when: on_failure
ci: Check that pot file is generated correctly This is to guard against the now infamous xgettext bug[0]. [0] https://savannah.gnu.org/bugs/?50920#comment5 https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/408
2019-02-09 03:51:00 +00:00
test-pot:
ci: Switch to mutter's v3 docker image As we start depending on newer stuff, switch to an image that is based on a more recent base image to minimize the pain a bit. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/792
2019-10-29 01:09:46 +00:00
image: registry.gitlab.gnome.org/gnome/mutter/master:v3
ci: Check that pot file is generated correctly This is to guard against the now infamous xgettext bug[0]. [0] https://savannah.gnu.org/bugs/?50920#comment5 https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/408
2019-02-09 03:51:00 +00:00
stage: test
before_script:
- ninja -C mutter/build install
script:
# Check that pot files are generated correctly:
# https://savannah.gnu.org/bugs/?50920#comment5
- ninja -C build gnome-shell-pot 2>&1 | awk '
BEGIN { start=0; }
start==1 { print $0; }
/gnome-shell-pot/ { start=1; }
' | tee $POT_LOG
- (! grep -q . $POT_LOG)
<<: *only_default
ci: Build Extensions flatpak bundle GNOME apps use (or are encouraged to use) flatpak in their CI setup[0], so do that for the Extensions app as well and get: - test building the flatpak - produce a bundle for download and testing - publish the build in gnome-nightly [0] https://gitlab.gnome.org/GNOME/Initiatives/wikis/DevOps-with-Flatpak https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1133
2020-03-19 17:20:27 +00:00
flatpak:
stage: build
variables:
SUBPROJECT: "subprojects/extensions-app"
# Your manifest path
MANIFEST_PATH: "$SUBPROJECT/build-aux/flatpak/org.gnome.Extensions.json"
RUNTIME_REPO: "https://nightly.gnome.org/gnome-nightly.flatpakrepo"
FLATPAK_MODULE: "gnome-extensions-app"
APP_ID: "org.gnome.Extensions"
MESON_ARGS: "$SUBPROJECT"
extends: .flatpak
before_script:
- flatpak run --command=$SUBPROJECT/generate-translations.sh
--filesystem=host org.gnome.Sdk//master
<<: *only_default
nightly:
extends: '.publish_nightly'
variables:
BUNDLES: '$BUNDLE'
Reference in New Issue Copy Permalink