XalokNext Documentation

Appearance

V7.4 main changes ​

DotEnv ​

Intro ​

For multisite single-installation the values of some parameters that are site-specific needs to be determined at runtime, when the chosen site is known. For this reason, XalokNext loads environment variables from an (optional) .env file in the root of the project.

Overwriting values ​

Variables defined in the .env file can be overwritten with environment specific values by adding a .env.dev (in dev environments) or .env.prod (in prod environments) file

Using environment variables ​

shell
# .env
S3_BUCKET='s3_bucket'
yaml
# app/config/parameters/local.yml
parameters:
  s3_bucket: '%env(S3_BUCKET)%'

No rehub ​

Deploy artefacts are built in gitlab's CI using configuration parameters for PRO. The publicUrl JavaScript config is thus dumped in the webpack's compilation output, using the value from PRO. To change this value on the PRE environment, a replacement of the PRO URL with the PRE one is done through the JavaScript files.

v7.4 replaces this process by dumping the fresh JSON post-deploy and reading it from there:

shell
./app/admin/console --env=prod wf:cms:wf-assets __ADMIN_BASE_URL__ --filter "config.json"

Note: In spite of requiring the __ADMIN_BASE_URL__ argument, this argument is used for generating absolute URLs in the assets, the command does not connect to the webserver, so it can be safely run (and it must be run) before changing the /var/www/sites/enabled symlink to the new version.

Log wf-assets errors on CI ​

When an error happens when downloading one of the wf-assets, the command outputs "Error XXX downloading URL". It doesn't log any additional details (like the HTML contents of the error) because that would be very verbose, burying this error message in many lines, likely leaving the developer clueless on what __URL__ had the error. For developers it's easier to get that __URL__ and put it in a browser and check the error.

On CI builds, on the other hand, the developer was left clueless with regard to what might've caused the error and debugging it was quite a cumbersome process. This is why in v7.4+ the wf-assets command logs the contents of the first error. It's only the first error in order to keep the output under some control (logging the HTML contents of tens of errors would make it difficult to see where one ends and another starts), but usually there's a single cause that leads to many errors.

For detecting whether it's running in a CI environment or not, one must set the CI environment variable in their ansible. This was done for the branch feature/generalization of the vagrant-provision repository in this commit. If using a different branch/provisioning repository, one must add these lines to their vagrant/build_pre_task.yml:

yaml
  - name: Ensure CI environment variable
    lineinfile:
      path: "/etc/environment"
      insertbefore: BOF
      line: "CI=true"
      state: present