GitLab CI - Error: BATS_TMPDIR (/tmp) is not writable

[cavo789]

Hello

I can't start bats in a GitLab CI, each time I got Error: BATS_TMPDIR (/tmp) is not writable. I've tried to change the target folder but nothing works.

My .gitlab-ci.yml file:

variables:
  GIT_SUBMODULE_STRATEGY: recursive 
  TMPDIR: "${CI_PROJECT_DIR}/.tmp"
  BATS_TMPDIR: "${CI_PROJECT_DIR}/.tmp"

stages:
  - test
 
bats:
  stage: test
  image: bash:5.1.16-alpine3.15
  script:
    before_script:
    - echo "BATS_TMPDIR IS **${BATS_TMPDIR}***"
    - mkdir -p "${BATS_TMPDIR}" && chmod 777 "${BATS_TMPDIR}"
    - ls -alh
    - ./test/bats/bin/bats --version
    script:
    - ./test/bats/bin/bats ./test

Environment:

• Bats Version 1.6.0
• OS: Linux
• Bash version: 5.1.16

As you can see below, the BATS_TMPDIR folder is set to my current working folder and I've create the folder (mkdir -p) and change his permissions to 777. The image show that the folder is created with the correct permission but, neverthless, I continue to get the "is not writable" message.

Did you see where I'm wrong?

(I've also tried to use the Docker image https://hub.docker.com/r/bats/bats but I was unable too to make it working i.e. which command should I run because bats seems unknown)

[martin-schulze-vireso]

From the documentation:

$BATS_TMPDIR is the base temporary directory used by bats to create its temporary files / directories. (default: $TMPDIR. If $TMPDIR is not set, /tmp is used.)

This means it is readonly (from outside Bats) and can only be populated from $TMPDIR.

However, since you set $TMPDIR that is not the issue. I'll need to try to reproduce this later to see what is happening. Is the behavior occuring on other Bats versions too?

[cavo789]

Will check tomorrow. Thanks for your really fast answer.

[martin-schulze-vireso]

I tried to reproduce this locally with bats-core checked out at v1.6.0 and using the following adapted .gitlab-ci.yml:

variables:
  GIT_SUBMODULE_STRATEGY: recursive 
  TMPDIR: "${CI_PROJECT_DIR}/.tmp"
  BATS_TMPDIR: "${CI_PROJECT_DIR}/.tmp"

stages:
  - test
 
bats:
  stage: test
  image: bash:5.1.16-alpine3.15
  before_script:
    - echo "BATS_TMPDIR IS **${BATS_TMPDIR}***"
    - mkdir -p "${BATS_TMPDIR}" && chmod 777 "${BATS_TMPDIR}"
    - ls -alh
    - ./bin/bats --version
  script:
    - ./bin/bats ./test

However, the tests ran as expected:

$ echo "BATS_TMPDIR IS **${BATS_TMPDIR}***"
BATS_TMPDIR IS **/builds/project-0/.tmp***
$ mkdir -p "${BATS_TMPDIR}" && chmod 777 "${BATS_TMPDIR}"
$ ls -alh
total 116K   
...
-rw-rw-rw-    1 root     root         140 Apr  7 21:24 .readthedocs.yml
drwxrwxrwx    2 root     root        4.0K Apr  7 21:24 .tmp
-rw-rw-rw-    1 root     root         219 Apr  7 21:24 AUTHORS
....
$ ./bin/bats --version
Bats 1.6.0
$ ./bin/bats ./test
1..205
ok 1 no arguments prints message and usage instructions
...

[cavo789]

Thanks for your very fast support.

I am using ./test/bats/bin/bats in the CI (and not ./bin/bats) because bats is installed in that folder. Here is the content of my .gitmodules.

[submodule "test/bats"]
	path = test/bats
	url = https://github.com/bats-core/bats-core.git
[submodule "test/test_helper/bats-support"]
	path = test/test_helper/bats-support
	url = https://github.com/bats-core/bats-support.git
[submodule "test/test_helper/bats-assert"]
	path = test/test_helper/bats-assert
	url = https://github.com/bats-core/bats-assert.git
[submodule "test/test_helper/bats-file"]
	path = test/test_helper/bats-file
	url = https://github.com/bats-core/bats-file
[submodule "test/test_helper/bats-mock"]
	path = test/test_helper/bats-mock
	url = https://github.com/grayhemp/bats-mock

I've tried with your suggestion (./bin/bats) but, of course, the file isn't found

I've also tried to install v1.5.0 (instead of v1.6.0) and still the same error (which I didn't understand since the folder has been well created, owned by root (same user) and having 777 as chmod)

