Merge pull request #176 from bird-house/fix/autodeploy-job

Bugfix for autodeploy job

The new code added with [this merge](d90765a) created a new bug for the autodeploy job.

From the autodeploy job's log : 
```
triggerdeploy START_TIME=2021-05-13T14:00:03+0000
Error: DEPLOY_DATA_JOB_SCHEDULE not set
```
If the `AUTODEPLOY_NOTEBOOK_FREQUENCY` variable is not set in the `env.local` file, it would create the error above.
The variable is set in the `default.env` file, in case it is not defined in the `env.local`, and is then used for the new env file from pavics-jupyter-base [here](https://github.com/bird-house/pavics-jupyter-base/blob/1f81480fe90e0a110f0320c6d6cb17f73b657733/scheduler-jobs/deploy_data_pavics_jupyter.env#L15).
The error happens because the `default.env` was not called in the `triggerdeploy.sh` script, and the variable was not set when running the `env.local`.

Solution was tested in a test environment and the cronjob seems to be fixed now.

I tried to see if the same situation could be found anywhere else. From what I see, default.env seems to be called in a consistent way before the env.local.
There is just [here](https://github.com/bird-house/birdhouse-deploy/blob/7e2b8cb428be29d52d27b4b1faa73be7017712ea/birdhouse/deployment/deploy.sh#L109), where the default.env doesn't seem to be called. A default.env call has also been added in that file.

birdhouse/deployment/deploy.sh

@@ -105,6 +105,8 @@ cd $COMPOSE_DIR
 START_TIME="`date -Isecond`"
 echo "deploy START_TIME=$START_TIME"
 
+. $COMPOSE_DIR/default.env
+
 # Read AUTODEPLOY_EXTRA_REPOS
 . $ENV_LOCAL_FILE
 

birdhouse/deployment/triggerdeploy.sh

@@ -119,6 +119,8 @@ START_TIME="`date -Isecond`"
 echo "==========
 triggerdeploy START_TIME=$START_TIME"
 
+. $COMPOSE_DIR/default.env
+
 # Read AUTODEPLOY_EXTRA_REPOS
 . $ENV_LOCAL_FILE