Hi @Rowat G@ADM(DS) DEIMS@Defence365 ,
Thank you for your question.
The behavior you are seeing is related to how the Azure Pipelines agent receives environment variables. Variables configured in /etc/environment or ~/.bashrc are not necessarily available to pipeline tasks because the agent is not launched through an interactive/PAM login shell.
Also, any export commands executed inside Setup.sh apply only to that script's current shell session. Once the provisioning script completes, those exported values do not automatically persist into the environment used by subsequent pipeline tasks.
A possible approach is to make the required variables available through the agent's .env file.
For example:
Shell
AGENT_ROOT="<path to the agent folder on the pool VM>"
cat >> "$AGENT_ROOT/.env" <<'EOF'
JAVA_HOME=/usr/lib/jvm/java-25-openjdk-amd64
JAVA_HOME_25_X64=/usr/lib/jvm/java-25-openjdk-amd64
JAVA_HOME_21_X64=/usr/lib/jvm/java-21-openjdk-amd64
JAVA_HOME_17_X64=/usr/lib/jvm/java-17-openjdk-amd64
JAVA_HOME_11_X64=/usr/lib/jvm/java-11-openjdk-amd64
TARGETARCH=linux-x64
EOF
Before implementing this, I recommend confirming the actual agent directory on the pool VM. You can use a diagnostic pipeline to check the agent location, for example:
Shell
ps -ef | grep -i Agent.Listener
echo $(Agent.HomeDirectory)
The timing is also important. The .env file needs to be available when the agent starts. Therefore, if your provisioning script executes before the agent directory is created, writing the file at that stage may not have the expected result.
After making the change, ensure that the agent restarts so that it can pick up the updated environment. Since you are already using provisioningScriptShouldRestart:`` ``true, the restart following provisioning may help with this.
You can then validate what is available to the pipeline using:
YAML
steps:
- script: |
printenv | grep -E 'JAVA_HOME|TARGETARCH'
displayName: Check env
- task: JavaToolInstaller@1
inputs:
versionSpec: '21'
jvmType: 'x64'
jdkArchitectureOption: 'x64'
jdkSourceOption: 'PreInstalled'
For JavaToolInstaller@1 with PreInstalled, please make sure the appropriate version-specific variable, such as JAVA_HOME_21_X64, is available to the task environment.
If the .env approach does not work as expected with Managed DevOps Pools, an alternative would be to define these variables through a common YAML template or variable group shared by the relevant pipelines.
For additional information, please refer to:
Azure Pipelines Linux agent documentation
JavaToolInstaller@1 documentation
I would suggest testing this with one pool first and validating the variables from a pipeline before applying the same approach more broadly.