...
 
Commits (3)
---
# Global Options Go Here
IndentWidth: 4
ColumnLimit: 80
---
Language: Cpp
BasedOnStyle: Google
AccessModifierOffset: -3 # to match cpplint
AllowShortIfStatementsOnASingleLine: false
AllowShortLoopsOnASingleLine: false
CommentPragmas: '^ NOLINT'
DerivePointerAlignment: false
ForEachMacros: []
IndentPPDirectives: AfterHash
IndentWidth: 4
MacroBlockBegin: "^JSNATIVE_TEST_FUNC_BEGIN$"
MacroBlockEnd: "^JSNATIVE_TEST_FUNC_END$"
PointerAlignment: Left # Google style allows both, but clang-format doesn't
SpacesBeforeTrailingComments: 2
---
# We should use eslint --fix instead, but we need to find a way to get that to
# operate on diffs like clang-format does.
Language: JavaScript
DisableFormat: true
...
installed-tests/js/jasmine.js
installed-tests/js/modules/overrides/WarnLib.js
modules/jsUnit.js
{
"env": {
"es6": true
},
"extends": "eslint:recommended",
"rules": {
"array-bracket-newline": [
"error",
"consistent"
],
"array-bracket-spacing": [
"error",
"never"
],
"arrow-spacing": "error",
"brace-style": "error",
"comma-spacing": [
"error",
{
"before": false,
"after": true
}
],
"indent": [
"error",
4,
{
"ignoredNodes": [
"CallExpression[callee.object.name=GObject][callee.property.name=registerClass] > ClassExpression:first-child"
],
"MemberExpression": "off"
}
],
"key-spacing": [
"error",
{
"beforeColon": false,
"afterColon": true
}
],
"keyword-spacing": [
"error",
{
"before": true,
"after": true
}
],
"linebreak-style": [
"error",
"unix"
],
"no-empty": [
"error",
{
"allowEmptyCatch": true
}
],
"no-implicit-coercion": [
"error",
{
"allow": ["!!"]
}
],
"no-restricted-properties": [
"error",
{
"object": "Lang",
"property": "bind",
"message": "Use arrow notation or Function.prototype.bind()"
},
{
"object": "Lang",
"property": "Class",
"message": "Use ES6 classes"
}
],
"nonblock-statement-body-position": [
"error",
"below"
],
"object-curly-newline": [
"error",
{
"consistent": true
}
],
"object-curly-spacing": "error",
"prefer-template": "error",
"quotes": [
"error",
"single",
{
"avoidEscape": true
}
],
"semi": [
"error",
"always"
],
"semi-spacing": [
"error",
{
"before": false,
"after": true
}
],
"space-before-blocks": "error",
"space-infix-ops": [
"error",
{
"int32Hint": false
}
]
},
"globals": {
"ARGV": false,
"Debugger": false,
"GIRepositoryGType": false,
"imports": false,
"Intl": false,
"log": false,
"logError": false,
"print": false,
"printerr": false,
"window": false
},
"parserOptions": {
"ecmaVersion": 2017
}
}
services:
- docker
stages:
- source_check
- test
- thorough_tests
- manual
- deploy
.CI_header: &CI_header 'echo;
echo "*********************************************";
echo "*** JavaScript bindings for GNOME ***";
echo "*** Continuous Integration ***";
echo "*********************************************";
echo;
'
.CI_footer: &CI_footer 'echo;
echo "*********************************************";
echo "*** See you soon ***";
echo "*********************************************";
'
.JHBuild files: &JHB_files [.cache/jhbuild/build/gjs/*.log, .cache/jhbuild/build/gjs/Makefile, .cache/jhbuild/build/gjs/configure]
.Coverage files: &cov_files [configure, Makefile, analysis/, ./*.log, ./*.trs, ./installed-tests/scripts/*.log, ./installed-tests/scripts/*.trs, coverage/]
.Regular files: &reg_files [configure, Makefile, analysis/, ./*.log, ./*.trs, ./installed-tests/scripts/*.log, ./installed-tests/scripts/*.trs]
.Flatpak files: &pak_files [./*.flatpak]
.jhbuild: &jhbuild
artifacts:
name: log_jhbuild
when: always
paths: *JHB_files
.coverage: &coverage
artifacts:
name: log_coverage
when: always
paths: *cov_files
.package: &package
artifacts:
name: log_package
paths: *pak_files
# Regular build
.build: &build
when: on_success
artifacts:
name: log
when: always
paths: *reg_files
script:
# CI starts here. Previous messages are from GitLab Runner setup.
- *CI_header
# GitLab is keeping some files between jobs. Remove them.
- rm -rf configure Makefile *.log analysis
# Run static code analysis OR
# Build GJS
- 'if [[ -n "${CODECHECK}" ]]; then
$(pwd)/test/test-ci.sh "$CODECHECK";
else
$(pwd)/test/test-ci.sh GJS;
fi
'
# Run installed extra tests
- 'if [[ $BUILD_OPTS == *"--enable-installed-tests"* ]]; then
$(pwd)/test/test-ci.sh GJS_EXTRA;
fi
'
# Run code coverage tests
- 'if [[ $BUILD_OPTS == *"--enable-code-coverage"* ]]; then
$(pwd)/test/test-ci.sh GJS_COVERAGE;
fi
'
# Run valgrind
- 'if [[ $BUILD_OPTS == *"--enable-valgrind"* ]]; then
$(pwd)/test/test-ci.sh VALGRIND;
fi
'
# Run the script tests again (to assure they are working)
- 'if [[ -n "${SCRIPTCHECK}" ]]; then
$(pwd)/test/test-ci.sh SH_CHECKS;
fi
'
# Done
- *CI_footer
# Cross (multi architecture) build
.qemu: &multiarch
artifacts:
name: log
when: always
paths: *reg_files
image: docker:latest
services:
- docker:dind
script:
# CI starts here. Previous messages are from GitLab Runner setup.
- *CI_header
# Register QEMU archs
- docker run --rm --privileged multiarch/qemu-user-static:register --reset
# Run the multiarch test job using QEMU
- 'docker run -v $(pwd):/cwd
-e TEST=check -e TASK_ID=$TASK_ID $IMAGE
bash -e -c "cd /cwd && test/test-ci.sh GJS"
'
# Done
- *CI_footer
#############################################
# Regular tests #
#############################################
# Test despite any changes in the Docker image
# SpiderMonkey has been configured with --enable-debug
fedora:
<<: *build
stage: source_check
image: registry.gitlab.gnome.org/gnome/gjs:job-142243_SM60-debug-gcc.fedora-dev # pinned on purpose
variables:
TASK_ID: "fedora-x86_64-gcc-debug-default-check"
TEST: "check"
WARNINGS: "count"
except:
- schedules
sanitizer_gcc:
<<: *build
stage: test
image: registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.fedora-dev
variables:
TASK_ID: "fedora-x86_64-gcc-default-ubsan_asan-check"
BUILD_OPTS: "--enable-asan --enable-ubsan"
TEST: "check"
except:
- schedules
# There are a lot of debug log statements that are ifdef'd out in normal usage.
# These sometimes get invalid expressions in them, leading to annoyance the
# next time you try to use debug logging.
with_logging:
<<: *build
stage: test
image: registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.ubuntu-dev
variables:
TASK_ID: "ubuntu-x86_64-clang-default-logging-check"
CC: clang
BUILD_OPTS: "CPPFLAGS='-DGJS_VERBOSE_ENABLE_PROPS=1 -DGJS_VERBOSE_ENABLE_MARSHAL=1 -DGJS_VERBOSE_ENABLE_LIFECYCLE=1 -DGJS_VERBOSE_ENABLE_GI_USAGE=1 -DGJS_VERBOSE_ENABLE_GCLOSURE=1 -DGJS_VERBOSE_ENABLE_GSIGNAL=1'"
TEST: "check"
SCRIPTCHECK: "yes"
ENABLE_GTK: "yes"
except:
- schedules
with_systemtap:
<<: *build
stage: test
image: registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.fedora-dev
variables:
TASK_ID: "fedora-x86_64-gcc-default-systemtap-check"
TEST: "check"
BUILD_OPTS: "--enable-systemtap"
except:
- schedules
no_graphics:
<<: *build
stage: test
image: registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.fedora-dev
variables:
TASK_ID: "fedora-x86_64-gcc-default-without_gtk-check"
TEST: "check"
BUILD_OPTS: "--without-cairo --without-gtk"
SCRIPTCHECK: "yes"
except:
- schedules
no_profiler:
<<: *build
stage: test
image: registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.fedora-dev
variables:
TASK_ID: "fedora-x86_64-gcc-default-disable_profiler-check"
TEST: "check"
BUILD_OPTS: "--disable-profiler"
except:
- schedules
no_readline:
<<: *build
stage: test
image: registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.fedora-dev
variables:
TASK_ID: "fedora-x86_64-gcc-default-disable_readline-check"
TEST: "check"
BUILD_OPTS: "--disable-readline"
except:
- schedules
# Generates
# The Code Coverage Report
coverage-automatic:
<<: *build
<<: *coverage
stage: source_check
image: registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.ubuntu-dev
variables:
TASK_ID: "coverage"
BUILD_OPTS: "--enable-code-coverage"
coverage: '/^Lines:.\d+.\d+.(\d+\.\d+\%)/'
except:
- schedules
only:
refs:
- master@GNOME/gjs
# Publishes
# The reports (coverage and code statistics)
pages:
stage: deploy
dependencies:
- coverage-automatic
- code_statistics
script:
- mv $(pwd)/coverage/ public/ || true
- mv $(pwd)/analysis/report.txt public/ || true
artifacts:
paths:
- public
only:
refs:
- master@GNOME/gjs
except:
variables:
- $CRON_TASK == "BUILD_CI_IMAGES"
#############################################
# Static Analyzers #
#############################################
cppcheck:
<<: *build
stage: source_check
image: registry.gitlab.gnome.org/gnome/gjs:fedora.static-analysis
variables:
TASK_ID: "cppcheck"
CODECHECK: "CPPCHECK"
except:
- schedules
- tags
cpplint:
<<: *build
stage: source_check
image: registry.gitlab.gnome.org/gnome/gjs:fedora.static-analysis
variables:
TASK_ID: "cpplint"
CODECHECK: "CPPLINT"
except:
- schedules
- tags
eslint:
<<: *build
stage: source_check
image: registry.gitlab.gnome.org/gnome/gjs:fedora.static-analysis
variables:
TASK_ID: "eslint"
CODECHECK: "ESLINT"
except:
- schedules
- tags
#############################################
# Daily jobs / Frequent jobs #
#############################################
codequality:
stage: source_check
image: docker:latest
variables:
TASK_ID: "codequality"
DOCKER_DRIVER: overlay
services:
- docker:dind
script:
- docker pull codeclimate/codeclimate
- docker run --env CODECLIMATE_CODE="$PWD" --volume "$PWD":/code --volume /var/run/docker.sock:/var/run/docker.sock --volume /tmp/cc:/tmp/cc codeclimate/codeclimate analyze -f json > codeclimate.json
artifacts:
paths: [codeclimate.json]
only:
refs:
- master@GNOME/gjs
variables:
- $CRON_FREQUENCY == "Daily"
code_statistics:
<<: *build
stage: source_check
image: registry.gitlab.gnome.org/gnome/gjs:fedora.static-analysis
variables:
TASK_ID: "code_statistics"
CODECHECK: "TOKEI"
only:
variables:
- $CRON_FREQUENCY == "Daily"
sanitizer_clang:
<<: *build
stage: thorough_tests
image: registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.ubuntu-dev
variables:
TASK_ID: "ubuntu-x86_64-clang_ubsan_asan-default-default-check"
CC: clang
BUILD_OPTS: "--enable-asan --enable-ubsan"
TEST: "check"
only:
variables:
- $CRON_FREQUENCY == "Daily"
fedora_gcc:
<<: *build
stage: thorough_tests
image: registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.fedora-dev
variables:
TASK_ID: "fedora-x86_64-gcc-default-default-distcheck"
TEST: "distcheck"
only:
variables:
- $CRON_FREQUENCY == "Daily"
installed_tests:
<<: *build
stage: thorough_tests
image: registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.fedora-dev
variables:
TASK_ID: "fedora-x86_64-gcc-default-default-installed_tests"
BUILD_OPTS: "--enable-installed-tests --prefix=/usr"
only:
variables:
- $CRON_FREQUENCY == "Daily"
#############################################
# Weekly jobs / Non-Frequent jobs #
#############################################
ubuntu_gcc:
<<: *build
stage: source_check
image: registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.ubuntu-dev
variables:
TASK_ID: "ubuntu-x86_64-gcc-default-default-distcheck"
TEST: "distcheck"
only:
variables:
- $CRON_FREQUENCY == "Weekly"
ubuntu_clang:
<<: *build
stage: source_check
image: registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.ubuntu-dev
variables:
TASK_ID: "ubuntu-x86_64-clang-default-default-distcheck"
CC: clang
TEST: "distcheck"
only:
variables:
- $CRON_FREQUENCY == "Weekly"
lts:
<<: *build
<<: *jhbuild
stage: thorough_tests
image: registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.ubuntu-lts
variables:
TASK_ID: "ubuntu_lts-x86_64-gcc-default-default-check"
DEV: jhbuild
TEST: "check"
only:
variables:
- $CRON_FREQUENCY == "Weekly"
valgrind:
<<: *build
stage: thorough_tests
image: registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.fedora-dev
variables:
TASK_ID: "fedora-x86_64-gcc-default-default-valgrind_check"
BUILD_OPTS: "--enable-valgrind --disable-valgrind-helgrind --prefix=/usr"
TEST: "check"
allow_failure: true
only:
variables:
- $CRON_FREQUENCY == "Weekly"
#############################################
# Flatpak packaging (weekly) #
#############################################
flatpak:
<<: *build
<<: *package
stage: deploy
image: registry.gitlab.gnome.org/gnome/gnome-nightly-oci/nightly:master
variables:
TASK_ID: "flatpak packaging"
CODECHECK: "FLATPAK"
APPID: "org.gnome.GjsDevel"
BUNDLE: "org.gnome.GjsDevel.flatpak"
MANIFEST_PATH: "org.gnome.GjsDevel.json"
RUNTIME_REPO: "https://sdk.gnome.org/gnome-nightly.flatpakrepo"
environment:
name: review/$CI_COMMIT_REF_NAME
url: https://gitlab.gnome.org/$CI_PROJECT_PATH/-/jobs/$CI_JOB_ID/artifacts/raw/${BUNDLE}
only:
variables:
- $CRON_FREQUENCY == "Weekly"
#############################################
# SpiderMonkey GC Tests (weekly) #
#############################################
zeal_2:
<<: *build
stage: thorough_tests
image: registry.gitlab.gnome.org/gnome/gjs:SM60-debug-gcc.fedora-dev
variables:
TASK_ID: "fedora-x86_64-gcc-debug-default-check_zeal2"
TEST: "check"
JS_GC_ZEAL: 2
only:
variables:
- $CRON_FREQUENCY == "Weekly"
zeal_4:
<<: *build
stage: thorough_tests
image: registry.gitlab.gnome.org/gnome/gjs:SM60-debug-gcc.fedora-dev
variables:
TASK_ID: "fedora-x86_64-gcc-debug-default-check_zeal4"
TEST: "check"
JS_GC_ZEAL: 4
only:
variables:
- $CRON_FREQUENCY == "Weekly"
zeal_11:
<<: *build
stage: thorough_tests
image: registry.gitlab.gnome.org/gnome/gjs:SM60-debug-gcc.fedora-dev
variables:
TASK_ID: "fedora-x86_64-gcc-debug-default-check_zeal11"
TEST: "check"
JS_GC_ZEAL: 11
only:
variables:
- $CRON_FREQUENCY == "Weekly"
#############################################
# Multiarch Tests (weekly) #
#############################################
armv8:
<<: *multiarch
stage: thorough_tests
variables:
TASK_ID: "fedora-armv8-gcc-default-default-check"
DOCKER_DRIVER: overlay
IMAGE: "registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.fedora-dev.aarch64"
only:
variables:
- $CRON_FREQUENCY == "Weekly"
ppc64le:
<<: *multiarch
stage: thorough_tests
variables:
TASK_ID: "fedora-ppc64le-gcc-default-default-check"
DOCKER_DRIVER: overlay
IMAGE: "registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.fedora-dev.ppc64le"
only:
variables:
- $CRON_FREQUENCY == "Weekly"
#############################################
# Manual Jobs #
#############################################
# Planned as daily
codequality:
stage: manual
image: docker:latest
variables:
TASK_ID: "codequality"
DOCKER_DRIVER: overlay
services:
- docker:dind
script:
- docker pull codeclimate/codeclimate
- docker run --env CODECLIMATE_CODE="$PWD" --volume "$PWD":/code --volume /var/run/docker.sock:/var/run/docker.sock --volume /tmp/cc:/tmp/cc codeclimate/codeclimate analyze -f json > codeclimate.json
artifacts:
paths: [codeclimate.json]
when: manual
except:
- schedules
code_statistics:
<<: *build
stage: manual
image: registry.gitlab.gnome.org/gnome/gjs:fedora.static-analysis
variables:
TASK_ID: "code_statistics"
CODECHECK: "TOKEI"
when: manual
except:
- schedules
coverage:
<<: *build
<<: *coverage
stage: manual
image: registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.ubuntu-dev
variables:
TASK_ID: "coverage"
BUILD_OPTS: "--enable-code-coverage"
coverage: '/^Lines:.\d+.\d+.(\d+\.\d+\%)/'
when: manual
except:
- schedules
sanitizer_clang:
<<: *build
stage: manual
image: registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.ubuntu-dev
variables:
TASK_ID: "ubuntu-x86_64-clang_ubsan_asan-default-default-check"
CC: clang
BUILD_OPTS: "--enable-asan --enable-ubsan"
TEST: "check"
when: manual
except:
- schedules
fedora_gcc:
<<: *build
stage: manual
image: registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.fedora-dev
variables:
TASK_ID: "fedora-x86_64-gcc-default-default-distcheck"
TEST: "distcheck"
when: manual
except:
- schedules
installed_tests:
<<: *build
stage: manual
image: registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.fedora-dev
variables:
TASK_ID: "fedora-x86_64-gcc-default-default-installed_tests"
BUILD_OPTS: "--enable-installed-tests --prefix=/usr"
when: manual
except:
- schedules
# Planned as weekly
ubuntu_gcc:
<<: *build
stage: manual
image: registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.ubuntu-dev
variables:
TASK_ID: "ubuntu-x86_64-gcc-default-default-distcheck"
TEST: "distcheck"
when: manual
except:
- schedules
ubuntu_clang:
<<: *build
stage: manual
image: registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.ubuntu-dev
variables:
TASK_ID: "ubuntu-x86_64-clang-default-default-distcheck"
CC: clang
TEST: "distcheck"
when: manual
except:
- schedules
lts:
<<: *build
<<: *jhbuild
stage: manual
image: registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.ubuntu-lts
variables:
TASK_ID: "ubuntu_lts-x86_64-gcc-default-default-check"
DEV: jhbuild
TEST: "check"
when: manual
except:
- schedules
valgrind:
<<: *build
stage: manual
image: registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.fedora-dev
variables:
TASK_ID: "fedora-x86_64-gcc-default-default-valgrind_check"
BUILD_OPTS: "--enable-valgrind --disable-valgrind-helgrind --prefix=/usr"
TEST: "check"
allow_failure: true
when: manual
except:
- schedules
# Flatpak packaging (weekly)
flatpak:
<<: *build
<<: *package
stage: manual
image: registry.gitlab.gnome.org/gnome/gnome-nightly-oci/nightly:master
variables:
TASK_ID: "flatpak packaging"
CODECHECK: "FLATPAK"
BUNDLE: "org.gnome.GjsDevel.flatpak"
MANIFEST: org.gnome.GjsDevel.json
RUNTIME_REPO: "https://sdk.gnome.org/gnome-nightly.flatpakrepo"
environment:
name: review/$CI_COMMIT_REF_NAME
url: https://gitlab.gnome.org/$CI_PROJECT_PATH/-/jobs/$CI_JOB_ID/artifacts/raw/${BUNDLE}
when: manual
except:
- schedules
# SpiderMonkey GC Tests (weekly)
zeal_2:
<<: *build
stage: manual
image: registry.gitlab.gnome.org/gnome/gjs:SM60-debug-gcc.fedora-dev
variables:
TASK_ID: "fedora-x86_64-gcc-debug-default-check_zeal2"
TEST: "check"
JS_GC_ZEAL: 2
when: manual
except:
- schedules
zeal_4:
<<: *build
stage: manual
image: registry.gitlab.gnome.org/gnome/gjs:SM60-debug-gcc.fedora-dev
variables:
TASK_ID: "fedora-x86_64-gcc-debug-default-check_zeal4"
TEST: "check"
JS_GC_ZEAL: 4
when: manual
except:
- schedules
zeal_11:
<<: *build
stage: manual
image: registry.gitlab.gnome.org/gnome/gjs:SM60-debug-gcc.fedora-dev
variables:
TASK_ID: "fedora-x86_64-gcc-debug-default-check_zeal11"
TEST: "check"
JS_GC_ZEAL: 11
when: manual
except:
- schedules
# Multiarch Tests (weekly)
armv8:
<<: *multiarch
stage: manual
variables:
TASK_ID: "fedora-armv8-gcc-default-default-check"
DOCKER_DRIVER: overlay
IMAGE: "registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.fedora-dev.aarch64"
when: manual
except:
- schedules
ppc64le:
<<: *multiarch
stage: manual
variables:
TASK_ID: "fedora-ppc64le-gcc-default-default-check"
DOCKER_DRIVER: overlay
IMAGE: "registry.gitlab.gnome.org/gnome/gjs:SM60-gcc.fedora-dev.ppc64le"
when: manual
except:
- schedules
#############################################
# Create CI Docker Images #
#############################################
.Docker image template: &create_docker_image
image: docker:latest
stage: deploy
services:
- docker:dind
only:
variables:
- $CRON_TASK == "BUILD_CI_IMAGES"
script:
# CI starts here. Previous messages are from GitLab Runner setup.
- *CI_header
# Skip the build (if requested)
- |
if [[ -z "${CI_COMMIT_MESSAGE##*[skip images]*}" && -z "${CI_COMMIT_MESSAGE##*$NAME*}" ]]; then
echo "== Nothing to do =="
exit 0
fi
# Get multiarch stuff
- |
if [[ -n "${TARGET_ARCH}" ]]; then
docker run --rm --privileged multiarch/qemu-user-static:register --reset
wget https://github.com/multiarch/qemu-user-static/releases/download/v2.12.0/x86_64_qemu-${TARGET_ARCH}-static.tar.gz
fi
# Build using the Dockerfile
- |
if [[ -n "${DOCKERFILE}" ]]; then
docker build -f "$DOCKERFILE" -t "$CI_REGISTRY_IMAGE:$NAME" .
fi
# Where the real magic happens
- |
if [[ -n "${IMAGE}" ]]; then
docker run --name $NAME -v $(pwd):/on-host \
-e BASE=$BASE -e OS=$IMAGE -e BUILD_OPTS=$BUILD_OPTS -e DEV=$DEV -e CC=gcc -e STATIC=$STATIC $IMAGE \
bash -e -c "cd /on-host && test/ci-images.sh BUILD_MOZ"
docker commit $NAME "$CI_REGISTRY_IMAGE:$NAME"
fi
# Prepare to publish
- docker tag "$CI_REGISTRY_IMAGE:$NAME" "$CI_REGISTRY_IMAGE:job-"$CI_JOB_ID"_$NAME"
- docker images
- docker login ${CI_REGISTRY} -u ${CI_REGISTRY_USER} -p ${CI_REGISTRY_PASSWORD}
# Publish (if running on a schedule)
- |
if [[ "${CI_PIPELINE_SOURCE}" == "schedule" ]]; then
docker push "$CI_REGISTRY_IMAGE"
fi
# Done
- *CI_footer
fedora.static-analysis:
<<: *create_docker_image
variables:
BASE: "fedora"
DOCKER_DRIVER: overlay
DOCKERFILE: "test/extra/Dockerfile.fedora.static-analysis"
NAME: "fedora.static-analysis"
SM60-gcc.fedora-dev:
<<: *create_docker_image
variables:
BASE: "fedora"
DEV: "devel"
DOCKER_DRIVER: overlay
IMAGE: "fedora:rawhide"
NAME: "SM60-gcc.fedora-dev"
SM60-debug-gcc.fedora-dev:
<<: *create_docker_image
variables:
BASE: "fedora"
BUILD_OPTS: "--enable-debug"
DEV: "devel"
DOCKER_DRIVER: overlay
IMAGE: "fedora:rawhide"
NAME: "SM60-debug-gcc.fedora-dev"
SM60-gcc.fedora-dev.aarch64:
<<: *create_docker_image
variables:
BASE: "fedora"
DEV: "devel"
DOCKER_DRIVER: overlay
DOCKERFILE: "test/extra/Dockerfile.arm64v8.fedora.29"
IMAGE: "${CI_REGISTRY_IMAGE}:SM60-gcc.fedora-dev.aarch64"
NAME: "SM60-gcc.fedora-dev.aarch64"
STATIC: "qemu"
TARGET_ARCH: "aarch64"
SM60-gcc.fedora-dev.ppc64le:
<<: *create_docker_image
variables:
BASE: "fedora"
DEV: "devel"
DOCKER_DRIVER: overlay
DOCKERFILE: "test/extra/Dockerfile.ppc64le.fedora.29"
IMAGE: "${CI_REGISTRY_IMAGE}:SM60-gcc.fedora-dev.ppc64le"
NAME: "SM60-gcc.fedora-dev.ppc64le"
STATIC: "qemu"
TARGET_ARCH: "ppc64le"
SM60-gcc.ubuntu-lts:
<<: *create_docker_image
variables:
BASE: "debian"
DOCKER_DRIVER: overlay
IMAGE: "ubuntu:18.04"
NAME: "SM60-gcc.ubuntu-lts"
SM60-gcc.ubuntu-dev:
<<: *create_docker_image
variables:
BASE: "debian"
DEV: "devel"
DOCKER_DRIVER: overlay
IMAGE: "ubuntu:devel"
NAME: "SM60-gcc.ubuntu-dev"
# System information #
What is your operating system and version? _(e.g. "Linux, Fedora 29" or "macOS 10.13")_
What is your version of GJS? _(e.g. "1.54.1-fc29.1" or "commit 4ab70ef")_
If the bug is related to GNOME Shell, what is your version of GNOME Shell? _(e.g. "3.30.1-2ubuntu1" or "commit b405ed64")_
# Bug information #
## Steps to reproduce ##
- Step by step, how can you make the problem appear?
- List those steps here.
- If the problem doesn't happen every time, note that as well.
Even better, if the problem can be observed by executing a standalone JS
file, paste that here instead of the steps.
Use code blocks (```js) to format it.
## Current behaviour ##
What happened that made it evident there was a problem?
Copy and paste the exact text of any error messages.
Use code blocks (```) to format them.
If the problem was with GNOME Shell, you may be able to find error
messages in the system journal (`sudo journalctl -xb`).
If GJS or GNOME Shell crashed, please include a stack trace.
For information on how to get a stack trace,
[read this wiki page](https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces/Details).
## Expected behaviour ##
What did you expect to see instead?
/label ~"1. Bug"
# Description #
Explain why this feature should be added.
Specific use cases are best.
# Prior Art #
List any comparable features in other JavaScript environments that you
are aware of.
/label ~"1. Feature"
# Contributing to GJS #
## Introduction ##
Thank you for considering contributing to GJS!
As with any open source project, we can't make it as good as possible
without help from you and others.
We do have some guidelines for contributing, set out in this file.
Following these guidelines helps communicate that you respect the time
of the developers who work on GJS.
In return, they should reciprocate that respect in addressing your
issue, reviewing your work, and helping finalize your merge requests.
### What kinds of contributions we are looking for ###
There are many ways to contribute to GJS, not only writing code.
We encourage all of them.
You can write example programs, tutorials, or blog posts; improve the
documentation; [submit bug reports and feature requests][bugtracker];
triage existing bug reports; vote on issues with a thumbs-up or
thumbs-down; or write code which is incorporated into [GJS itself][gjs].
### What kinds of contributions we are not looking for ###
Please don't use the [issue tracker][bugtracker] for support questions.
Instead, check out the [#javascript][irc] IRC channel on irc.gnome.org.
You can also try the [javascript-list][mailinglist] mailing list, or
Stack Overflow.
If you are writing code, please do not submit merge requests that only
fix linter errors in code that you are not otherwise changing (unless
you have discussed it in advance with a maintainer on [IRC][irc].)
When writing code or submitting a feature request, make sure to first
read the section below titled "Roadmap".
Contributions that run opposite to the roadmap are not likely to be
accepted.
## Ground Rules ##
Your responsibilities as a contributor:
- Be welcoming and encouraging to newcomers.
- Conduct yourself professionally; rude, abusive, harrassing, or
discriminatory behaviour is not tolerated.
- For any major changes and enhancements you want to make, first create
an issue in the [bugtracker], discuss things transparently, and get
community feedback.
- Ensure all jobs are green on GitLab CI for your merge requests.
- Your code must pass the tests.
- Your code must pass the linters; code should not introduce any new
linting errors.
- Your code should not cause any compiler warnings.
- Add tests for any new functionality you write, and regression tests
for any bugs you fix.
## Your First Contribution ##
Unsure where to start?
Try looking through the [issues labeled "Newcomers"][newcomers].
We try to have these issues contain some step-by-step explanation on how
a newcomer might approach them.
If that explanation is missing from an issue marked "Newcomers", feel
free to leave a comment on there asking for help on how to get started.
[Issues marked "Help Wanted"][helpwanted] may be a bit more involved
than the Newcomers issues, but many of them still do not require
in-depth familiarity with GJS.
## How to contribute documentation or tutorials ##
If you don't have an account on [gitlab.gnome.org], first create one.
Some contributions are done in different places than the main GJS
repository.
To contribute to the documentation, go to the [DevDocs][devdocs]
repository.
To contribute to tutorials, go to [GJS Guide][gjsguide].
Next, read the [workflow guide to contributing to GNOME][workflow].
(In short, create a fork of the repository, make your changes on a
branch, push them to your fork, and create a merge request.)
If your contribution fixes an existing issue, please refer to the issue
in your commit message with `Closes #123` (for issue 123).
Otherwise, creating a separate issue is not required.
See the section on "Commit messages" below.
When you submit your merge request, make sure to click "Allow commits
from contributors with push access".
This is so that the maintainers can re-run the GitLab CI jobs, since
there is currently a bug in the infrastructure that makes some of the
jobs fail unnecessarily.
!157 is an example of a small documentation bugfix in a merge request.
That's all!
## How to contribute code ##
To contribute code, follow the instructions above for contributing
documentation.
There are further instructions for how to set up a development
environment and install the correct tools for GJS development in the
[Hacking.md][hacking] file.
## How to report a bug ##
If you don't have an account on [gitlab.gnome.org], first create one.
Go to the [issue tracker][bugtracker] and click "New issue".
Use the "bug" template when reporting a bug.
Make sure to answer the questions in the template, as otherwise it might
make your bug harder to track down.
_If you find a security vulnerability,_ make sure to mark the issue as
"confidential"!
If in doubt, ask on [IRC][irc] whether you should report a bug about
something, but generally it's OK to just go ahead.
Bug report #170 is a good example of a bug report with an independently
runnable code snippet for testing, and lots of information, although it
was written before the templates existed.
## How to suggest a feature or enhancement ##
If you find yourself wishing for a feature that doesn't exist in GJS,
you are probably not alone.
Open an issue on our [issue tracker][bugtracker] which describes the
feature you would like to see, why you need it, and how it should work.
Use the "feature" template for this.
However, for a new feature, the likelihood that it will be implemented
goes way up if you or someone else plans to submit a merge request along
with it.
If the feature is small enough that you won't feel like your time was
wasted if we decide not to adopt it, you can just submit a merge
request rather than going to the issue tracker.
Make sure to explain why you think it's a good feature to have!
!213 is an example of a small feature suggestion that was submitted as a
merge request.
In cases where you've seen something that needs to be fixed or
refactored in the code, it's OK not to use a template.
It's OK to be less rigorous here, since this type of report is usually
used by people who plan to fix the issue themselves later.
## How to triage bugs ##
You can help the maintainers by examining the existing bug reports in
the bugtracker and adding instructions to reproduce them, or
categorizing them with the correct labels.
For bugs that cause a crash (segmentation fault, not just a JS
exception) use the "1. Crash" label.
For other bugs, use the "1. Bug" label.
Feature requests should get the "1. Feature" label.
Any crashes, or bugs that prevent most or all users from using GJS or
GNOME Shell, should also get the "To Do" label.
If some information is missing from the bug (for example, you can't
reproduce it based on their instructions,) add the "2. Needs
information" label.
Add any topic labels from the "5" group (e.g. "5. Performance") as you
see fit.
As for reproducer instructions, a small, self-contained JS program that
exhibits the bug, to be run with the command-line `gjs` interpreter, is
best.
Instructions that provide code to be loaded as a GNOME Shell extension
are less helpful, because they are more tedious to test.
## Code review process ##
Once you have submitted your merge request, a maintainer will review it.
You should get a first response within a few days.
Sometimes maintainers are busy; if it's been a week and you've heard
nothing, feel free to ping the maintainer and ask for an estimate of
when they might be able to review the merge request.
You might get a review even if some of the GitLab CI jobs have not yet
succeeded.
In that case, acceptance of the merge request is contingent on fixing
whatever needs to be fixed to get all the jobs to turn green.
In general, unless the merge request is very simple, it will not be
ready to accept immediately.
You should normally expect one to three rounds of code review, depending
on the size and complexity of the merge request.
Be prepared to accept constructive criticism on your code and to work on
improving it before it's merged; code review comments don't mean it's
bad.
!242 is an example of a bug fix merge request with a few code review
comments on it, if you want to get a feel for the process.
Contributors with a GNOME developer account have automatic push access
to the main GJS repository.
However, even if you have this access, you are still expected to submit
a merge request and have a GJS maintainer review it.
The exception to this is if there is an emergency such as GNOME
Continuous being broken.
## Community ##
For general questions and support, visit the [#javascript][irc] channel
on irc.gnome.org.
The maintainers are listed in the [DOAP file][doap] in the root of the
repository.
## Roadmap and Philosophy ##
This section explains what kinds of changes we do and don't intend to
make in GJS in the future and what direction we intend to take the
project.
Internally, GJS uses Firefox's Javascript engine, called SpiderMonkey.
First of all, we will not consider switching GJS to use a different
Javascript engine.
If you believe that should be done, the best way to make it happen is to
start a new project, copy GJS's regression test suite, and make sure all
the tests pass and you can run GNOME Shell with it.
Every year when a new ESR (extended support release) of Firefox appears,
we try to upgrade GJS to use the accompanying version of SpiderMonkey
as soon as possible.
Sometimes upgrading SpiderMonkey requires breaking backwards
compatibility, and in that case we try to make it as easy as possible
for existing code to adapt.
Other than the above exception, we avoid all changes that break existing
code, even if they would be convenient.
However, it is OK to break compatibility with GJS's documented behaviour
if in practice the behaviour never actually worked as documented.
(That happens more often than you might think.)
We also try to avoid surprises for people who are used to modern ES
standard Javascript, so custom GJS classes should not deviate from the
behaviour that people would be used to in the standard.
The Node.js ecosystem is quite popular and many Javascript developers
are accustomed to it.
In theory, we would like to move in the direction of providing all the
same facilities as Node.js, but we do not necessarily want to copy the
exact way things work in Node.js.
The platforms are different and so the implementations sometimes need to
be different too.
The module system in GJS should be considered legacy.
We don't want to make big changes to it or add any features.
Instead, we want to enable ES6-style imports for the GJS platform.
We do have some overrides for GNOME libraries such as GLib, to make
their APIs more Javascript-like.
However, we like to keep these to a minimum, so that GNOME code remains
straightforward to read if you are used to using the GNOME libraries in
other programming languages.
GJS was originally written in C, and the current state of the C++ code
reflects that.
Gradually, we want to move the code to a more idiomatic C++ style, using
smart pointer classes such as `GjsAutoChar` to help avoid memory leaks.
Even farther in the future, we expect the Rust bindings for SpiderMonkey
to mature as Mozilla's Servo browser engine progresses, and we may
consider rewriting part or all of GJS in Rust.
We believe in automating as much as possible to prevent human error.
GJS is a complex program that powers a lot of GNOME, so breakages can be
have far-reaching effects in other programs.
We intend to move in the direction of having more static code checking
in the future.
We would also like to have more automated integration testing, for
example trying to start a GNOME Shell session with each new change in
GJS.
Lastly, changes should in principle be compatible with other platforms
than only Linux and GNOME.
Although we don't have automated testing for other platforms, we will
occasionally build and test things there, and gladly accept
contributions to fix breakages on other platforms.
## Conventions ##
### Coding style ###
We use the [Google style guide][googlestyle] for C++ code, with a few
exceptions, 4-space indents being the main one.
There is a handy git commit hook that will autoformat your code when you
commit it; see the [Hacking.md][hacking] file.
For C++ coding style concerns that can't be checked with a linter or an
autoformatter, read the [CPP_Style_Guide.md][cppstyle] file.
For Javascript code, an [ESLint configuration file][eslint] is included
in the root of the GJS repository.
This is not integrated with a git commit hook, so you need to manually
manually sure that all your new code conforms to the style.
Don't rewrite old code with `eslint --fix` unless you are already
changing that code for some other reason.
### Commit messages ###
The title of the commit should say what you changed, and the body of the
commit message should explain why you changed it.
We look in the commit history quite often to figure out why code was
written a certain way, so it's important to justify each change so that
in the future people will realize why it was needed.
For further guidelines about line length and commit messages, read
[this guide][commitmessages].
If the commit is related to an open issue in the issue tracker, note
that on the last line of the commit message. For example, `See #153`, or
`Closes #277` if the issue should be automatically closed when the merge
request is accepted.
## Thanks ##
Thanks to [@nayafia][contributingtemplate] for the inspiration to write
this guide!
[gitlab.gnome.org]: https://gitlab.gnome.org
[bugtracker]: https://gitlab.gnome.org/GNOME/gjs/issues
[gjs]: https://gitlab.gnome.org/GNOME/gjs
[irc]: https://riot.im/app/#/room/#_gimpnet_#javascript:matrix.org
[mailinglist]: https://mail.gnome.org/mailman/listinfo/javascript-list
[newcomers]: https://gitlab.gnome.org/GNOME/gjs/issues?label_name%5B%5D=4.+Newcomers
[helpwanted]: https://gitlab.gnome.org/GNOME/gjs/issues?label_name%5B%5D=4.+Help+Wanted
[devdocs]: https://github.com/ptomato/devdocs
[gjsguide]: https://gitlab.gnome.org/rockon999/gjs-guide
[workflow]: https://wiki.gnome.org/GitLab#Using_a_fork_-_Non_GNOME_developer
[hacking]: https://gitlab.gnome.org/GNOME/gjs/blob/master/doc/Hacking.md
[doap]: https://gitlab.gnome.org/GNOME/gjs/blob/master/gjs.doap
[googlestyle]: https://google.github.io/styleguide/cppguide.html
[cppstyle]: https://gitlab.gnome.org/GNOME/gjs/blob/master/doc/CPP_Style_Guide.md
[eslint]: https://eslint.org/
[commitmessages]: https://chris.beams.io/posts/git-commit/
[contributingtemplate]: https://github.com/nayafia/contributing-template
# This is the toplevel CPPLINT.cfg file
set noparent
# We give a limit to clang-format of 80, but we allow 100 here for cases where
# it really is more readable to have a longer line
linelength=100
Installation Instructions
*************************
Copyright (C) 1994-1996, 1999-2002, 2004-2016 Free Software
Foundation, Inc.
Copying and distribution of this file, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved. This file is offered as-is,
without warranty of any kind.
Basic Installation
==================
Briefly, the shell command './configure && make && make install'
should configure, build, and install this package. The following
more-detailed instructions are generic; see the 'README' file for
instructions specific to this package. Some packages provide this
'INSTALL' file but do not implement all of the features documented
below. The lack of an optional feature in a given package is not
necessarily a bug. More recommendations for GNU packages can be found
in *note Makefile Conventions: (standards)Makefile Conventions.
The 'configure' shell script attempts to guess correct values for
various system-dependent variables used during compilation. It uses
those values to create a 'Makefile' in each directory of the package.
It may also create one or more '.h' files containing system-dependent
definitions. Finally, it creates a shell script 'config.status' that
you can run in the future to recreate the current configuration, and a
file 'config.log' containing compiler output (useful mainly for
debugging 'configure').
It can also use an optional file (typically called 'config.cache' and
enabled with '--cache-file=config.cache' or simply '-C') that saves the
results of its tests to speed up reconfiguring. Caching is disabled by
default to prevent problems with accidental use of stale cache files.
If you need to do unusual things to compile the package, please try
to figure out how 'configure' could check whether to do them, and mail
diffs or instructions to the address given in the 'README' so they can
be considered for the next release. If you are using the cache, and at
some point 'config.cache' contains results you don't want to keep, you
may remove or edit it.
The file 'configure.ac' (or 'configure.in') is used to create
'configure' by a program called 'autoconf'. You need 'configure.ac' if
you want to change it or regenerate 'configure' using a newer version of
'autoconf'.
The simplest way to compile this package is:
1. 'cd' to the directory containing the package's source code and type
'./configure' to configure the package for your system.
Running 'configure' might take a while. While running, it prints
some messages telling which features it is checking for.
2. Type 'make' to compile the package.
3. Optionally, type 'make check' to run any self-tests that come with
the package, generally using the just-built uninstalled binaries.
4. Type 'make install' to install the programs and any data files and
documentation. When installing into a prefix owned by root, it is
recommended that the package be configured and built as a regular
user, and only the 'make install' phase executed with root
privileges.
5. Optionally, type 'make installcheck' to repeat any self-tests, but
this time using the binaries in their final installed location.
This target does not install anything. Running this target as a
regular user, particularly if the prior 'make install' required
root privileges, verifies that the installation completed
correctly.
6. You can remove the program binaries and object files from the
source code directory by typing 'make clean'. To also remove the
files that 'configure' created (so you can compile the package for
a different kind of computer), type 'make distclean'. There is
also a 'make maintainer-clean' target, but that is intended mainly
for the package's developers. If you use it, you may have to get
all sorts of other programs in order to regenerate files that came
with the distribution.
7. Often, you can also type 'make uninstall' to remove the installed
files again. In practice, not all packages have tested that
uninstallation works correctly, even though it is required by the
GNU Coding Standards.
8. Some packages, particularly those that use Automake, provide 'make
distcheck', which can by used by developers to test that all other
targets like 'make install' and 'make uninstall' work correctly.
This target is generally not run by end users.
Compilers and Options
=====================
Some systems require unusual options for compilation or linking that
the 'configure' script does not know about. Run './configure --help'
for details on some of the pertinent environment variables.
You can give 'configure' initial values for configuration parameters
by setting variables in the command line or in the environment. Here is
an example:
./configure CC=c99 CFLAGS=-g LIBS=-lposix
*Note Defining Variables::, for more details.
Compiling For Multiple Architectures
====================================
You can compile the package for more than one kind of computer at the
same time, by placing the object files for each architecture in their
own directory. To do this, you can use GNU 'make'. 'cd' to the
directory where you want the object files and executables to go and run
the 'configure' script. 'configure' automatically checks for the source
code in the directory that 'configure' is in and in '..'. This is known
as a "VPATH" build.
With a non-GNU 'make', it is safer to compile the package for one
architecture at a time in the source code directory. After you have
installed the package for one architecture, use 'make distclean' before
reconfiguring for another architecture.
On MacOS X 10.5 and later systems, you can create libraries and
executables that work on multiple system types--known as "fat" or
"universal" binaries--by specifying multiple '-arch' options to the
compiler but only a single '-arch' option to the preprocessor. Like
this:
./configure CC="gcc -arch i386 -arch x86_64 -arch ppc -arch ppc64" \
CXX="g++ -arch i386 -arch x86_64 -arch ppc -arch ppc64" \
CPP="gcc -E" CXXCPP="g++ -E"
This is not guaranteed to produce working output in all cases, you
may have to build one architecture at a time and combine the results
using the 'lipo' tool if you have problems.
Installation Names
==================
By default, 'make install' installs the package's commands under
'/usr/local/bin', include files under '/usr/local/include', etc. You
can specify an installation prefix other than '/usr/local' by giving
'configure' the option '--prefix=PREFIX', where PREFIX must be an
absolute file name.
You can specify separate installation prefixes for
architecture-specific files and architecture-independent files. If you
pass the option '--exec-prefix=PREFIX' to 'configure', the package uses
PREFIX as the prefix for installing programs and libraries.
Documentation and other data files still use the regular prefix.
In addition, if you use an unusual directory layout you can give
options like '--bindir=DIR' to specify different values for particular
kinds of files. Run 'configure --help' for a list of the directories
you can set and what kinds of files go in them. In general, the default
for these options is expressed in terms of '${prefix}', so that
specifying just '--prefix' will affect all of the other directory
specifications that were not explicitly provided.
The most portable way to affect installation locations is to pass the
correct locations to 'configure'; however, many packages provide one or
both of the following shortcuts of passing variable assignments to the
'make install' command line to change installation locations without
having to reconfigure or recompile.
The first method involves providing an override variable for each
affected directory. For example, 'make install
prefix=/alternate/directory' will choose an alternate location for all
directory configuration variables that were expressed in terms of
'${prefix}'. Any directories that were specified during 'configure',
but not in terms of '${prefix}', must each be overridden at install time
for the entire installation to be relocated. The approach of makefile
variable overrides for each directory variable is required by the GNU
Coding Standards, and ideally causes no recompilation. However, some
platforms have known limitations with the semantics of shared libraries
that end up requiring recompilation when using this method, particularly
noticeable in packages that use GNU Libtool.
The second method involves providing the 'DESTDIR' variable. For
example, 'make install DESTDIR=/alternate/directory' will prepend
'/alternate/directory' before all installation names. The approach of
'DESTDIR' overrides is not required by the GNU Coding Standards, and
does not work on platforms that have drive letters. On the other hand,
it does better at avoiding recompilation issues, and works well even
when some directory options were not specified in terms of '${prefix}'
at 'configure' time.
Optional Features
=================
If the package supports it, you can cause programs to be installed
with an extra prefix or suffix on their names by giving 'configure' the
option '--program-prefix=PREFIX' or '--program-suffix=SUFFIX'.
Some packages pay attention to '--enable-FEATURE' options to
'configure', where FEATURE indicates an optional part of the package.
They may also pay attention to '--with-PACKAGE' options, where PACKAGE
is something like 'gnu-as' or 'x' (for the X Window System). The
'README' should mention any '--enable-' and '--with-' options that the
package recognizes.
For packages that use the X Window System, 'configure' can usually
find the X include and library files automatically, but if it doesn't,
you can use the 'configure' options '--x-includes=DIR' and
'--x-libraries=DIR' to specify their locations.
Some packages offer the ability to configure how verbose the
execution of 'make' will be. For these packages, running './configure
--enable-silent-rules' sets the default to minimal output, which can be
overridden with 'make V=1'; while running './configure
--disable-silent-rules' sets the default to verbose, which can be
overridden with 'make V=0'.
Particular systems
==================
On HP-UX, the default C compiler is not ANSI C compatible. If GNU CC
is not installed, it is recommended to use the following options in
order to use an ANSI C compiler:
./configure CC="cc -Ae -D_XOPEN_SOURCE=500"
and if that doesn't work, install pre-built binaries of GCC for HP-UX.
HP-UX 'make' updates targets which have the same time stamps as their
prerequisites, which makes it generally unusable when shipp