DT-598: Fixes #2722: ci.blt.yml not consistently applied.

[danepowell]

Fixes #2722

Changes proposed

• Add documentation about how yml properties are expanded
• Fix ci environment not being detected when building artifact on Pipelines

Steps to replicate the issue

1. Add a post-deploy-build command to ci.blt.yml, i.e.:

command-hooks:
  post-deploy-build:
    dir: /tmp/artifact
    command: 'npm install'

2. Commit and start a pipelines job.

Previous (bad) behavior, before applying PR

The post-deploy-build command is not run

Expected behavior, after applying PR and re-running test steps

The post-deploy-build command is run

[danepowell]

This is the second or third bug we've caught where this parameter was missing.

There are ways we could refactor this to avoid passing --environment=ci every time, such as setting BLT_ENV=ci as an environment variable once at the start of the script, or by incorporating EnvironmentDetector::isCiEnv() into the DefaultConfig environment detection step. They aren't without risk though, and at any rate are beyond the scope of this PR.

[alexxed]

CI=true is present in most CI environments today. If not (looking at Jenkins, people can set it).

Why does blt have to act differently in CI vs on your machine ?

[danepowell]

Good point about the CI variable, we should key off of that. I created this followup issue: #3859

This ticket is itself a good example of why BLT needs to behave differently. System paths are different, available resources are different, you need different modules enabled, etc... In this particular case, the deploy directory is pretty special in Pipelines.

[alexxed]

CI=true is present in most CI environments today. If not (looking at Jenkins, people can set it).

Why does blt have to act differently in CI vs on your machine ?