isa/gnome-shell
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
bbd3275dad
gnome-shell/.gitlab-ci.yml

89 lines
2.1 KiB
YAML
Raw Normal View History

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-27 21:34:48 -05: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 14:34:07 -05:00
- 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-27 21:34:48 -05:00
- source_check
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 11:53:42 -05: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 16:39:47 -05:00
- test
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-27 21:34:48 -05:00
variables:
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-08 22:51:00 -05: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-27 21:34:48 -05: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 11:53:42 -05: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 14:34:07 -05:00
check_commit_log:
ci: Use custom image for commit log check We can speed up the check a little bit by using an image that already contains git, so do that. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/480
2019-04-03 07:28:32 -04:00
image: registry.gitlab.gnome.org/gnome/mutter/master:v1
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 14:34:07 -05: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 06:24:12 -04: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 14:34:07 -05: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-27 21:34:48 -05: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-12 23:49:37 -05:00
image: registry.gitlab.gnome.org/gnome/gnome-shell/extension-ci:v1
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-27 21:34:48 -05:00
stage: source_check
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 11:53:42 -05:00
<<: *only_default
ci: Skip source_check stage when appropriate We don't have to run the static analyzer on javascript sources when no javascript source was changed. https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/408
2019-02-12 14:17:07 -05:00
only:
changes:
- js/**/*
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-27 21:34:48 -05: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 11:53:42 -05:00
build:
image: registry.gitlab.gnome.org/gnome/gnome-shell/master:v1
stage: build
before_script:
- .gitlab-ci/checkout-mutter.sh
- meson mutter mutter/build --prefix=/usr -Dtests=false
- ninja -C mutter/build install
script:
- meson . build -Dbuiltype=debugoptimized
- 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 16:39:47 -05:00
artifacts:
expire_in: 1 day
paths:
- mutter
- build
test:
image: registry.gitlab.gnome.org/gnome/gnome-shell/master:v1
stage: test
before_script:
- ninja -C mutter/build install
script:
- xvfb-run meson test -C build --no-rebuild
<<: *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-08 22:51:00 -05:00
test-pot:
image: registry.gitlab.gnome.org/gnome/gnome-shell/master:v1
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
Reference in New Issue Copy Permalink