GitLab CI DIND: timeout error

Expected Behavior
docker-slim should run without error when run in a GitLab CI environment

Actual Behavior
docker-slim fails with timeout error.

Steps to Reproduce the Problem

Create a GitLab CI project with a Dockerfile in it and the following .gitlab-ci.yml file:

---
gitlab_registry:
  stage: test
  image: megabytelabs/dockerslim:latest
  needs: []
  services:
    - docker:dind
  tags:
    - docker
  variables:
    DOCKER_HOST: tcp://docker:2376
    DOCKER_TLS_CERTDIR: /certs
    DOCKER_CERT_PATH: "$DOCKER_TLS_CERTDIR/client"
    DOCKER_TLS_VERIFY: 1
    GIT_DEPTH: 1
  script:
    - docker login -u "${CI_REGISTRY_USER}" -p "${CI_REGISTRY_PASSWORD}" "${CI_REGISTRY}"
    - docker build -t "${CI_COMMIT_REF_SLUG}:latest" .
    - docker-slim --debug --tls-verify=false build --http-probe=false --exec 'echo hey' "${CI_COMMIT_REF_SLUG}:latest"

Trigger the CI build. Docker commands are working as expected but the docker-slim build fails with the following output:

Running with gitlab-runner 13.12.0-rc1 (b21d5c5b)
  on docker-auto-scale 0277ea0f
  feature flags: FF_GITLAB_REGISTRY_HELPER_IMAGE:true, FF_SKIP_DOCKER_MACHINE_PROVISION_ON_CREATION_FAILURE:true
Resolving secrets
00:00
Preparing the "docker+machine" executor
Using Docker executor with image megabytelabs/dockerslim:latest ...
Starting service docker:dind ...
Pulling docker image docker:dind ...
Using docker image sha256:dc8c389414c80f3c6510d3690cd03c29fc99d66f58955f138248499a34186bfa for docker:dind with digest docker@sha256:87ed8e3a7b251eef42c2e4251f95ae3c5f8c4c0a64900f19cc532d0a42aa7107 ...
Waiting for services to be up and running...
Pulling docker image megabytelabs/dockerslim:latest ...
Using docker image sha256:383b8ff911c08e8a29b6cc8a75d8069fec480f71d9c773ed3f96a4a8486b46ec for megabytelabs/dockerslim:latest with digest megabytelabs/dockerslim@sha256:c21249ab64d840452d81e796952341649ed8774665b1285ae92a4f47998c0022 ...
Preparing environment
00:00
Running on runner-0277ea0f-project-25813727-concurrent-0 via runner-0277ea0f-srm-1621013830-ed04e4e1...
Getting source from Git repository
00:02
$ eval "$CI_PRE_CLONE_SCRIPT"
Fetching changes with git depth set to 1...
Initialized empty Git repository in /builds/megabyte-labs/dockerfile/ci-pipeline/yamllint/.git/
Created fresh repository.
Checking out 417f788b as master...
Skipping Git submodules setup
Executing "step_script" stage of the job script
Using docker image sha256:383b8ff911c08e8a29b6cc8a75d8069fec480f71d9c773ed3f96a4a8486b46ec for megabytelabs/dockerslim:latest with digest megabytelabs/dockerslim@sha256:c21249ab64d840452d81e796952341649ed8774665b1285ae92a4f47998c0022 ...
$ docker login -u "${CI_REGISTRY_USER}" -p "${CI_REGISTRY_PASSWORD}" "${CI_REGISTRY}"
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
$ docker build -t "${CI_COMMIT_REF_SLUG}:latest" .
Step 1/20 : FROM alpine:3
3: Pulling from library/alpine
540db60ca938: Pulling fs layer
540db60ca938: Verifying Checksum
540db60ca938: Download complete
540db60ca938: Pull complete
Digest: sha256:69e70a79f2d41ab5d637de98c1e0b055206ba40a8145e7bddb55ccc04e13cf8f
Status: Downloaded newer image for alpine:3
 ---> 6dbb9cc54074
Step 2/20 : ENV container docker
 ---> Running in 5633d9ac9aab
Removing intermediate container 5633d9ac9aab
 ---> b177e9721c4f
