CIMG: Using `exit` in bash login shells always fails the step

In the below configuration, we simply test running “exit 0” under 2 shells. The default linux shell and one with the login option added “-l”.

version: 2.1

workflows:
  test_exit:
    jobs:
      - test_non_login
      - test_login
jobs:
  test_non_login:
    docker:
      - image: cimg/base:2020.03
    steps:
      - run:
          name: Test exiting in non login shell
          shell: /bin/bash -eo pipefail
          command: |
            exit 0
  test_login:
    docker:
      - image: cimg/base:2020.03
    steps:
      - run:
          name: Test exiting in login shell
          shell: /bin/bash -eo pipefail -l
          command: |
            exit 0

The non login shell job succeeds, as expected, whereas the login shell fails with this:

It seems like it’s related to the CircleCI container.

docker run --rm -it ubuntu:latest  /bin/bash -elc "exit 0" #returns 0
docker run --rm -it cimg/base:2020.03  /bin/bash -elc "exit 0" #returns 1

The situation only happens when both login and errexit are used.
Thanks,
Phil

Ok turns out the CircleCI base image (cimg/base) creates a new user. This is a good thing. However, useradd uses /etc/skel/ as a template for the user’s home directory. This template, in the current version of the ubuntu:18.04 contains some shell hooks: .bashrc, .profile and .bash_logout. The last command of the logout hook is clear_console -q. This returns 1, therefore the whole logout step will return 1 when using -e and -l in bash.

This happens when running exit in a step in CircleCI (non interactive shell)

My point of view is that it may be desirable to use a login shell in CircleCI. For example, our base image at work leverages pyenv and nvm, which can both benefit from login hooks for convenience. So we change the default shell to be /bin/bash -eo pipefail -l in our executor

The -e option when running steps is also highly desirable.

We worked around this by removing all default shell hooks from the /home/circleci/ directory. I’m unsure if this should end up as a ticket for the actual image repository or not, seems like its default Ubuntu behaviour.