I'll revert to v1.6.0 in the meantime and disable that stage in my CI.

[martin-schulze-vireso]

I am using ./test/bats/bin/bats in the CI (and not ./bin/bats) because bats is installed in that folder.

Yes, my intention was to show what I had done to reproduce this. As I reused the bats-core repository, I needed to adapt the file paths. I don't think that the location of bats matters in this case.

I've also tried to install v1.5.0 (instead of v1.6.0) and still the same error

Okay, so we probably don't have a regression here. Did this work before or did you just set up a new Bats test suite?

Can you recreate a public reproducer repository of this? My gut feeling is, that there is something about your CI system/environment that trips up the test. You can also try to run test -w "$BATS_TMPDIR" || echo Not writable and see if it agrees with Bats (it should, since this is the test Bats is running internally). If it does agree, then you will have to fix this on your end.

[cavo789]

Indeed, not writable...

This sounds crazy to me. The folder has been created during the CI, under root and 777.

I perfectly understand it's a problem / setting on my side. I'll close this issue thus; nothing to do with Bats.

Thanks Martin for the very good support.

[martin-schulze-vireso]

Just for the curious: did you find out what was causing this?

[dr4vs]

Hi,

I had a similar problem, but what I notice is that on sh there is no issue:

Seems like the issue is in the latest version of bash used in the newest bats images. After changing the bats image version to the old one 1.2.1 with bash 5.0, the problems are gone. Possible that the issue exists only when running Docker in Docker, as it is in GitLab pipeline.

[martin-schulze-vireso]

The old bats version might lack the failing check.

[dr4vs]

I've built the image from source as well, by specifying bash version in Dockerfile.
ARG bashver=5.1.4

Versions which I tested:
Working: 5.0.16 and 5.1.4
Failed: 5.1.16, 5.1.12, 5.1.8, 5.0.18

It's not a bats issue that -w condition does not work correctly, in some versions. I wanted just to let You know that using a different bash could fix the issue.

[martin-schulze-vireso]

Okay, thanks for the feedback and the detailed Investigation.

[chilversc]

To follow up further on this, I think this is caused by Alpine 3.14 updating glibc to use the faccessat2 syscall on Linux, https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.14.0#faccessat2.

The main issue appears to arise due to seccomp incorrectly returning EPERM for unknown syscalls instead of ENOSYS. opencontainers/runc#2151

This causes the access check to incorrectly fail with EPERM instead of falling back to the older faccessat syscall.

It should be noted that the faccessat2 was added to kernel 5.8. However, the kernel version is not relevent to this issue because the issue is caused by the seccomp profile blocking the syscall and returning EPERM instead of ENOSYS.

From the Alpine notes there are three options to solve this, use runc >= v1.0.0-rc93, use docker >= 20.10, or as a workaround change the default action of the seccomp profile to SCMP_ACT_TRACE.

Testing the SCMP_ACT_TRACE workaround

In this test I'm using an older kernel (pre 5.8 that does not implement faccessat2), an older runc, and an older docker.

• Ubuntu 20.04.4 LTS
• 5.4.0-121-generic
• Docker version 19.03.4, build 9013bf583a
• runc version 1.0.0-rc8+dev

When trying to run the 1.7.0 bats image as standard the test -w check fails as per the issue reported.

When repeating the test, using the workaround bats was able to execute correctly.

Though I do not know the implications of this setting, so I cannot advise if this workaround is suitable for your environment.