Step 3/20 : RUN apk --no-cache add --virtual build-dependencies       py3-pip=20.3.4-r0   && apk --no-cache add       python3=3.8.10-r0   && pip3 install --no-cache-dir       yamllint==1.26.1   && apk del build-dependencies   && rm -Rf /var/cache/apk/*
 ---> Running in 35b9887db817
fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/community/x86_64/APKINDEX.tar.gz
(1/36) Installing libbz2 (1.0.8-r1)
(2/36) Installing expat (2.2.10-r1)
(3/36) Installing libffi (3.3-r2)
(4/36) Installing gdbm (1.19-r0)
(5/36) Installing xz-libs (5.2.5-r0)
(6/36) Installing ncurses-terminfo-base (6.2_p20210109-r0)
(7/36) Installing ncurses-libs (6.2_p20210109-r0)
(8/36) Installing readline (8.1.0-r0)
(9/36) Installing sqlite-libs (3.34.1-r0)
(10/36) Installing python3 (3.8.10-r0)
(11/36) Installing py3-appdirs (1.4.4-r1)
(12/36) Installing py3-ordered-set (4.0.2-r0)
(13/36) Installing py3-parsing (2.4.7-r1)
(14/36) Installing py3-six (1.15.0-r0)
(15/36) Installing py3-packaging (20.9-r0)
(16/36) Installing py3-setuptools (51.3.3-r0)
(17/36) Installing py3-chardet (4.0.0-r0)
(18/36) Installing py3-idna (3.1-r0)
(19/36) Installing py3-urllib3 (1.26.2-r1)
(20/36) Installing py3-requests (2.25.1-r1)
(21/36) Installing py3-msgpack (1.0.2-r0)
(22/36) Installing py3-lockfile (0.12.2-r3)
(23/36) Installing py3-cachecontrol (0.12.6-r0)
(24/36) Installing py3-colorama (0.4.4-r0)
(25/36) Installing py3-contextlib2 (0.6.0-r0)
(26/36) Installing py3-distlib (0.3.1-r1)
(27/36) Installing py3-distro (1.5.0-r1)
(28/36) Installing py3-webencodings (0.5.1-r3)
(29/36) Installing py3-html5lib (1.1-r0)
(30/36) Installing py3-pytoml (0.1.21-r0)
(31/36) Installing py3-pep517 (0.9.1-r0)
(32/36) Installing py3-progress (1.5-r0)
(33/36) Installing py3-retrying (1.3.3-r0)
(34/36) Installing py3-toml (0.10.2-r0)
(35/36) Installing py3-pip (20.3.4-r0)
(36/36) Installing build-dependencies (20210514.173827)
Executing busybox-1.32.1-r6.trigger
OK: 75 MiB in 50 packages
fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/community/x86_64/APKINDEX.tar.gz
OK: 75 MiB in 50 packages
Collecting yamllint==1.26.1
  Downloading yamllint-1.26.1.tar.gz (126 kB)
Collecting pathspec>=0.5.3
  Downloading pathspec-0.8.1-py2.py3-none-any.whl (28 kB)
Collecting pyyaml
  Downloading PyYAML-5.4.1.tar.gz (175 kB)
  Installing build dependencies: started
  Installing build dependencies: finished with status 'done'
  Getting requirements to build wheel: started
  Getting requirements to build wheel: finished with status 'done'
    Preparing wheel metadata: started
    Preparing wheel metadata: finished with status 'done'
Using legacy 'setup.py install' for yamllint, since package 'wheel' is not installed.
Building wheels for collected packages: pyyaml
  Building wheel for pyyaml (PEP 517): started
  Building wheel for pyyaml (PEP 517): finished with status 'done'
  Created wheel for pyyaml: filename=PyYAML-5.4.1-cp38-cp38-linux_x86_64.whl size=45641 sha256=877f5c66f7f4841b24843d0d0f0fb94e7de2f892a282030f82208f393289c172
  Stored in directory: /tmp/pip-ephem-wheel-cache-63w9bcle/wheels/dd/c5/1d/5d7436173d3efd4a14dcb510eb0b29525ecb6b0e41489e716e
Successfully built pyyaml
Installing collected packages: pyyaml, pathspec, yamllint
    Running setup.py install for yamllint: started
    Running setup.py install for yamllint: finished with status 'done'
Successfully installed pathspec-0.8.1 pyyaml-5.4.1 yamllint-1.26.1
WARNING: Ignoring https://dl-cdn.alpinelinux.org/alpine/v3.13/main: No such file or directory
WARNING: Ignoring https://dl-cdn.alpinelinux.org/alpine/v3.13/community: No such file or directory
(1/26) Purging build-dependencies (20210514.173827)
(2/26) Purging py3-pip (20.3.4-r0)
(3/26) Purging py3-cachecontrol (0.12.6-r0)
(4/26) Purging py3-lockfile (0.12.2-r3)
(5/26) Purging py3-colorama (0.4.4-r0)
(6/26) Purging py3-contextlib2 (0.6.0-r0)
(7/26) Purging py3-distlib (0.3.1-r1)
(8/26) Purging py3-distro (1.5.0-r1)
(9/26) Purging py3-html5lib (1.1-r0)
(10/26) Purging py3-msgpack (1.0.2-r0)
(11/26) Purging py3-pep517 (0.9.1-r0)
(12/26) Purging py3-pytoml (0.1.21-r0)
(13/26) Purging py3-progress (1.5-r0)
(14/26) Purging py3-requests (2.25.1-r1)
(15/26) Purging py3-chardet (4.0.0-r0)
(16/26) Purging py3-idna (3.1-r0)
(17/26) Purging py3-urllib3 (1.26.2-r1)
(18/26) Purging py3-retrying (1.3.3-r0)
(19/26) Purging py3-setuptools (51.3.3-r0)
(20/26) Purging py3-ordered-set (4.0.2-r0)
(21/26) Purging py3-appdirs (1.4.4-r1)
(22/26) Purging py3-packaging (20.9-r0)
(23/26) Purging py3-parsing (2.4.7-r1)
(24/26) Purging py3-six (1.15.0-r0)
(25/26) Purging py3-toml (0.10.2-r0)
(26/26) Purging py3-webencodings (0.5.1-r3)
Executing busybox-1.32.1-r6.trigger
OK: 53 MiB in 24 packages
Removing intermediate container 35b9887db817
 ---> 42fbfd532903
Step 4/20 : WORKDIR /work
 ---> Running in 6021fb838d36
Removing intermediate container 6021fb838d36
 ---> e577bd51ef96
Step 5/20 : CMD ["yamllint", "--version"]
 ---> Running in 5fd4acde5fcb
Removing intermediate container 5fd4acde5fcb
 ---> 707a4e31146c
Step 6/20 : ARG BUILD_DATE
 ---> Running in 2d05149992d0
Removing intermediate container 2d05149992d0
 ---> 3dc1350b9cc6
Step 7/20 : ARG REVISION
 ---> Running in a1378959cdc8
Removing intermediate container a1378959cdc8
 ---> 157cff7ac860
Step 8/20 : ARG VERSION
 ---> Running in 91cfaa6c36f0
Removing intermediate container 91cfaa6c36f0
 ---> c82f2a79a67f
Step 9/20 : LABEL maintainer="Megabyte Labs<EMAIL_ADDRESS> ---> Running in 6b299b749337
Removing intermediate container 6b299b749337
 ---> a23b0e61c651
Step 10/20 : LABEL org.opencontainers.image.authors="Brian Zalewski<EMAIL_ADDRESS> ---> Running in aaa702f8739b
Removing intermediate container aaa702f8739b
 ---> 179294040d60
Step 11/20 : LABEL org.opencontainers.image.created=$BUILD_DATE
 ---> Running in 28cf86ff3b43
Removing intermediate container 28cf86ff3b43
 ---> d57eb219f866
Step 12/20 : LABEL org.opencontainers.image.description="An incredibly compact YAML Lint container that you can use in CI environments as well as from the command-line as a one-liner (only 3.21997 MB compressed!)"
 ---> Running in dd58c6e68c5b
Removing intermediate container dd58c6e68c5b
 ---> 70241d26333c
Step 13/20 : LABEL org.opencontainers.image.documentation="https://gitlab.com/megabyte-labs/dockerfile/ci-pipeline/yamllint/-/blob/master/README.md"
 ---> Running in 942a0b796677
Removing intermediate container 942a0b796677
 ---> 8b58f5ca076e
Step 14/20 : LABEL org.opencontainers.image.licenses="MIT"
 ---> Running in f4720da47785
Removing intermediate container f4720da47785
 ---> 8badffc09f5e
Step 15/20 : LABEL org.opencontainers.image.revision=$REVISION
 ---> Running in 21e020722a88
Removing intermediate container 21e020722a88
 ---> 6ee378250f76
Step 16/20 : LABEL org.opencontainers.image.source="https://gitlab.com/megabyte-labs/dockerfile/ci-pipeline/yamllint.git"
 ---> Running in 3a86e3acfb62
Removing intermediate container 3a86e3acfb62
 ---> 36ee118325a8
Step 17/20 : LABEL org.opencontainers.image.url="https://megabyte.space"
 ---> Running in 6902612d6ea8
Removing intermediate container 6902612d6ea8
 ---> 7856ce7d7760
Step 18/20 : LABEL org.opencontainers.image.vendor="Megabyte Labs"
 ---> Running in 4692e2e96213
Removing intermediate container 4692e2e96213
 ---> 65c98cefaf27
Step 19/20 : LABEL org.opencontainers.image.version=$VERSION
 ---> Running in 6395eaaa7b24
Removing intermediate container 6395eaaa7b24
 ---> 009f738fe80e
Step 20/20 : LABEL space.megabyte.type="ci-pipeline"
 ---> Running in 557e14a54a04
Removing intermediate container 557e14a54a04
 ---> 6db846ce739a
Successfully built 6db846ce739a
Successfully tagged master:latest
$ docker-slim --debug --tls-verify=false build --http-probe=false --exec 'yamllint .' "${CI_COMMIT_REF_SLUG}:latest"
time="2021-05-14T17:38:44Z" level=debug msg="sysinfo => system.SystemInfo{Sysname:\"Linux\", Nodename:\"runner-0277ea0f-project-25813727-concurrent-0\", Release:\"4.19.78-coreos\", Version:\"#1 SMP Mon Oct 14 22:56:39 -00 2019\", Machine:\"x86_64\", Domainname:\"(none)\", OsBuild:\"\", Distro:system.DistroInfo{Name:\"Alpine Linux\", Version:\"3.13.5\", DisplayName:\"Alpine Linux v3.13\"}}"
docker-slim: message='join the Gitter channel to ask questions or to share your feedback' info='https://gitter.im/docker-slim/community'
docker-slim: message='join the Discord server to ask questions or to share your feedback' info='https://discord.gg/9tDyxYS'
docker-slim: message='Github discussions' info='https://github.com/docker-slim/docker-slim/discussions'
cmd=build info=exec message='changing continue-after mode to exec'
time="2021-05-14T17:38:44Z" level=debug msg="docker-slim: new Docker client (TLS,no verify) [4]"
cmd=build state=started
cmd=build info=params target='master:latest' continue.mode='exec' rt.as.user='true' keep.perms='true'
time="2021-05-14T17:38:44Z" level=info msg="image=master:latest http-probe=false remove-file-artifacts=false image-overrides=map[] entrypoint=[] (false) cmd=[] (false) workdir='' env=[] expose=map[]" app=docker-slim command=build
cmd=build info=app version='linux|Transformer|1.35.1|89ddd87f009dd1e7cbd66a5494e5956c3c093edc|2021-04-27_07:10:07PM' container=true dsimage=false
cmd=build info=app location='/usr/local/bin'
cmd=build info=host osname='Alpine Linux v3.13'
cmd=build info=host osbuild=
cmd=build info=host version='#1 SMP Mon Oct 14 22:56:39 -00 2019'
cmd=build info=host release=4.19.78-coreos
cmd=build info=host sysname=Linux
cmd=build info=docker name=32fd90fcb8bb
cmd=build info=docker kernel_version=4.19.78-coreos
cmd=build info=docker operating_system=Alpine Linux v3.13 (containerized)
cmd=build info=docker ostype=linux
cmd=build info=docker server_version=20.10.6
cmd=build info=docker architecture=x86_64
cmd=build info=dclient api_version=1.41
cmd=build info=dclient min_api_version=1.12
cmd=build info=dclient build_time=2021-04-09T22:46:14.000000000+00:00
cmd=build info=dclient git_commit=8728dd2
cmd=build state=image.inspection.start
time="2021-05-14T17:38:44Z" level=info msg="inspecting 'fat' image metadata..." app=docker-slim command=build
time="2021-05-14T17:38:44Z" level=debug msg="PrepareImageStateDirs(,sha256:6db846ce739a8656ce1ae8a922d7de63663fd01740cdf5864b78b08a32257530)"
time="2021-05-14T17:38:44Z" level=debug msg="PrepareImageStateDirs - statePrefix=/usr/local/bin appDir=/usr/local/bin badPath=/usr/local/bin"
time="2021-05-14T17:38:44Z" level=debug msg="PrepareImageStateDirs - overriding state path to /tmp/docker-slim-state"
time="2021-05-14T17:38:44Z" level=debug msg="PrepareImageStateDirs - statePrefix=/tmp/docker-slim-state appDir=/usr/local/bin badPath=/usr/local/bin"
time="2021-05-14T17:38:44Z" level=debug msg="PrepareImageStateDirs - copying sensor to state path (to /tmp/docker-slim-state)"
time="2021-05-14T17:38:44Z" level=debug msg="CopyRegularFile(false,/usr/local/bin/docker-slim-sensor,/tmp/docker-slim-state/docker-slim-sensor,true)"
time="2021-05-14T17:38:44Z" level=debug msg="PrepareImageStateDirs - will create new state location: /tmp/docker-slim-state/.docker-slim-state/images/6db846ce739a8656ce1ae8a922d7de63663fd01740cdf5864b78b08a32257530/artifacts"
time="2021-05-14T17:38:44Z" level=debug msg="PrepareImageStateDirs - created new image state location: /tmp/docker-slim-state/.docker-slim-state/images/6db846ce739a8656ce1ae8a922d7de63663fd01740cdf5864b78b08a32257530/artifacts"
time="2021-05-14T17:38:44Z" level=debug msg="localVolumePath=/tmp/docker-slim-state/.docker-slim-state/images/6db846ce739a8656ce1ae8a922d7de63663fd01740cdf5864b78b08a32257530, artifactLocation=/tmp/docker-slim-state/.docker-slim-state/images/6db846ce739a8656ce1ae8a922d7de63663fd01740cdf5864b78b08a32257530/artifacts, statePath=/tmp/docker-slim-state, stateKey=6db846ce739a8656ce1ae8a922d7de63663fd01740cdf5864b78b08a32257530" app=docker-slim command=build
cmd=build info=image size.human='52 MB' id='sha256:6db846ce739a8656ce1ae8a922d7de63663fd01740cdf5864b78b08a32257530' size.bytes='52089452'
time="2021-05-14T17:38:44Z" level=info msg="processing 'fat' image info..." app=docker-slim command=build
time="2021-05-14T17:38:44Z" level=debug msg="\n\nIMAGE HISTORY =>\n[]docker.ImageHistory{docker.ImageHistory{ID:\"sha256:6db846ce739a8656ce1ae8a922d7de63663fd01740cdf5864b78b08a32257530\", Tags:[]string{\"master:latest\"}, Created:1621013924, CreatedBy:\"/bin/sh -c #(nop)  LABEL space.megabyte.type=ci-pipeline\", Size:0, Comment:\"\"}, docker.ImageHistory{ID:\"sha256:009f738fe80edb4066f1d400b215b89a31049e747bfb9991d63cacd268e750b6\", Tags:[]string(nil), Created:1621013924, CreatedBy:\"/bin/sh -c #(nop)  LABEL org.opencontainers.image.version=\", Size:0, Comment:\"\"}, docker.ImageHistory{ID:\"sha256:65c98cefaf2782b17c566b065db0b7f105443bda51c466a3b00489c195207745\", Tags:[]string(nil), Created:1621013924, CreatedBy:\"/bin/sh -c #(nop)  LABEL org.opencontainers.image.vendor=Megabyte Labs\", Size:0, Comment:\"\"}, docker.ImageHistory{ID:\"sha256:7856ce7d776034950aa6a000faf9a820e52688c48c48ea23fc11aa9da3cc0624\", Tags:[]string(nil), Created:1621013923, CreatedBy:\"/bin/sh -c #(nop)  LABEL org.opencontainers.image.url=https://megabyte.space\", Size:0, Comment:\"\"}, docker.ImageHistory{ID:\"sha256:36ee118325a8d7b8ab8c95df5f44fb043b2eae1673521c799dfd89cf1b9db392\", Tags:[]string(nil), Created:1621013923, CreatedBy:\"/bin/sh -c #(nop)  LABEL org.opencontainers.image.source=https://gitlab.com/megabyte-labs/dockerfile/ci-pipeline/yamllint.git\", Size:0, Comment:\"\"}, docker.ImageHistory{ID:\"sha256:6ee378250f76a3595fb2fae2d9ddbc9386a1fad4708c8204dbe96058c6cd9c5e\", Tags:[]string(nil), Created:1621013923, CreatedBy:\"/bin/sh -c #(nop)  LABEL org.opencontainers.image.revision=\", Size:0, Comment:\"\"}, docker.ImageHistory{ID:\"sha256:8badffc09f5ec3edf83665febef736697b7b19984500a637623bcb2f2d7075f5\", Tags:[]string(nil), Created:1621013923, CreatedBy:\"/bin/sh -c #(nop)  LABEL org.opencontainers.image.licenses=MIT\", Size:0, Comment:\"\"}, docker.ImageHistory{ID:\"sha256:8b58f5ca076ee77f0b27208126abbb5bb12d81b43f2eec96dc5f6e32e638d5f7\", Tags:[]string(nil), Created:1621013923, CreatedBy:\"/bin/sh -c #(nop)  LABEL org.opencontainers.image.documentation=https://gitlab.com/megabyte-labs/dockerfile/ci-pipeline/yamllint/-/blob/master/README.md\", Size:0, Comment:\"\"}, docker.ImageHistory{ID:\"sha256:70241d26333cc48ef20772aefc7394a458c22d94b6f3e75b25230f4ce2c01d79\", Tags:[]string(nil), Created:1621013923, CreatedBy:\"/bin/sh -c #(nop)  LABEL org.opencontainers.image.description=An incredibly compact YAML Lint container that you can use in CI environments as well as from the command-line as a one-liner (only 3.21997 MB compressed!)\", Size:0, Comment:\"\"}, docker.ImageHistory{ID:\"sha256:d57eb219f866f188bb5724396bf25f1f921706cb342dfe0bcb14f199924f5c67\", Tags:[]string(nil), Created:1621013923, CreatedBy:\"/bin/sh -c #(nop)  LABEL org.opencontainers.image.created=\", Size:0, Comment:\"\"}, docker.ImageHistory{ID:\"sha256:179294040d6010d4a7c09b2169d985a9427407959de4a981a36d6aacd4e248b3\", Tags:[]string(nil), Created:1621013923, CreatedBy:\"/bin/sh -c #(nop)  LABEL org.opencontainers.image.authors=Brian Zalewski<EMAIL_ADDRESS>Size:0, Comment:\"\"}, docker.ImageHistory{ID:\"sha256:a23b0e61c6513695b06cfcd06cf8e7cb8c0810612b701f871bff8adbb75c4c19\", Tags:[]string(nil), Created:1621013923, CreatedBy:\"/bin/sh -c #(nop)  LABEL maintainer=Megabyte Labs<EMAIL_ADDRESS>Size:0, Comment:\"\"}, docker.ImageHistory{ID:\"sha256:c82f2a79a67fca3e57ef5283255ac45cd0769479d2c901e459602048082b26d1\", Tags:[]string(nil), Created:1621013923, CreatedBy:\"/bin/sh -c #(nop)  ARG VERSION\", Size:0, Comment:\"\"}, docker.ImageHistory{ID:\"sha256:157cff7ac8604e75bf2ba52ba3e1e60ded5dd127701a3ada6f5f26b69cf9c5ae\", Tags:[]string(nil), Created:1621013922, CreatedBy:\"/bin/sh -c #(nop)  ARG REVISION\", Size:0, Comment:\"\"}, docker.ImageHistory{ID:\"sha256:3dc1350b9cc6a7621e35229e6773af3868e56f607ae04156d20c33694bbf03a4\", Tags:[]string(nil), Created:1621013922, CreatedBy:\"/bin/sh -c #(nop)  ARG BUILD_DATE\", Size:0, Comment:\"\"}, docker.ImageHistory{ID:\"sha256:707a4e31146cc4f53204c658e7392b97944ff0b9630eaa350f8e3a8eee948b3f\", Tags:[]string(nil), Created:1621013922, CreatedBy:\"/bin/sh -c #(nop)  CMD [\\\"yamllint\\\" \\\"--version\\\"]\", Size:0, Comment:\"\"}, docker.ImageHistory{ID:\"sha256:e577bd51ef96d43ebe3f3e64ce80783810c9c87bc9e3691a418f66d7b6e36982\", Tags:[]string(nil), Created:1621013922, CreatedBy:\"/bin/sh -c #(nop) WORKDIR /work\", Size:0, Comment:\"\"}, docker.ImageHistory{ID:\"sha256:42fbfd532903bf42c288e015eab2d6c505f5b097dc756ffd39994d6f105e35f5\", Tags:[]string(nil), Created:1621013922, CreatedBy:\"/bin/sh -c apk --no-cache add --virtual build-dependencies       py3-pip=20.3.4-r0   && apk --no-cache add       python3=3.8.10-r0   && pip3 install --no-cache-dir       yamllint==1.26.1   && apk del build-dependencies   && rm -Rf /var/cache/apk/*\", Size:46476294, Comment:\"\"}, docker.ImageHistory{ID:\"sha256:b177e9721c4fbe30d8b5b5be2ea7784f47b70a7a82f43ef3b5914804324e311b\", Tags:[]string(nil), Created:1621013906, CreatedBy:\"/bin/sh -c #(nop)  ENV container=docker\", Size:0, Comment:\"\"}, docker.ImageHistory{ID:\"sha256:6dbb9cc54074106d46d4ccb330f2a40a682d49dda5f4844962b7dce9fe44aaec\", Tags:[]string{\"alpine:3\"}, Created:1618427979, CreatedBy:\"/bin/sh -c #(nop)  CMD [\\\"/bin/sh\\\"]\", Size:0, Comment:\"\"}, docker.ImageHistory{ID:\"<missing>\", Tags:[]string(nil), Created:1618427979, CreatedBy:\"/bin/sh -c #(nop) ADD file:8ec69d882e7f29f0652d537557160e638168550f738d0d49f90a7ef96bf31787 in / \", Size:5613158, Comment:\"\"}}\n\n"
time="2021-05-14T17:38:44Z" level=debug msg="IMAGE INSTRUCTIONS:"
time="2021-05-14T17:38:44Z" level=debug msg="FROM scratch"
time="2021-05-14T17:38:44Z" level=debug msg="# new image"
time="2021-05-14T17:38:44Z" level=debug msg="ADD file:8ec69d882e7f29f0652d537557160e638168550f738d0d49f90a7ef96bf31787 /"
time="2021-05-14T17:38:44Z" level=debug msg="CMD [\"/bin/sh\"]"
time="2021-05-14T17:38:44Z" level=debug msg="# end of image: alpine:3 (id:  tags: alpine:3)"
time="2021-05-14T17:38:44Z" level=debug
time="2021-05-14T17:38:44Z" level=debug msg="# new image"
time="2021-05-14T17:38:44Z" level=debug msg="ENV container=docker"
time="2021-05-14T17:38:44Z" level=debug msg="RUN apk --no-cache add --virtual build-dependencies       py3-pip=20.3.4-r0 && \\\n\tapk --no-cache add       python3=3.8.10-r0 && \\\n\tpip3 install --no-cache-dir       yamllint==1.26.1 && \\\n\tapk del build-dependencies && \\\n\trm -Rf /var/cache/apk/*"
time="2021-05-14T17:38:44Z" level=debug msg="WORKDIR /work"
time="2021-05-14T17:38:44Z" level=debug msg="CMD [\"yamllint\",\"--version\"]"
time="2021-05-14T17:38:44Z" level=debug msg="ARG BUILD_DATE"
time="2021-05-14T17:38:44Z" level=debug msg="ARG REVISION"
time="2021-05-14T17:38:44Z" level=debug msg="ARG VERSION"
time="2021-05-14T17:38:44Z" level=debug msg="LABEL maintainer=Megabyte Labs<EMAIL_ADDRESS>time="2021-05-14T17:38:44Z" level=debug msg="LABEL org.opencontainers.image.authors=Brian Zalewski<EMAIL_ADDRESS>time="2021-05-14T17:38:44Z" level=debug msg="LABEL org.opencontainers.image.created="
time="2021-05-14T17:38:44Z" level=debug msg="LABEL org.opencontainers.image.description=An incredibly compact YAML Lint container that you can use in CI environments as well as from the command-line as a one-liner (only 3.21997 MB compressed!)"
time="2021-05-14T17:38:44Z" level=debug msg="LABEL org.opencontainers.image.documentation=https://gitlab.com/megabyte-labs/dockerfile/ci-pipeline/yamllint/-/blob/master/README.md"
time="2021-05-14T17:38:44Z" level=debug msg="LABEL org.opencontainers.image.licenses=MIT"
time="2021-05-14T17:38:44Z" level=debug msg="LABEL org.opencontainers.image.revision="
time="2021-05-14T17:38:44Z" level=debug msg="LABEL org.opencontainers.image.source=https://gitlab.com/megabyte-labs/dockerfile/ci-pipeline/yamllint.git"
time="2021-05-14T17:38:44Z" level=debug msg="LABEL org.opencontainers.image.url=https://megabyte.space"
time="2021-05-14T17:38:44Z" level=debug msg="LABEL org.opencontainers.image.vendor=Megabyte Labs"
time="2021-05-14T17:38:44Z" level=debug msg="LABEL org.opencontainers.image.version="
time="2021-05-14T17:38:44Z" level=debug msg="LABEL space.megabyte.type=ci-pipeline"
time="2021-05-14T17:38:44Z" level=debug msg="# end of image: master:latest (id:  tags: master:latest)"
time="2021-05-14T17:38:44Z" level=debug
cmd=build info=image.stack index='0' name='alpine:3' id='sha256:6dbb9cc54074106d46d4ccb330f2a40a682d49dda5f4844962b7dce9fe44aaec'
cmd=build info=image.stack name='master:latest' id='sha256:6db846ce739a8656ce1ae8a922d7de63663fd01740cdf5864b78b08a32257530' index='1'
cmd=build state=image.inspection.done
cmd=build state=container.inspection.start
time="2021-05-14T17:38:44Z" level=debug msg="FatContainerCmd - [yamllint --version]" app=docker-slim command=build component=container.inspector
time="2021-05-14T17:38:44Z" level=info msg="starting instrumented 'fat' container..." app=docker-slim command=build
time="2021-05-14T17:38:44Z" level=debug msg="RunContainer: sensor (/usr/local/bin/docker-slim-sensor) perms => 0755" app=docker-slim command=build component=container.inspector
time="2021-05-14T17:38:44Z" level=debug msg="dockerutil.HasVolume: volume not found - docker-slim-sensor.1.35.1"
time="2021-05-14T17:38:44Z" level=debug msg="ensureSensorVolume: no volume yet = docker-slim-sensor.1.35.1" app=docker-slim command=build component=container.inspector
time="2021-05-14T17:38:44Z" level=debug msg="version.Check: http status = 200 OK" app=docker-slim
time="2021-05-14T17:38:44Z" level=debug msg="dockerutil.CreateVolumeWithData: volumeInfo = &{Name:docker-slim-sensor.1.35.1 Driver:local Mountpoint:/var/lib/docker/volumes/docker-slim-sensor.1.35.1/_data Labels:map[] Options:map[] CreatedAt:2021-05-14 17:38:44 +0000 UTC}"
time="2021-05-14T17:38:45Z" level=debug msg="dockerutil.CopyToVolume: containerID - 58348dcb61b326cabccadb9e03ba8623bc890843e1241d173f93c59075202438"
time="2021-05-14T17:38:45Z" level=debug msg="RunContainer: default exposed ports => map[docker.Port]struct {}{\"65501/tcp\":struct {}{}, \"65502/tcp\":struct {}{}}" app=docker-slim command=build component=container.inspector
cmd=build info=container status='created' name='dockerslimk_29_20210514173845' id='483c9963b9b34692828315003fc18880278fdaec0a02cfdb1d8359b63af3e461'
time="2021-05-14T17:38:45Z" level=debug msg="RunContainer: container HostConfig.NetworkMode => default len(ports)=2" app=docker-slim command=build component=container.inspector
time="2021-05-14T17:38:45Z" level=debug msg="RunContainer: container NetworkSettings.Ports => map[docker.Port][]docker.PortBinding{\"65501/tcp\":[]docker.PortBinding{docker.PortBinding{HostIP:\"<IP_ADDRESS>\", HostPort:\"49154\"}, docker.PortBinding{HostIP:\"::\", HostPort:\"49154\"}}, \"65502/tcp\":[]docker.PortBinding{docker.PortBinding{HostIP:\"<IP_ADDRESS>\", HostPort:\"49153\"}, docker.PortBinding{HostIP:\"::\", HostPort:\"49153\"}}}" app=docker-slim command=build component=container.inspector
time="2021-05-14T17:38:45Z" level=debug msg="ipc.NewClient(<IP_ADDRESS>,65501,65502)"
time="2021-05-14T17:38:45Z" level=debug msg="channel.NewClient: connect wait timeout - 1m0s"
time="2021-05-14T17:38:45Z" level=debug msg="channel.NewClient: net.DialTimeout(tcp,<IP_ADDRESS>:65501,15s) [time=1621013925650110776]"
time="2021-05-14T17:39:00Z" level=debug msg="channel.NewClient: (dial time = 15.000319532s) - connect error = dial tcp <IP_ADDRESS>:65501: i/o timeout"
time="2021-05-14T17:39:00Z" level=debug msg="channel.NewClient: waiting before trying to connect again..."
time="2021-05-14T17:39:02Z" level=debug msg="channel.NewClient: net.DialTimeout(tcp,<IP_ADDRESS>:65501,15s) [time=1621013942650946145]"
time="2021-05-14T17:39:17Z" level=debug msg="channel.NewClient: (dial time = 15.000454304s) - connect error = dial tcp <IP_ADDRESS>:65501: i/o timeout"
time="2021-05-14T17:39:17Z" level=debug msg="channel.NewClient: waiting before trying to connect again..."
time="2021-05-14T17:39:19Z" level=debug msg="channel.NewClient: net.DialTimeout(tcp,<IP_ADDRESS>:65501,15s) [time=1621013959651850145]"
time="2021-05-14T17:39:34Z" level=debug msg="channel.NewClient: (dial time = 15.000622457s) - connect error = dial tcp <IP_ADDRESS>:65501: i/o timeout"
time="2021-05-14T17:39:34Z" level=debug msg="channel.NewClient: waiting before trying to connect again..."
time="2021-05-14T17:39:36Z" level=debug msg="channel.NewClient: net.DialTimeout(tcp,<IP_ADDRESS>:65501,15s) [time=1621013976652942851]"
time="2021-05-14T17:39:51Z" level=debug msg="channel.NewClient: (dial time = 15.000435023s) - connect error = dial tcp <IP_ADDRESS>:65501: i/o timeout"
time="2021-05-14T17:39:51Z" level=debug msg="channel.NewClient: waiting before trying to connect again..."
time="2021-05-14T17:39:53Z" level=debug msg="channel.NewClient: connect wait timeout (waited=1m8.003791712s)"
time="2021-05-14T17:39:53Z" level=error msg="channel.NewCommandClient: NewClient error = wait timeout"
time="2021-05-14T17:39:53Z" level=error msg="ipc.NewClient init error = wait timeout"
time="2021-05-14T17:39:53Z" level=fatal msg="docker-slim: failure" error="wait timeout" stack="goroutine 1 [running]:\nruntime/debug.Stack(0x74, 0x0, 0xc000078138)\n\truntime/debug/stack.go:24 +0x9f\ngithub.com/docker-slim/docker-slim/pkg/util/errutil.FailOn(0xeeb1e0, 0xc000170480)\n\tgithub.com/docker-slim/docker-slim/pkg/util/errutil/errutil.go:28 +0x54\ngithub.com/docker-slim/docker-slim/pkg/app/master/commands/build.OnCommand(0xc00000eeb8, 0xc0003a8690, 0x7fffbd716043, 0xd, 0x0, 0xc00017c630, 0xc0003d6e50, 0x0, 0x0, 0x0, ...)\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/commands/build/handler.go:426 +0x1c87\ngithub.com/docker-slim/docker-slim/pkg/app/master/commands/build.glob..func1(0xc0003ca160, 0xc0003c6a00, 0xc0003c6fb0)\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/commands/build/cli.go:518 +0x29c5\ngithub.com/urfave/cli.HandleAction(0xc97640, 0xe11d70, 0xc0003ca160, 0xc0003ca160, 0x0)\n\tgithub.com/urfave/cli@v1.22.4/app.go:526 +0xfd\ngithub.com/urfave/cli.Command.Run(0xdcf282, 0x5, 0x0, 0x0, 0x1441930, 0x1, 0x1, 0xe061cb, 0x6c, 0x0, ...)\n\tgithub.com/urfave/cli@v1.22.4/command.go:174 +0x58e\ngithub.com/urfave/cli.(*App).Run(0xc000380380, 0xc000030080, 0x8, 0x8, 0x0, 0x0)\n\tgithub.com/urfave/cli@v1.22.4/app.go:279 +0x7e8\ngithub.com/docker-slim/docker-slim/pkg/app/master.Run()\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/app.go:15 +0x54\nmain.main()\n\tgithub.com/docker-slim/docker-slim/cmd/docker-slim/main.go:8 +0x25\n" version="linux|Transformer|1.35.1|89ddd87f009dd1e7cbd66a5494e5956c3c093edc|2021-04-27_07:10:07PM"

And here's the Dockerfile for the image being used in case that's helpful:
https://gitlab.com/megabyte-labs/dockerfile/ci-pipeline/dockerslim/-/blob/master/Dockerfile

Thanks for the repro details @ProfessorManhattan ! It's super useful. Looks like the main process can't connect to the temporary container it created. It's possible that the target container crashed. Do you mind adding the --show-clogs build command flag to see the logs from the temporary container that gets created. Also can you try using the 1.35.2 version of docker-slim.

Hey @kcq -- thanks for following up. I added --show-clogs and upgraded to 1.35.2 but that did not work.
Things I have tried:

Using the latest docker image that matches the latest docker image service (20.10.6)
TLS enabled and disabled
With and without specifying the entrypoint as ""
With and without compressing docker-slim with upx

Here's the build with TLS enabled:
https://gitlab.com/megabyte-labs/dockerfile/ci-pipeline/ansible-lint/-/jobs/1264169021
And here's the build with TLS disabled (basically the same thing):
https://gitlab.com/megabyte-labs/dockerfile/ci-pipeline/dockerslim/-/jobs/1284746324
And here's the updated container I'm using:
FROM docker:20.10.6 as build

ENV container docker
ENV DOCKERSLIM_SHA256 d87d6c52ccc39f2823817cdd29951eb38237fe2220572558a9281bb37800155c
ENV DOCKERSLIM_URL https://downloads.dockerslim.com/releases/1.35.2/dist_linux.tar.gz

SHELL ["/bin/ash", "-eo", "pipefail", "-c"]
RUN apk --no-cache add --virtual build-dependencies \
      upx=3.96-r1 \
      wget=1.21.1-r1 \
  && wget -nv $DOCKERSLIM_URL -O /tmp/dockerslim.tar.gz \
  && echo "$DOCKERSLIM_SHA256  /tmp/dockerslim.tar.gz" | sha256sum -c \
  && tar -xzvf /tmp/dockerslim.tar.gz \
  && cp -rf dist_linux/* /usr/local/bin \
  && rm -rf /tmp/* dist_linux \
  && upx /usr/local/bin/docker-slim \
  && upx /usr/local/bin/docker-slim-sensor

FROM docker:20.10.6

COPY --from=build /usr/local/bin/docker-slim /usr/local/bin/docker-slim
COPY --from=build /usr/local/bin/docker-slim-sensor /usr/local/bin/docker-slim-sensor

RUN apk --no-cache add \
      jq=1.6-r1 \
  && rm -Rf /var/cache/apk/*

WORKDIR /work

Thanks for looking at this. This is my favorite project on GitHub and I've looked through the top 10,000 projects sorted by stars.

Hey @kcq -- did the logs with --show-clogs output anything useful?

Hi, I can confirm that docker-slim does not work in the GitLab SaaS runners, for the same reason as the OP indicated. See here. Pity.

Hi, I can confirm that docker-slim does not work in the GitLab SaaS runners, for the same reason as the OP indicated. See here. Pity.

@MShekow thanks a lot for providing the logs! Super helpful... and great that the app repo is available too https://gitlab.com/MShekow/docker-slim-example . We'll figure this out :)

@MShekow thanks a lot for providing the logs! Super helpful... and great that the app repo is available too https://gitlab.com/MShekow/docker-slim-example . We'll figure this out :)

@kcq thanks for looking into it. The project (and docker-slim) does work in my organization's private GitLab instance, where we use self-hosted GitLab runners (with "docker" executor), which are configured to mount the host machine's Docker socket into the CI job containers (so we are not using Docker-in-Docker there, but socket mounting). This means that the problem somehow seems to be caused by using the DinD service.

@kcq thanks for looking into it. The project (and docker-slim) does work in my organization's private GitLab instance, where we use self-hosted GitLab runners (with "docker" executor), which are configured to mount the host machine's Docker socket into the CI job containers (so we are not using Docker-in-Docker there, but socket mounting). This means that the problem somehow seems to be caused by using the DinD service.

@MShekow yes, mounting the docker socket with Gitlab's setup is not really an option. Need to use DOCKER_HOST instead. Double checking the exact configs...

Also looks like the main app is not picking up the right IP address when it's trying to talk to the temporary container

Do you have any idea what causes this?

Is there anything I can do to help debug this? Currently facing this issue and don't want to mount sockets. Using DIND:Rootless.

Is there anything I can do to help debug this? Currently facing this issue and don't want to mount sockets. Using DIND:Rootless.

Not mounting the socket should be possible, but rootless hasn't been tested. I'd recommend trying a rootless setup locally if you want to double check if it works. The big question here is the use of fanotify and ptrace. Need to see if they'd work running rootless.

Is there anything I can do to help debug this? Currently facing this issue and don't want to mount sockets. Using DIND:Rootless.

Not mounting the socket should be possible, but rootless hasn't been tested. I'd recommend trying a rootless setup locally if you want to double check if it works. The big question here is the use of fanotify and ptrace. Need to see if they'd work running rootless.

Using sensor-ipc-mode proxy on dind:rootless I get this:
cmd=build info=container message='obtained IP address' ip='<IP_ADDRESS>'  cmd=build info=cmd.startmonitor status='sent'  cmd=build info=event.error status='received' data='SensorError{Op:sensor.fanotify.Run/fanapi.Initialize,Kind:call.error,Wrapped:{Type=syscall.Errno,Info=operation not permitted,Line:47,File:github.com/docker-slim/docker-slim/pkg/app/sensor/monitors/fanotify/monitor.go}}'  cmd=build state=exited code=-124 component=container.inspector version=linux|Transformer|1.37.3-42-g768c393|768c3930f23c509b3f5b39da3940e7cc7a22efc3|2022-02-27_06:38:30PM
So I'd wager dind:rootless might be a no-go here.


normalize_observations=True not working with MPI-parallelized PPO2

First of all, I'm very glad to see the unified algorithm/policy API, as I've been able to successfully create my own callback function that works across all algorithms, with minimal changes to the code (adding a callback argument to each algorithm's learn function, and if callback: callback(locals(), globals()) in the code.
It seems that when normalize_observations=True (one of the network_kwargs parameters), the MPI-parallelized versions of PPO2 don't work. It's important I use the MPI-parallelized and not SubprocVecEnv version due to my custom environment.
Here are simple reproducible examples using CartPole-v1:
Works:
python -m baselines.run --alg=ppo2 --env=CartPole-v1 --normalize_observations=True
python -m baselines.run --alg=ppo2 --env=CartPole-v1 --normalize_observations=True --num_env=2
mpirun -n 1 python -m baselines.run --alg=ppo2 --env=CartPole-v1 --normalize_observations=True
mpirun - n 2 python -m baselines.run --alg=ppo2 --env=CartPole-v1 --normalize_observations=False

Doesn't work:
mpirun -n 2 python -m baselines.run --alg=ppo2 --env=CartPole-v1 --normalize_observations=True
mpirun -n 2 python -m baselines.run --alg=ppo2 --env=CartPole-v1 --normalize_observations=True --num_env=2

To summarize, normalize_observations=True works for all non-MPI cases and fails for all MPI cases except the trivial one in which there is only 1 worker. Looks like the issue is on a comm.Bcast call in mpi_utils.py's sync_from_root.
Traceback:
(venv) name:baselines name$ mpirun -n 2 python -m baselines.run --alg=ppo2 --env=CartPole-v1 --normalize_observations=True
Logging to /var/folders/3q/vr2qmgq17y59wnv9qrn2l2m4001spw/T/openai-2018-10-31-15-03-18-260956
Logging to /var/folders/3q/vr2qmgq17y59wnv9qrn2l2m4001spw/T/openai-2018-10-31-15-03-18-261338
env_type: classic_control
Logging to /var/folders/3q/vr2qmgq17y59wnv9qrn2l2m4001spw/T/openai-2018-10-31-15-03-18-458159
env_type: classic_control
Training ppo2 on classic_control:CartPole-v1 with arguments
Training ppo2 on classic_control:CartPole-v1 with arguments
Traceback (most recent call last):
  File "/usr/local/Cellar/python/3.6.5_1/Frameworks/Python.framework/Versions/3.6/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/local/Cellar/python/3.6.5_1/Frameworks/Python.framework/Versions/3.6/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/Users/petersen33/repositories/baselines/baselines/run.py", line 221, in <module>
    main()
  File "/Users/petersen33/repositories/baselines/baselines/run.py", line 195, in main
    model, env = train(args, extra_args)
  File "/Users/petersen33/repositories/baselines/baselines/run.py", line 78, in train
    **alg_kwargs
  File "/Users/petersen33/repositories/baselines/baselines/ppo2/ppo2.py", line 305, in learn
    model = make_model()
  File "/Users/petersen33/repositories/baselines/baselines/ppo2/ppo2.py", line 304, in <lambda>
    max_grad_norm=max_grad_norm)
  File "/Users/petersen33/repositories/baselines/baselines/ppo2/ppo2.py", line 142, in __init__
    sync_from_root(sess, global_variables) #pylint: disable=E1101
  File "/Users/petersen33/repositories/baselines/baselines/common/mpi_util.py", line 23, in sync_from_root
    comm.Bcast(returned_var)
  File "mpi4py/MPI/Comm.pyx", line 579, in mpi4py.MPI.Comm.Bcast
mpi4py.MPI.Exception: MPI_ERR_TRUNCATE: message truncated

Hi @brendenpetersen ! The short answer is this - do not use normalize_observations with ppo2 :)
even if we were to make it work, normalize_observations requires algorithm to call rms.update() (where rms RunningMeanStd object), which ppo2 does not. Instead, ppo2 can use VecNormalize environment wrapper for observation normalization (VecNormalize does not use MPI at the moment). Eventually, we'll unify observation and reward normalization; but I am not sure which way will it go (environment wrapper or an normalization object within algorithm). Closing this, also creating a separate issue about unifying observation normalization: https://github.com/openai/baselines/issues/698


Remove leftPad function comment

Remove the comment on leftPad which needlessly raised concerns that the
code is actually proprietary.

I signed it!

Thanks @heathkit . That was fast!


typo: Create Policy -> Apply Policy

wording might have changed
Proposed changes
Corrected instructions so they matched AWS

Thanks, @rdesfo :)


Request for Style Change

Hey Abiel !
Awesome work with the chatGPT extension with Raycast, I am currently using it now with a hotkey map and it is effortlessly amazing. Im making a request to remove or reduce the size of the bottom panel with the date, ID and conversation ID. It does not give the results enough space. And potentially allow the side panel width to be draggable to give the results even more space. Style the code blocks a little better with syntax colors and this extension will be 10/10.

Hi,
I'll add an option to disable the metadata details view (date, ID, etc) in the extension settings so users can see the answer immersively. The code syntax color is a great feature idea, I'll try to play around with it. The sizeable width is not something I can do because beyond Raycast limitation.
My current focus is publishing the extension to the Raycast store. Once it's published, I'll add the two features that I've mentioned above.

Closed due to Raycast's extension API. Would consider the code block syntax colors feature in the future.


Updated validations.py python script

Fixed the behavior of validate_user function in validations.py
Closes: #1

It's a good idea to open an issue first for discussion.

[ ] Tests pass
[ ] Appropriate changes to README are included in PR

Coursera.  Thx!


Towards #1108 :In C2D README, show how to submit an algorithm for use by C2D including docker container

Towards #1108 .
Changes proposed in this PR:

Add optional parameter in create_url_asset to indicate whether the asset is an algorithm
In create_with_default_metadata add metadata required for using the default algorithm setup if the created asset is an algorithm

Some things still needed:

in create_algo_asset(), flesh out how checksum is calculated, by using dockerhub api
unit test for new method create_algo_asset()
ensure all tests passing

Some things still needed:

in create_algo_asset(), flesh out how checksum is calculated, by using dockerhub api
unit test for new method create_algo_asset()
ensure all tests passing

@trentmc
All done.
There is an issue with the test on a remote test because of balances of some addresses that ere used for sending transactions in mumbai

There is an issue with the test on a remote test because of balances of some addresses that ere used for sending transactions in mumbai

What specifically?
FYI, when you run the polygon or mumbai tests locally, you have to test your own REMOTE_TEST_PRIVATE_KEY1 and 2. Details: https://github.com/oceanprotocol/ocean.py/blob/main/READMEs/developers.md#3-set-up-contracts

@jfdelgad could you do a "git merge main" into your branch please? Many changes went into ocean.py in the last 24h, and now this PR's diff looks huge.
Once that's in, and tests are passing, please ping me and I will review. Thanks!

@trentmc Closed this because many conflicts with the latest changes, created a new PR #1209


Trouble healing with 500 series

Is your problem within Home Assistant (Core or Z-Wave JS Integration)?
NO, my problem is NOT within Home Assistant or the ZWave JS integration
Is your problem within ZWaveJS2MQTT?
NO, my problem is NOT within ZWaveJS2MQTT
Checklist

[X] I have checked the troubleshooting section and my problem is not described there.

[X] I have read the changelog and my problem was not mentioned there.

Describe the bug
I recently switched back to using an Aeotec Z-Stick 5+ (instead of the 7 I've been using for a few months). I used the migration tool that @AlCalzone has been working on to shift back.
I'm having some trouble completing a full network heal, though. About 50% of my nodes do okay, but the others fail both when triggered individually and when done as part of a network heal.  I moved to another, and it failed. So the behavior seems to be inconsistent. The driver logs are attached.
I do have one node near the center of my network that is currently offline (I inadvertently unplugged its power and am not nearby to plug it back in). The interface seems to have recognized that it's offline and it is now marked to "skip." I thought I could just heal around it (honestly, I'd rather that node not be heavily relied on) - but could its existence be causing this issue?
Device information
Manufacturer: Aeotec
Model name: Z-Stick 5+
Node ID in your network: 13
How are you using node-zwave-js?

[ ] zwavejs2mqtt Docker image (latest)
[ ] zwavejs2mqtt Docker image (dev)
[ ] zwavejs2mqtt Docker manually built (please specify branches)
[ ] ioBroker.zwave2 adapter (please specify version)
[X] HomeAssistant zwave_js integration  (please specify version)
[ ] pkg
[ ] node-red-contrib-zwave-js (please specify version, double click node to find out)
[ ] Manually built from GitHub (please specify branch)
[ ] Other (please describe)

Which branches or versions?
version:
node-zwave-js branch: 8.9.0-beta.1
zwavejs2mqtt branch: 0.32.1
Did you change anything?
no
If yes, what did you change?
No response
Did this work before?
Don't know, this is a new device
If yes, where did it work?
No response
Attach Driver Logfile
zwave_js.log

Further information: doing a Soft Reset on the controller seems to help. I was able to heal 6 stubborn nodes before it started failing again with the "no response from controller" errors.

Upgrade to Z2M 6.2.0 that doesn't include beta.1. That was released by a mistake.

Okay, thanks. I'll work on that. I try to update as soon as new releases are made available through the official integrations, but I'll figure out how to accelerate that locally

Try to use the master branch. I'm not using docker so not sure how it works. But I know the master tag has it. :)

Closing for now - feel free to reopen if the issue persists in v8.9.2.


i18n(ko-KR): update astro-pages.mdx

Description (required)

update astro-pages.mdx
#8573

Related issues & labels (optional)

Closes #
Suggested label:

Lunaria Status Overview
🌕 This pull request will trigger status changes.

Learn more
By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.
You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

Locale
File
Note

ko
basics/astro-pages.mdx
Localization changed, will be marked as complete.

Warnings reference

Icon
Description

🔄
The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.


Form Error doesn't show Form Field that has error

If one of required field is null while submitting form, Form Error only show this message Network error: Cannot read property 'data' of null
graphql response:
{   "errors": [     {       "message": "Cannot read property 'data' of null",       "locations": [         "TypeError: Cannot read property 'data' of null\n    at registerWatchedMutation (http://localhost:3000/packages/vulcan_core.js?hash=701f37454a591447e8a6b44c5d21bf3d324a8981:402:61)\n    at WatchedMutationLink.value [as updateQueryAfterMutation] (http://localhost:3000/packages/modules.js?hash=46f7a6d2a5862753d1af6eeba7f441f283f5fee2:120212:27)\n    at http://localhost:3000/packages/modules.js?hash=46f7a6d2a5862753d1af6eeba7f441f283f5fee2:120275:18\n    at Array.forEach (<anonymous>)\n    at http://localhost:3000/packages/modules.js?hash=46f7a6d2a5862753d1af6eeba7f441f283f5fee2:120268:33\n    at Object.next (http://localhost:3000/packages/modules.js?hash=46f7a6d2a5862753d1af6eeba7f441f283f5fee2:74950:23)\n    at notifySubscription (http://localhost:3000/packages/modules.js?hash=46f7a6d2a5862753d1af6eeba7f441f283f5fee2:74772:18)\n    at onNotify (http://localhost:3000/packages/modules.js?hash=46f7a6d2a5862753d1af6eeba7f441f283f5fee2:74807:3)\n    at SubscriptionObserver.next (http://localhost:3000/packages/modules.js?hash=46f7a6d2a5862753d1af6eeba7f441f283f5fee2:74861:7)\n    at Object.next (http://localhost:3000/packages/modules.js?hash=46f7a6d2a5862753d1af6eeba7f441f283f5fee2:123187:34)"       ]     }   ] }

on latest devel

Could you share your schema?

import { generateIdResolverSingle } from '../../modules/utils/schemaUtils'
import { Utils, getSetting, registerSetting, getCollection } from 'meteor/vulcan:core';

const schema = {
    // default properties

    _id: {
      type: String,
      optional: true,
      canRead: ['guests'],
    },
    createdAt: {
      type: Date,
      optional: true,
      canRead: ['guests'],
      onCreate: () => {
        return new Date();
      },
    },
    userId: {
        type: String,
        optional: true,
        control: 'select',
        viewableBy: ['guests'],
        insertableBy: ['members'],
        hidden: true,
        resolveAs: {
          fieldName: 'user',
          type: 'User',
          resolver: generateIdResolverSingle(
            {collectionName: 'Users', fieldName: 'userId'}
          ),
          addOriginalField: true
        },
      },

    // custom properties

    contractName: {
      label: 'Name',
      type: String,
      // optional: true,
      canRead: ['members'],
      canCreate: ['members'],
      canUpdate: ['members'],
    },
    contractNumber: {
      label: 'Number',
      type: String,
      // optional: true,
      canRead: ['members'],
      canCreate: ['members'],
      canUpdate: ['members'],
    },
    contractValue: {
      label: 'Value',
      type: Number,
      // optional: true,
      canRead: ['members'],
      canCreate: ['members'],
      canUpdate: ['members'],
      form: {
        defaultValue: 0,
        min: 0,
        formatter: value => `${value}`.replace(/\B(?=(\d{3})+(?!\d))/g, ','),
        parser: value => `${value}`.replace(/\$\s?|(,*)/g, ''),
        style: {
          width: '150px'
        }
      }
    },
    contractDate: {
      label: 'Signed Date,
      type: Date,
      // optional: true,
      canRead: ['members'],
      canCreate: ['members'],
      canUpdate: ['members'],
    },
  };

  export default schema;

Hi @darwis059
Last week I have an issue with Datatable a field declared as number  + optional. because in my database I have some imported data from CSV that create documents with an empty field ''.
So my solution was iterate in my document and remove those fields in the specific fields using the following snippet.
db.getCollection('suburbs').update(
	{communityCode: ''},
	{
		$unset: {
			"communityCode": 1,
		}
	},
	{
		upsert: true,
		multi:true
	}
);

What I did to found the issues in my schema + data storage, was to comment out the fields definitions and enable one by one until I found the ones with the issue.
I hope my experience helps you a little bit.

Weird, I just tried submitting a document with empty fields and it worked fine. Also searching the codebase I can't find a trace of registerWatchedMutation actually being used, so I don't know how it could end up throwing an error?

its happen on every type of Field that required and empty while form submitted. on server console detail of required Field error logged.
on client side, the mutationErrorCallback called with document(DOM, not new document from form) passed as document variable <- is this normal?

i tried using vulcan-starter example-simple. it got same error

Hi guys, should be fixed now on devel.
This was due to a failure on watchedMutations. When you create/update/delete, Apollo will detect it and update lists automatically, before the next polling. So you could have this bug on pages that contained both a form and a list (eg when editing from a datatable).
The errors were there, but since an error was thrown before they were sent it failed.

I am still not 100% sure about the internals of watchedMutations, basically they seem to be called if you also have a list on the page that calls the mutationResolver.


Add ALT text to every clickable element in the top bar

Describe the solution you'd like
Each element in the clickable should provide additional context using ALT text
Additional context
https://github.com/owncloud/ocis/assets/33026403/ce05b43a-a4c1-4fc3-ba92-543b461e82c1
As you can see some elements have no alternative text when hovering

@ChrisEdS can be moved to the web repo?

@ChrisEdS why blue ticket?

@ChrisEdS why blue ticket?

Need that for a customer

app switcher = Already implemented
logo (which can be changed using the theming) = "Back to home"
search bar = "Search filter" (the search bar itself has no "hand icon")
user menu = "Settings and more"
These are just ruff ideas

@ChrisEdS can be moved to the web repo?

Sure, sorry for opening inside the wrong repo


TargetWithFilterChain - FilterChain becomes empty array, when no filters

Faster filter check when no filters. Another micro-optimization.

Looks like appveyor stable and previous image are both pointing to a broken  .NET SDK 3.0.301. Waiting for the next update that will include  .NET SDK 3.0.302


Only the checkboard image is saved to output folder

How to automatically save the transparent image?

It seems that fixed by https://github.com/layerdiffusion/sd-forge-layerdiffusion/pull/6

It seems that fixed by #6

Can confirm the fix works. Just make sure to enable the checkbox under 'Settings > Layer Diffusion'.

Would be great if the setting come to the master branch, the need to save every file manually if really frustrating, otherwise - great work, thank you!

Sorry; why is this closed? I'm still getting checkerboards.

can we ask to pull this fix into the main branch? I have the latest version but there is no setting for layered diff in the settings section :(

@NutritiousCookie @AlekFy checkout the PR #6 and continue discussion there

It seems that fixed by #6

Can confirm the fix works. Just make sure to enable the checkbox under 'Settings > Layer Diffusion'.

there is no layer diffusion in setting tab

Yeah it seems that commit was never applied or whatever. Downloading the .py files and manually adding/replacing them in your install seems to be a bad idea, as it's an old version of the file and you'll lose options and might run into errors.
Why was this closed? I just spent way too much time looking for an option that doesn't exist, and then trying to add it in.


crashplan: 4.8.2 -> 4.8.3

Refs #26666
Things done

[ ] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[X ] NixOS
[ ] macOS
[ ] Linux

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

cc @sztupi @domenkozar @jerith666

This works fine for me.  (The Travis CI builds failed with what appears to be an unrelated error, No module named 'dogpile.cache'.)

How do I test this. I get an error on startup:
$ CrashPlanDesktop
/nix/store/hisapihmnadyfap13n9pd6q74q6s4qv3-crashplan-4.8.3-r1/bin/.CrashPlanDesktop-wrapped: line 9: /var/lib/crashplan/bin/run.conf: No such file or directory
Error: Could not find or load main class com.backup42.desktop.CPDesktop

CrashPlanDesktop is just a front-end for https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/backup/crashplan.nix, so you have to set services.crashplan.enable = true in configuration.nix before it'll do anything useful.  (The service creates and populates /var/lib/crashplan.)

Ok. Got tested until I reached the sign-up page.


aws-config and aws-storage cookbooks from Aexol

Codecov Report

Merging #235 into master will decrease coverage by 7.48%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master    #235      +/-   ##
=========================================
- Coverage   35.29%   27.8%   -7.49%
=========================================
  Files         119     103      -16
  Lines        4780    2852    -1928
  Branches        5       5
=========================================
- Hits         1687     793     -894
+ Misses       3093    2059    -1034


CHANGELOG/README changes for 0.16.0

Bumping version, noting changes since last release.

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

/kind flaky-test

If contributing rules or changes to rules, please make sure to also uncomment one of the following line:

/kind rule-update

/kind rule-create

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area engine

/area rules

/area deployment

/area integrations

/area examples
What this PR does / why we need it:
Update CHANGELOG for 0.16.0.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

NONE

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: mstemm
If they are not already assigned, you can assign the PR to them by writing /assign @mstemm in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Thanks for your pull request. Before we can look at it, you'll need to add a 'DCO signoff' to your commits.
:memo: Please follow instructions in the contributing guide to update your commits with the DCO
Full details of the Developer Certificate of Origin can be found at developercertificate.org.
The list of commits missing DCO signoff:

17a0d8e CHANGELOG/README changes for 0.16.0

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

I'm going to try to assign myself as a reviewer, as the changes are just docs and I'm trying to get a release out.

/assign @mstemm

/approve

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: mstemm
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [mstemm]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/lgtm

@mstemm: you cannot LGTM your own PR.

In response to this:

/lgtm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: mstemm
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [mstemm]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/lgtm

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: mfdii, mstemm
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [mstemm]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/approve

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: mfdii, mstemm
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [mstemm]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: mfdii, mstemm
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [mstemm]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Integrate FreeRTOS C++11 into project

See implementation here and add to third-party library.
https://www.codeproject.com/Articles/1278513/Cplusplus11-FreeRTOS-GCC

Adding this will allow embedded projects using multi-threads to be easily and seamlessly ported over to SBCs.


if does not work in a ViewBuilder body

Currently if you try and use if, you are met with:
Value of optional type 'view type?' must be unwrapped to a value of type 'view type'
This can be resolved with an else statement, but then it crashes with:
RuntimeError: memory access out of bounds

Is this reproducible with the default 2020-06-12-a snapshot?

Also, would you be able to post some sample code for reproduction? Thanks!

Yes, that is the snapshot I'm on. Here's some sample code:
VStack {
  if true {
    Text("Yup")
  }
}

Value of optional type 'Text?' (aka 'Optional<Text>') must be unwrapped to a value of type 'Text'

Ok, so I've solved the compilation issue with:
extension Optional : View where Wrapped : View {
  @ViewBuilder
  public var body: some View {
    if let view = self {
      view
    } else {
      EmptyView()
    }
  }
}

However this still causes the runtime error. I also changed _ConditionalContent to a struct to match SwiftUI.
With type erasure I can get around the runtime error:
extension Optional : View where Wrapped : View {
  public var body: AnyView {
    if let view = self {
      return AnyView(view)
    } else {
      return AnyView(EmptyView())
    }
  }
}

I think this is a bug in swiftwasm/swift


update base image to eclipse-temurin:17.0.11_9-jre-jammy

update base image to eclipse-temurin:17.0.11_9-jre-jammy
current image (eclipse-temurin:<IP_ADDRESS>_1-jre-jammy) has high-severity vulnerabilities

Since this  issue was created, a more-recent release of java 17 jre is available: 17.0.12_7-jre-jammy

done - PR #145


Rename this variable to not match a restricted identifier.

Issues flagged by sonar cloud - https://sonarcloud.io/project/issues?resolved=false&rules=java%3AS6213&severities=MAJOR&id=open-metadata_OpenMetadata
Instead of using the restricted identifier name record, we could change it to extensionRecord

Thanks @TheGor1lla assigned it to you


Add new guides for React Native createAsyncStoragePersister

Add new documentation guides about using PersistQueryClientProvider instead of using persistQueryClient.

Dear @TkDodo, I sent this PR, but I didn't have an issue with this PR, if you think using fixes/resolves works are mandatory please give me a shout here, then I will create an issue and will connect it to this PR. thanks.


Address other breadcrumbs issues

Test URLs:
Before: https://main--moleculardevices--hlxsites.hlx.page/products/assay-kits/igg-quantification-assays/valitatiter
After: https://breadcrumbs-links--moleculardevices--hlxsites.hlx.page/products/assay-kits/igg-quantification-assays/valitatiter
Before: https://main--moleculardevices--hlxsites.hlx.page/en/assets/tutorials-videos/bpd/colony-picking-automation-excerpt
After: https://breadcrumbs-links--moleculardevices--hlxsites.hlx.page/en/assets/tutorials-videos/bpd/colony-picking-automation-excerpt
Before: https://main--moleculardevices--hlxsites.hlx.page/en/assets/app-note/dd/img/ai-enabled-phenotypic-analysis-of-label-free-intestinal-organoids
After: https://breadcrumbs-links--moleculardevices--hlxsites.hlx.page/en/assets/app-note/dd/img/ai-enabled-phenotypic-analysis-of-label-free-intestinal-organoids
Before: https://main--moleculardevices--hlxsites.hlx.page/resources/citations/axon
After: https://breadcrumbs-links--moleculardevices--hlxsites.hlx.page/resources/citations/axon

@mhaack for the last one in the PR list resources should maybe be capitalised too. WDYT? Still would be slightly different than the original, but I think that would be ok.

l, but I think that would be ok.

@mhaack for the last one in the PR list resources should maybe be capitalised too. WDYT? Still would be slightly different than the original, but I think that would be ok.

Right added resources to the mapping as well.


Double nesting addRulesetForEach

Is it possible to (double) rules-sets?
The order rules-set works properly, but i can't seem get the (nested) product rule-set to work.
 // product validation rules
 this.productRuleSet = createRuleset()
                               .forProperty("deliveryDate")
                                   .addRule("required")
                               .build();

 // order validation rules
 this.orderRuleSet = createRuleset()
                               .forProperty("products")
                                   .addRulesetForEach(this.productRuleSet)
                               .build();

 // invoice validation rules
 this.invoiceRuleSet = createRuleset()
                                  .forProperty("orders")
                                    .addRulesetForEach(this.orderRuleSet)
                                  .build();

 this.invoiceValGroup = createGroup(this.invoice, this.invoiceRuleSet);

hello, off top of my head you should be able to do what you have above as it just checks at each level in the model is it a RuleLink a RuleSet or a ForEachRule there is some more complexity to it but that should be able it, so if it doesnt work I will make an explicit test for it and verify later.
Currently there is a merge about to take place from one of the forks so this may end up being done after that.

Just done a quick test to check this behaviour:
    it("should correctly validate foreach in foreach", function(done){
        // product validation rules
        var productRuleSet = createRuleset()
            .forProperty("deliveryDate")
            .addRule("required")
            .build();

        // order validation rules
        var orderRuleSet = createRuleset()
            .forProperty("products")
            .addRulesetForEach(productRuleSet)
            .build();

        // invoice validation rules
        var invoiceRuleSet = createRuleset()
            .forProperty("orders")
            .addRulesetForEach(orderRuleSet)
            .build();

        var dummyProduct1 = { deliveryDate: null };
        var dummyProduct2 = { deliveryDate: null };
        var dummyProduct3 = { deliveryDate: null };
        var dummyProduct4 = { deliveryDate: null };

        var dummyOrder1 = { products: [ dummyProduct1, dummyProduct2 ] };
        var dummyOrder2 = { products: [ dummyProduct3, dummyProduct4 ] };

        var dummyInvoice = {
            orders: [ dummyOrder1, dummyOrder2 ]
        };

        var invoiceValidationGroup = createGroup(dummyInvoice, invoiceRuleSet);

        invoiceValidationGroup.getModelErrors()
            .then(function(errors){
                console.log("errors", errors);
                done("error");
            }).catch(done);
    });

and it outputs:
'errors', Object {
 orders[0].products[0].deliveryDate: 'This field is required',
 orders[0].products[1].deliveryDate: 'This field is required',
 orders[1].products[0].deliveryDate: 'This field is required',
 orders[1].products[1].deliveryDate: 'This field is required'
}

So it looks like it works as expected, do you not get the above behaviour? if not can you make a quick repro on something like cloud9 etc?

The problem was that the array was not initialized before creating the validation-group.
it("should correctly validate foreach in foreach", function(done){
    // product validation rules
    var productRuleSet = createRuleset()
        .forProperty("deliveryDate")
        .addRule("required")
        .build();

    // order validation rules
    var orderRuleSet = createRuleset()
        .forProperty("products")
        .addRulesetForEach(productRuleSet)
        .build();

    // invoice validation rules
    var invoiceRuleSet = createRuleset()
        .forProperty("orders")
        .addRulesetForEach(orderRuleSet)
        .build();

    var dummyProduct1 = { deliveryDate: null };
    var dummyProduct2 = { deliveryDate: null };
    var dummyProduct3 = { deliveryDate: null };
    var dummyProduct4 = { deliveryDate: null };

    var dummyOrder1 = { products: [ ] };
    var dummyOrder2 = { products: [ dummyProduct3, dummyProduct4 ] };

    var dummyInvoice = {
        orders: [ dummyOrder1, dummyOrder2 ]
    };

    var invoiceValidationGroup = createGroup(dummyInvoice, invoiceRuleSet);

    invoiceValidationGroup.getModelErrors()
        .then(function(errors){
            console.log("errors", errors);
            done("error");
        }).catch(done);
});

the problem was that the array was not initialized before creating the validation group.
something like te following test
it("should correctly validate dynamic nested arrays", function(done){
    // product validation rules
    var productRuleSet = createRuleset()
        .forProperty("deliveryDate")
        .addRule("required")
        .build();

    // order validation rules
    var orderRuleSet = createRuleset()
        .forProperty("products")
        .addRulesetForEach(productRuleSet)
        .build();

    // invoice validation rules
    var invoiceRuleSet = createRuleset()
        .forProperty("orders")
        .addRulesetForEach(orderRuleSet)
        .build();

    var dummyProduct1 = { deliveryDate: null };
    var dummyProduct2 = { deliveryDate: null };
    var dummyProduct3 = { deliveryDate: null };
    var dummyProduct4 = { deliveryDate: null };

    var dummyOrder1 = { products: [ ] };
    var dummyOrder2 = { products: [ dummyProduct3, dummyProduct4 ] };

    var dummyInvoice = {
        orders: [ dummyOrder1, dummyOrder2 ]
    };

    var invoiceValidationGroup = createGroup(dummyInvoice, invoiceRuleSet);

   dummyOrder1.products.push(dummyProduct1);
   dummyOrder1.products.push(dummyProduct2);

    invoiceValidationGroup.getModelErrors()
        .then(function(errors){
            console.log("errors", errors);
            done("error");
        }).catch(done);
});`

will try it out for you shortly

ok so doing the test you have there outputs:
'errors', Object {
orders[1].products[0].deliveryDate: 'This field is required',
orders[1].products[1].deliveryDate: 'This field is required'
}

So it seems that for some reason it is not picking up the changes, will look into it.

Okay, thanks for testing this out. Let me know if you need my help.

RIGHT!
The crux of it is that the change is not picked up in time, as the default re-check of a model happens every 500ms (configurable), so if a change happens it does not notify the model about it until the next dirty check happens.
So in this case what is happening is that you are changing it, then reporting on it and the change has not flagged up yet, so it would report only the "known" errors. Now this has been an on-going trouble as there are a couple of fixes, one is to do something like delaying calls until after the next model check has happened, another would be to manually trigger the model watcher before you run to confirm any changes are bubbled. So some discussion needs to happen around that.

Thanks for the help, i will try solve this issue with suggested work-arounds.

sorry my above stuff is not a solution for you, its just a way for me to prove what the problem is. We will implement a solution in the core lib its just until this merge is done I dont want to rock the boat any further, so the next version should hopefully have a fix for this, until then you can do a delay temporarily but its just going to be a hack.

right in the next version there is a temporary fix in for this, where if you call getModelErrors it automatically re-validates the entire stack, this is a simple way to solve this issue while the whole discussion on how to best handle non reactive validators and other bits kicks off. The version you will want is 0.11.0 so keep an eye out, I should hopefully release it at some point over the weekend or worst case early next week.

Thanks for the temporary fix, will try it out once it's released.

OK, so to clarify, the issue here (which is solved in the latest release) is that getModelErrors() isn't intended to perform the validation, but to intelligently wait for any pending rules to complete then return a list of errors.
If you want to know if there are any errors then you must use the validate() method, as that returns whether or not the model has any errors, without waiting for the timer on the model change detector to fire. When you then call getModelErrors() it will instantly return the list of errors.
So here's the above test case changing the model and showing the reflected errors immediately:
    it("should correctly validate dynamic nested arrays", function(done) {

        // product validation rules
        var productRuleSet = createRuleset()
            .forProperty("deliveryDate")
            .addRule("required")
            .build();

        // order validation rules
        var orderRuleSet = createRuleset()
            .forProperty("products")
            .addRulesetForEach(productRuleSet)
            .build();

        // invoice validation rules
        var invoiceRuleSet = createRuleset()
            .forProperty("orders")
            .addRulesetForEach(orderRuleSet)
            .build();

        var dummyProduct1 = {deliveryDate: null};
        var dummyProduct2 = {deliveryDate: null};
        var dummyProduct3 = {deliveryDate: null};
        var dummyProduct4 = {deliveryDate: null};

        var dummyOrder1 = {products: []};
        var dummyOrder2 = {products: [dummyProduct3, dummyProduct4]};

        var dummyInvoice = {
            orders: [dummyOrder1, dummyOrder2]
        };

        var invoiceValidationGroup = createGroup(dummyInvoice, invoiceRuleSet);

        var errorCount = () => Object.keys(invoiceValidationGroup.propertyErrors).length;

        dummyOrder1.products.push(dummyProduct1);
        dummyOrder1.products.push(dummyProduct2);

        invoiceValidationGroup.validate().then(isvalid => invoiceValidationGroup.getModelErrors()
            .then(function (errors) {
                expect(isvalid).to.be.false;
                expect(errorCount()).to.equal(4);

                dummyInvoice.orders[0].products[1].deliveryDate = new Date();

                invoiceValidationGroup.validate()
                    .then(function (isvalid) {
                        expect(isvalid).to.be.false;
                        expect(errorCount()).to.equal(3);

                        dummyInvoice.orders[0].products[1].deliveryDate = null;

                        invoiceValidationGroup.validate()
                            .then(isvalid => {
                                expect(isvalid).to.be.false;
                                expect(errorCount()).to.equal(4);
                                done();

                            }).catch(done);
                    }).catch(done);
            }).catch(done)
        ).catch(done);
    });


Simple memory placement optimizations not performed when targeting TPUs

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): Yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Linux Ubuntu 17.10
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device: N/A
TensorFlow installed from (source or binary): source
TensorFlow version (use command below): r1.9
Python version: N/A
Bazel version (if compiling from source): 0.11.1
GCC/Compiler version (if compiling from source): 7.2.0
CUDA/cuDNN version: N/A
GPU model and memory: N/A
Exact command to reproduce: N/A

Describe the problem
I'm playing with compiling Julia code to TF graphs for TPU offload. At the moment, I have the two functions:
f(X, Y) = Y * (X + c_1*X) * (X + c_2*X) * (X + c_3*X) * (X + c_4*X) * (X + c_5*X) * (X + c_6*X) * (X + c_7*X) * (X + c_8*X)
g(X, Y) = Y * (X + c_1*X) * (X + c_2*X) * (X + c_3*X) * (X + c_4*X) * (X + c_5*X) * (X + c_6*X) * (X + c_7*X) * (X + c_8*X) * (X + c_9 * X)

(Note the * is matrix-multiply between two matrices). Now, when I run (the TF graph resulting from the compilation of) these two functions against a cloud TPU (Tensorflow version 1.9), with X,Y both 10,000 x 10,000 Float32 matrices, c_i Float32 constants, f runs fine, but g delivers the following out of memory error:
Tensorflow error: Status: Failed to allocate request for 385.74MiB (404480000B) on device ordinal 0

Total hbm usage >= 7.88G:
    reserved                 528.00M
    persistent allocations     7.37G (7.4% fragmentation)
    program                    33.0K

Persistent allocations include some or all of:
    arguments                771.48M (98.9% utilization)
    output                   385.75M (98.9% utilization) [may share some memory with arguments]

This seems to indicate to me that it's trying to reserve space for all the intermediate matrix results in high bandwidth memory. I would have expected (and @learyg mentioned that it should) that XLA would have optimized the memory placement in order to avoid this problem.
Looking at the profile output for the f function, it seems to be doing all the broadcasts in order, followed by grouping all the matmuls (which would indeed blow the memory budget):

I also note that gap between the broadcasts and the matmuls, during which time it seems to be running XLA again. To me that indicates that XLA is not getting the full TF graph on the server side and thus cannot optimize the memory placement properly. I'm hoping that there's just some missing setting in the TF graph def that would allow it to do its job.
Source code / logs
I was able to reproduce this in raw Tensorflow.jl (which should have a more or less 1:1 API correspondence to python, though of course there may be a bug in the bindings also - cc @malmaud @oxinabox), using code like this:
using TensorFlow
using TensorFlow: Device

sess = Session(Graph(); target="grpc://localhost:8470")

with_device(TensorFlow.NamedDevice("/job:tpu_worker/replica:0/task:0/device:TPU:0")) do
    global X,Y,Z
    X = placeholder(Float32, shape=[10000, 10000])
    Z = Y = placeholder(Float32, shape=[10000, 10000])
    for i = 1:8 # Fails for 1:9
        Z *= X + rand(Float32)*X
    end
end

x, z = rand(Float32, 10000, 10000), rand(Float32, 10000, 10000)
run(sess, Z, Dict(X=>x, Y=>z))

A serialized GraphDef of the graph for f is at https://gist.github.com/Keno/9321e0f1f278b04fbf3b878e551b3ecb
Is there something missing from this GraphDef that would enable XLA to perform the appropriate memory placement optimization on the device?

@jpienaar are the right person to look at this, or can you redirect to someone who is? Thanks.

Sure, I'll start looking at it and then redirect as needed.
@Keno  Do you see the the compile op in the trace?

Yes, I do. I can probably get you the trace somehow if you tell me what files you need.

I don't know how the Julia TF integration works, are you currently generating the graphdef directly?
I think the XLA HLO computations, it would be great if you could dump those too (would provide extra validation).

Yes, right now we're generating the graphdef directly (in particular the one I attached to the original issue) and then XLA is generated server side. Now that https://github.com/tensorflow/tensorflow/tree/master/tensorflow/compiler/xrt is in tree, I'm hoping to move to that for running stuff on TPUs as soon as that becomes available in the TF version deployed on Cloud TPUs, but for now it's raw TF graphdefs.

SG, what I would suggest is to generate the graph to look exactly like one would see when using tpu.rewrite. In particular adding the _tpu_replicate attribute to indicate which nodes are part of the same cluster. The easiest would be to rewrite in Python and use that as your template. The graphs look quite different (and the memory usage is much better too).
If you are generating the graphdef directly then I think that would be your best bet for now: it should not require too many changes (adding replicate metadata/input/output nodes and replicate attribute per node in computation cluster) and then you should end up triggering the same extraction passes.

Nagging Assignee @jpienaar: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Not an issue when using xrt (which just became available with 1.11), so I consider this resolved.


[C++][Parquet] minor compilation issue

I find out some very minor issue when I tried to compile the reader on my environment due to some namespace clashing.
As example shared_ptr and unordered_map are also in C++11 std namespace. Some compile don't like it.
Also I find that with my test files that I'm reading there was a dereference to a null pointer, if the field is required definition_level_decoder_ is null.
I've make the fork and the change https://github.com/ffabbri4/incubator-parquet-cpp/tree/candidate
Reporter: Fabrizio Fabbri / @ffabbri4
Assignee: Fabrizio Fabbri](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=ffabbri4) / @ffabbri4
Note: This issue was originally created as PARQUET-232. Please see the migration documentation for further details.

Nong Li / @nongli:
Issue resolved by pull request 7
https://github.com/apache/incubator-Parquet-cpp/pull/7


Remove outdated non-valid possibles causes of the error in the debug pods section

This is a Bug Report

Remove outdated non-valid possibles causes of the error in the debug pods section

Problem:
In the section https://kubernetes.io/docs/tasks/debug/debug-application/debug-pods/#debugging-pods, you can find as possible case "My pod is running but not doing what I told it to do" -- https://kubernetes.io/docs/tasks/debug/debug-application/debug-pods/#my-pod-is-running-but-not-doing-what-i-told-it-to-do -- indicating as possible causes of this error

Often a section of the pod description is nested incorrectly, or a key name is typed incorrectly, and so the key is ignored.
For example, if you misspelled command as commnd then the pod will be created but
will not use the command line you intended it to use.

The first thing to do is to delete your pod and try creating it again with the --validate option.
For example, run kubectl apply --validate -f mypod.yaml.
If you misspelled command as commnd then will give an error like this:

I0805 10:43:25.129850   46757 schema.go:126] unknown field: commnd
I0805 10:43:25.129973   46757 schema.go:129] this may be a false alarm, see https://github.com/kubernetes/kubernetes/issues/6842
pods/mypod

And for non-so latest kubernetes versions, the pod is NOT created if you make mistakes such as:

nesting
mispelling -- command as commnd --

Simple example confirming it:

kind create cluster
Simple manifest pod with nesting and mispelling errors, saved the manifest as 'pod.yaml'

apiVersion: v1
kind: Pod
metadata:
  name: simple
spec:
  containers:
    - name: simple
        image: busybox:latest # nesting error
      commnd:           # mispelling
        - sleep
        - "3600"

kubectl apply -f pod.yaml and getting an error directly, without the need to pass --validateflag

Proposed Solution:
Remove the invalid references as possible cases, such as mispelling and nesting errors.

If your pod is not behaving as you expected, it may be that there was an error in your
pod description (e.g. mypod.yaml file on your local machine), and that the error
was silently ignored when you created the pod.  Often a key name is typed incorrectly, and so the key is ignored.

The first thing to do is to delete your pod and try creating it again with the --validate option.
For example, run kubectl apply --validate -f mypod.yaml.

The next thing to check is whether the pod on the apiserver....

Page to Update:
https://kubernetes.io/docs/tasks/debug/debug-application/debug-pods/
Note:
No frequent changes in this page since long time

/language en

This is a Bug Report

Remove outdated non-valid possibles causes of the error in the debug pods section

Problem: In the section https://kubernetes.io/docs/tasks/debug/debug-application/debug-pods/#debugging-pods, you can find as possible case "My pod is running but not doing what I told it to do" -- https://kubernetes.io/docs/tasks/debug/debug-application/debug-pods/#my-pod-is-running-but-not-doing-what-i-told-it-to-do -- indicating as possible causes of this error

Often a section of the pod description is nested incorrectly, or a key name is typed incorrectly, and so the key is ignored.
For example, if you misspelled command as commnd then the pod will be created but
will not use the command line you intended it to use.

The first thing to do is to delete your pod and try creating it again with the --validate option.
For example, run kubectl apply --validate -f mypod.yaml.
If you misspelled command as commnd then will give an error like this:

I0805 10:43:25.129850   46757 schema.go:126] unknown field: commnd
I0805 10:43:25.129973   46757 schema.go:129] this may be a false alarm, see kubernetes/kubernetes#6842
pods/mypod

And for non-so latest kubernetes versions, the pod is NOT created if you make mistakes such as:

nesting
mispelling -- command as commnd --

Simple example confirming it:

kind create cluster
Simple manifest pod with nesting and mispelling errors, saved the manifest as 'pod.yaml'

apiVersion: v1
kind: Pod
metadata:
  name: simple
spec:
  containers:
    - name: simple
        image: busybox:latest # nesting error
      commnd:           # mispelling
        - sleep
        - "3600"

kubectl apply -f pod.yaml and getting an error directly, without the need to pass --validateflag

Proposed Solution:
Remove the invalid references as possible cases, such as mispelling and nesting errors.

If your pod is not behaving as you expected, it may be that there was an error in your
pod description (e.g. mypod.yaml file on your local machine), and that the error
was silently ignored when you created the pod.  Often a key name is typed incorrectly, and so the key is ignored.

The first thing to do is to delete your pod and try creating it again with the --validate option.
For example, run kubectl apply --validate -f mypod.yaml.

The next thing to check is whether the pod on the apiserver....

Page to Update: https://kubernetes.io/docs/tasks/debug/debug-application/debug-pods/
Note: This specific section is previous to 2017 -- #3108 --

+1


What is the usage of logger component?

Hello, Can you provide more detail about the logger service and how to get the benefit of it, how to track services in case of any error or failure in some services? And what is the difference between logger and workflow? What I have understood is that both of them are used to log some information related to services, but it is not clear to me what kind of logging info each one can provide. Thank you.

Hello. Logging service listens for the events from other services/containers and logs received info. The idea of logger is to keep logs in a single place from other services, this also helps to see the order of executions. Workflow service is responsible to provide info, which service should be called, when certain request comes from API endpoint. Worklfow implements mapping between external IDs and internal names.

Thank you for the answer.


added configure arguments to --version output

I added configure arguments to the --version output. As suggested in #940
If anything is wrong or you would like this implemented in different way, I would be happy to change anything. 😃
I thought this had been referenced in another issue also but I can't find it.

Merged. Thanks a lot!

This closes #1068.


Feature/applics 80 register to have your say translation 2 of 3

Describe your changes
Translations for the unique 'organisation' pages (and validations) on the register to have your say journey.

https://pins-ds.atlassian.net.mcas.ms/jira/software/c/projects/APPLICS/boards/242?selectedIssue=APPLICS-80

Useful information to review or test

Type of change 🧩

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update
[ ] Other (please explain in the description section above)

Checklist before requesting a review

[x] I have performed a self-review of my own code
[x] I have double checked this work does not include any hardcoded secrets or passwords
[ ] I have made corresponding changes to the documentation
[ ] I have provided details on how I have tested my code
[x] I have referenced the ticket number above
[x] I have provided a description of the ticket
[x] I have included unit tests to cover any testable code changes

:tada: This PR is included in version 1.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.27.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.33.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.14.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


moved all bower_components libraries into public/js folder and refactored all files to use the correct new path

I suggest to move to a new branch for testing

I agree


auro-background: use of deprecated<EMAIL_ADDRESS>

General Support Request
This component has a dependency on a deprecated version of the wcss.
Please update from<EMAIL_ADDRESS>to latest<EMAIL_ADDRESS>or later)

This issue was addressed within the scope of this duplicate issue.

https://github.com/AlaskaAirlines/auro-background/issues/15


N-Bit_up_Down_Counter

#14

https://github.com/acmpesuecc/SystemVerilog-Playground/pull/32

a) this is all verilog
b) you have not understood the question at all
c) you are combining multiple issues in one, which is not allowed

!bounty 5


Add Nuget Links

Description
Add NuGet links to the README.
Type of Change

[ ] Bug Fix
[ ] New Feature
[ ] Breaking Change
[ ] Refactor
[x] Documentation
[ ] Other (please describe)

Checklist

[x] I have read the contributing guidelines
[x] Existing issues have been referenced (where applicable)
[x] I have verified this change is not present in other open pull requests
[x] Functionality is documented
[x] All code style checks pass
[x] New code contribution is covered by automated tests
[x] All new and existing tests pass

Codecov Report
Patch and project coverage have no change.

Comparison is base (6e47d4b) 100.00% compared to head (51a7936) 100.00%.

:exclamation: Current head 51a7936 differs from pull request most recent head 31eccf1. Consider uploading reports for the commit 31eccf1 to get more accurate results

Additional details and impacted files
@@            Coverage Diff            @@
##              main        #3   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            1         1
  Lines            1         1
=========================================
  Hits             1         1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Improve performance using reference, not clonage

The performance (may be) improved if the logger holds a reference to it's parent, instead of cloning the entire base fields, preHooks, postHooks and outputs slices/maps.
At the useReference branch, there's some suggestion:
type hooksChain struct {
	parent *hooksChain
	hooks  Hooks
}

If this struct is used inside the logger struct, replacing the old baseFields, preHooks/postHooks and outputs field types, they will continue to have the same behavior.

This will only help async loggers, since the work still needs to be done. It may be even worse, because we'll need to use no-tail recursion.
We're basically just moving the overhead from the log cloning to the post-hooks phase, that may be executed asynchronously...

useReference branch was deleted, because it was too old. Do it from scratch, if it is really needed


Form not being blocked from being sent and error message resets after focusing out of the input

Hi there,
First, thank you for providing us with this tool :) Pardon me if this is not a bug but IMO I find this behavior weird.
I'm trying to check if two password are equals in a form. As I think there is no out of the box solution for this problem I'm using setError to come up with my own comparison (See https://codesandbox.io/s/react-hook-form-seterror-epesl).
The thing is the form is not always blocked from being sent (after one incorrect edit of the second password we are able to send the form). Moreover, sometime clicking outside the incorrect field (under the submit button for example) resets the error message.
I'd like to find a way to do such comparison or at least not to be able to reset the error message with focus out.
Many thanks,
Have a good day!

thanks for reporting this bug, i will take a look into that 🙏

I have fixed the bug :) thanks for reporting
https://codesandbox.io/s/react-hook-form-seterror-kylns
will publish it soon.
I have one suggestion for what you doing here, why not try out validate in register
  validate: value => value === password,
})```

https://github.com/bluebill1049/react-hook-form/releases/tag/v3.13.0

Hi, thank you for fixing the bug !!
I don't quite get what native validation has to do with that though :confused:
Regarding my problematic, we actually need to link onChange to both input, as the form could be filled in reverse order (quick tricky right :laughing:) https://codesandbox.io/s/react-hook-form-seterror-fj6ds?fontsize=14.
Also, we want to display errors only after the form has been submitted, not while the confirm field is being completed, as it will display error to quickly. It would be better if it could be the default behavior (as for other fields). But I guess we can use formState.submitCount > 0 to check if the form has ever been submitted.
On the other hand, regarding the use of the validate rule, it doesn't quite work as expected (see https://codesandbox.io/s/react-hook-form-seterror-vbrup). It keeps displaying errors even when the inputs are correct and doesn't listen to input change.
It would be better if fields comparison would be supported out of the box and without using setError. But not sure it would not overwhelm the library.
Anyways, thank you very much for the library and for processing my bug request!
Have a good day!

native validation is a separate feature that I have worked for a while which I was going to publish :)
here is a working version with validate
https://codesandbox.io/s/react-hook-form-seterror-9dind
watch need to be called within the validate due to scope. I will take a look at the other example now.

@Romcol happy to close this issue? 🙏

Thanks very much @bluebill1049 ! Only one little use case is not supported by the validate when both fields are completed in reverse order, but with setError that should do it (as in sandbox).

Awesome! You are so kind and polite. Thank you too!