mirror of
https://github.com/digital-asset/daml.git
synced 2024-09-19 16:57:40 +03:00
86bce50b9a
Somehow, in the current setup, the publish steps do not get executed on master. This is what Azure reports: ``` Evaluating: and(succeeded(), eq('$(is_release)', 'true'), eq(variables['Build.SourceBranchName'], 'master'), eq('linux', 'linux')) Expanded: and(True, eq('$(is_release)', 'true'), eq(variables['Build.SourceBranchName'], 'master'), eq('linux', 'linux')) Result: False ``` So it looks like, in the condition, `${{parameters.is_release}}` evaluates to the literal string `$(is_release)`. If we look at the point of invocation of the ~function~ template, we can see: ``` - template: ci/build-unix.yml parameters: release_tag: $(release_tag) name: 'linux' is_release: $(is_release) ``` so it does not seem completely crazy. However, according to the documentation, we should expect that to be replaced by the value of the corresponding variable, as per: ``` variables: release_sha: $[ dependencies.check_for_release.outputs['out.release_sha'] ] release_tag: $[ coalesce(dependencies.check_for_release.outputs['out.release_tag'], '0.0.0') ] trigger_sha: $[ dependencies.check_for_release.outputs['out.trigger_sha'] ] is_release: $[ dependencies.check_for_release.outputs['out.is_release'] ] ``` What's interesting here is that, within `build-unix.yml`, we are also using `release_tag` in the exact same way: ``` - bash: ./build.sh "_$(uname)" displayName: 'Build' env: DAML_SDK_RELEASE_VERSION: ${{parameters.release_tag}} ``` and this time output from the build seems to show the value being correctly substituted: ``` damlc - Compiler and IDE backend for the Digital Asset Modelling Language SDK Version: 0.13.55-snapshot.20200226.3266.d58bb459 Usage: <interactive> COMMAND Invoke the DAML compiler. Use -h for help. ``` My current guess is that the (undocumented, as far as I can tell) evaluation order is as follows: 1. In the template, syntactically replace all the parameters. 2. In the job definition, replace the call to the template with the code of the template. So it is as if we had written the template directly in the `azure-pipelines.yml` file, with `$(release_tag)` and `$(is_release)`. 3. Run the build. When we reach the time to run this specific job, we can evaluate the expressions for the variables and replace them in the rest of the job. So what is going wrong? I believe the issue is with the quotes, preventing the substitution of `is_release`. They came directly from the [documented syntax](https://docs.microsoft.com/en-us/azure/devops/pipelines/process/conditions?view=azure-devops&tabs=yaml#use-a-template-parameter-as-part-of-a-condition), but if the above evaluation order is correct, they should not be there. There are actually two things going wrong here. The first one is that the syntax `$()` is used to substitute a value in what Azure considers a string. This is the case for `env` keys. However, the `condition` key is not a string, it is an Azure "expression". Expressions have their own evaluation rules and syntax, and in particular, `$()` is not a substitution rule there, so when it sees `$()` in a string in an expression (due to the quoptes), it leaves it alone. Removing the quotes does not directly help, though, as we then end with ``` condition: eq($(is_release), 'true') ``` and `$()` is not valid syntax in an expression. The way to use variables in an expression is `variables.name` (or `variables["name"]`, because why have only one?). So that means we have to pass variables to the template in different ways depending on how they will be used. So much fun. CHANGELOG_BEGIN CHANGELOG_END |
||
---|---|---|
.. | ||
azure-cleanup | ||
cron | ||
docker/daml-sdk | ||
build-unix.yml | ||
build-windows.yml | ||
check-changelog.sh | ||
configure-bazel.sh | ||
dev-env-install.sh | ||
dev-env-push.py | ||
report-end.yml | ||
report-start.yml | ||
slack_user_ids | ||
tell-slack-failed.yml | ||
windows-diagnostics.ps1 |