I have the following variable in my pipeline script:
variables:
is_main: $[eq(variables['Build.SourceBranch'], 'refs/heads/main')]
And I want to use it like this:
- script: npm run build -- --source-map=$(is_main)
Unfortunately that leads to an error because "True" is not allowed:
> ng build "--source-map=True"
Cannot parse arguments. See below for the reasons.
Argument --source-map could not be parsed using value "True".Valid type(s) is: boolean
##[error]Bash exited with code '1'.
Finishing: Angular build
I need to lowercase the boolean, and I want to do so in the script step to keep the variable in the pipeline as a true boolean (as opposed to a string) until the last possible moment. I've tried several options. To summarize:
Option 1 $(is_main) leads to:
Argument --source-map could not be parsed using value "True".Valid type(s) is: boolean
Option 2 $[lower($(is_main))] leads to:
lower(True): syntax error in expression (error token is "(True)")
Option 3 $[lower(variables('is_main'))] leads to:
lower(variables('is_main')): syntax error in expression (error token is "(variables('is_main'))")
Option 4 $[lower(variables['is_main'])] leads to:
lower(variables['is_main']): syntax error in expression (error token is "(variables['is_main'])")
Option 5 ${{ lower(variables.is_main) }} (which should not work as far as I could tell from documenation, because it is not used for runtime evaluation, but hey....) leads to:
eq(variables['build.sourcebranch'], 'refs/heads/main'): syntax error in expression (error token is "(variables['build.sourcebranch'], 'refs/heads/main')")
I've read through the "Expressions" documentation on Azure Pipelines MSDN pages and my above attempts are based on it already.
What is the proper way to convert a boolean variable in an Azure Devops pipeline to a lowercase string to be used inside a script step?
Footnote:
For now I use this workaround:
variables:
is_main: $[eq(variables['Build.SourceBranch'], 'refs/heads/main')]
generate_source_maps: $[lower(variables['is_main'])] # script step requires lowercase boolean
And use it like this:
- script: npm run build -- --source-map=$(generate_source_maps)
Quite suboptimal because generate_source_maps is a string whereas the name suggests it's a boolean, and the conversion to lowercase happens very far from the place in the yml where it is relevant and obvious that this is needed. But it works.
My team and I encountered a similar problem just now [A], and convertToJson worked for us as a way to convert a Pipeline boolean value to lowercase string literal.
Since your initial value is a non-static variable, I don't think you can inline this expression into your script line though [B] - you probably still need an extra variable.
Perhaps this would work for you?
variables:
is_main: $[eq(variables['Build.SourceBranch'], 'refs/heads/main')]
is_main_str: $[convertToJson(variables['is_main'])]
- script: npm run build -- --source-map=$(is_main_str)
[A]: Specifically, we wanted to pass a Pipeline parameter value of type boolean to an ARM template parameter via overrideParameters on an AzureResourceManagerTemplateDeployment#3 task.
[B]: According to the docs, Compile time expressions can be used anywhere; runtime expressions can be used in variables and conditions., and only runtime expressions can access non-static variables. Looks like the $() macro syntax cannot evaluate an expression.
Use boolean variable as lowercase string in Azure Devops YML pipeline script
You could try to below scripts:
variables:
is_main: $[eq(variables['Build.SourceBranch'], 'refs/heads/main')]
- script: npm run build -- --source-map=$(echo "$(is_main)" | tr "[:upper:]" "[:lower:]")
If above not work for you, please try to use below scripts:
variables:
Branch: $[eq(variables['Build.SourceBranch'], 'refs/heads/Dev_Test5')]
is_main: $(echo "$(Branch)" | tr "[:upper:]" "[:lower:]")
- script: npm run build -- --source-map=$(is_main)
Related
$CI_ENVIRONMENT_NAME doesn't work with rules:changes. Is it expected behaviour?
rules:
- changes: # Include the job and set to when:manual if any of the follow paths match a modified file.
- authurl/config/$CI_ENVIRONMENT_NAME/*
when: manual
allow_failure: false
As soon as the variable replaced with a static value the rule stars working.
The docs mention that $CI_ENVIRONMENT_NAME is available only if environment:name is set.
For expected behavior, you might have to add the environment value to the job.
Is it possible to get GitLab to report out what it's actually running in the output log. For example, the following .gitlab-ci.yml
variables:
MAVEN_CLI_OPTS: >-
-s $CI_PROJECT_DIR/.m2/settings.xml
--batch-mode
--errors
--fail-at-end
--show-version
-DinstallAtEnd=true
-DdeployAtEnd=true
compile-test-package:
stage: package
script:
- mvn ${MAVEN_CLI_OPTS} package
The run log then shows this
...
mvn ${MAVEN_CLI_OPTS} package
...
But I really would like it to give the specific details like
...
mvn -s path/to/my/project/.m2/settings.xml --batch-mode --errors --fail-at-end --show-version -DinstallAtEnd=true -DdeployAtEnd=true package
...
The best I've learned on this is that GitLab doesn't have a way to report the full details of what its executing. As Michael Delgado mentioned, putting an echo in to output will give you a method to do this. However use this with cation cause protected values could be exposed using this method.
I'm still struggling with variable replacement but at least now I can see what GitLab is replacing and not.
The Azure DevOps pipeline has this variable:
Name: pat
Value: Git repo authentication token
The pipeline has a Bash script task. It is set to filepath. Filepath is set to script.sh. script.sh begins with:
git clone https://username:$(PAT)#dev.azure.com/company/project/_git/repo-name
Errors in pipeline logs:
PAT: command not found
Cloning into 'repo-name'...
fatal: Authentication failed for 'https://dev.azure.com/healthcatalyst/CAP/_git/docs-template/'
To validate that the authentication token and repo URL are accurate, I can verify this works when run as inline code:
git clone https://username:$(pat)#dev.azure.com/company/project/_git/repo-name
script.sh file is in repo-name.
However, environment variables work. Both of the following return the accurate value within the script. Note that one has no quotes and the other does.
echo $BUILD_REPOSITORY_NAME
repo-name
echo "$BUILD_REPOSITORY_NAME"
repo-name
Based on documentation I've seen (I am having difficulty with Microsoft's docs because I am not using a YAML file), I've tried unsuccessfully:
$pat
$PAT
$(PAT)
"$(PAT)"
gitToken=<backtick - Markdown is not allowing me to show a backtick here>echo $PAT<backtick>
Does anyone know what I'm doing wrong? Thank you for any tips.
Is your PAT variable a secret variable ?
If so, then it's not directly accessible in script files
As you can see in the documentation: https://learn.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch#secret-variables
Unlike a normal variable, they are not automatically decrypted into environment variables for scripts. You need to explicitly map secret variables.
Example:
...
env:
MY_MAPPED_ENV_VAR: $(mySecret) # the recommended way to map to an env variable
Or if you are using the visual editor, like that:
Use System.AccessToken instead of personal PAT:
git clone https://$SYSTEM_ACCESSTOKEN#dev.azure.com/company/project/_git/repo-name
To enable $SYSTEM_ACCESSTOKEN: go to release page in ADO > Tasks > Agent job > check Allow scripts to access the OAuth token
I am calling a GitHub action, and I want to pass it the parameter extra_build_args with the value --build-arg CURRENT_DD_VERSION={$VER} (not in string) where $VER is a shell variable that I set with a specific version. When I check what was passed in I see it took the literal value {$VER} instead of resolving the variable. I set $VER in a different (earlier) step of the Github action. How can pass in the content of the shell variable as a parameter?
- name: Get version
run: |
VER=$(cat ver.txt)
- name: Build docker image
uses: kciter/aws-ecr-action#v3
with:
//some more parameters
extra_build_args: "--build-arg CURRENT_DD_VERSION={$VER}"
Check first the syntax:
${VER}
# not
{$VER}
In your case:
extra_build_args: "--build-arg CURRENT_DD_VERSION=${VER}"
You also have the documentation "Environment variables"
To set custom environment variables, you need to specify the variables in the workflow file.
You can define environment variables for a step, job, or entire workflow using the jobs.<job_id>.steps[*].env, jobs.<job_id>.env, and env keywords.
The examples would use $VER
Or:
extra_build_args: "--build-arg CURRENT_DD_VERSION=${{ env.VER }}"
I'd like to create a simple "hello, world" Gitlab CI script. I already got the Docker runner working and I'm experimenting with something like this:
image: debian:sid
test:first:
script:
- true
Unfortunately, the build fails with the error: test:first job: script should be a string or an array of a strings
What am I doing wrong?
After a bit of experimenting, I found the root cause and reported it as a bug. Apparently "true" was evaluated as a boolean here. Adding path to true executable helped solve the problem.
Double-check your spacing on the list lines - specifically that each dash is followed by a space. It can be an easy thing to overlook, especially if the "list" is only a single item.
(Though admittedly, that was not the cause of error in your "Hello world" CI file)