PHP CLI image instruction adding crontab entry cannot succeed

[f4z4on]

Preconditions

1. Docker 20.10.12
2. Magento Cloud Docker 1.3.2 (source code)

Steps to reproduce

1. Start in directory with source code of Magento Cloud Docker 1.3.2.
2. cd images/php/7.4-cli
3. docker build .

Expected result

1. The relevant step succeeds:

   Step 44/48 : RUN if [ ! -z "${CRONTAB}" ]; then echo "${CRONTAB}" > /etc/cron.d/magento && touch /var/log/cron.log ; fi
    ---> Running in f74f6ae577c2
   Removing intermediate container f74f6ae577c2
    ---> 7f64efe9445c
   

   Notice the difference from current Dockerfile. Expected RUN instruction uses POSIX-compliant [ instead of Bash-specific [[.

2. Alternatively, this instruction is deemed redundant as nobody noticed since its introduction in d78c326 (and being part of two releases).

Actual result

1. The relevant step technically succeeds, but logically always fails no matter the actual value of $CRONTAB:

   Step 44/48 : RUN if [[ ! -z "${CRONTAB}" ]]; then echo "${CRONTAB}" > /etc/cron.d/magento && touch /var/log/cron.log ; fi
    ---> Running in cc4ba5f26f15
   /bin/sh: 1: [[: not found
   Removing intermediate container cc4ba5f26f15
    ---> a329b4cfebf5
   

[f4z4on]

I apologize my report is not from user perspective, but I am not familiar with cron features of Magento Cloud Docker. I cannot say if something is missing and broken, or if this instruction is redundant. I simply noticed the issue when doing some experiments with Cloud Docker PHP images outside of Magento Cloud Suite.

[OneCricketeer]

always fails no matter the actual value of $CRONTAB

The variable isn't the issue, it's that [[ syntax is not valid for POSIX shell (which the Docker build RUN command uses)

[f4z4on]

This is the difference between my expected result and reported actual result. I should have mentioned it explicitly though. I have updated the description. Thank you for pointing it out @OneCricketeer.

However, CRONTAB is a built-time argument to image build (ARG instruction). It is set to an empty string by default. And as far as I can tell, nothing ever changes that default at built-time. I know entrypoints recognize CRONTAB environment variable, but this is a different scope. Which is why I think the reported instruction is redundant.

The instruction can be deemed as redundant because nobody noticed it has never done what its author intended. So it probably does not have be there.

Lastly, the exact same thing is done by entrypoint.