[JIRA] (JENKINS-60949) [EnvInject] Injecting properties of previous build breaks SCM polling

[sebastian.ratz@sap.com (JIRA)]

Sebastian Ratz created an issue

Jenkins / JENKINS-60949 [EnvInject] Injecting properties of previous build breaks SCM polling Issue Type: Bug Assignee: Unassigned Components: envinject-plugin Created: 2020-02-03 12:16 Priority: Major Reporter: Sebastian Ratz The EnvInject plugin re-injects the environment of the previous build into the SCM poll for the next build. However, it does this blindly, without considering when and where the previous build happened, and without knowing if the properties are actually applicable. Scenario: Have 2 slaves (slave-linux, slave-windows) Configure job for SCM polling Build job for the first time -> runs on slave-linux** builds/1/injectedEnvVars.txt contains, for example, HOME=/home/jenkins **Wait for next SCM poll. SCM poll runs on slave-windows this time. EnvInject blindly takes the env vars from injectedEnvVars.txt from build 1 and injects it into the SCM polling process. SCM polling on Windows fails, e.g. with "Could not create directory '/home/jenkins/.ssh'." because of the wrong HOME environment variable. Is there a way to prevent this? The job in question does not even make use of the EnvInject functionality, yet, injecting still happens at SCM polling time. Add Comment

This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)

[sebastian.ratz@sap.com (JIRA)]

Sebastian Ratz updated an issue

Jenkins / JENKINS-60949 [EnvInject] Injecting properties of previous build breaks SCM polling

Change By: Sebastian Ratz

The EnvInject plugin re-injects the environment of the previous build into the SCM poll for the next build. However, it does this blindly, without considering when and where the previous build happened, and without knowing if the properties are actually applicable. Scenario:

# Have 2 slaves (*slave-linux*, *slave-windows*) # Configure job for SCM polling # Build job for the first time -> runs on *slave-linux* ** # builds/1/injectedEnvVars.txt contains, for example, *HOME=/home/jenkins* # ** Wait for next SCM poll. # SCM poll runs on *slave-windows* this time. # EnvInject blindly takes the env vars from injectedEnvVars.txt from build 1 and injects it into the SCM polling process. # SCM polling on Windows fails, e.g. with "Could not create directory '/home/jenkins/.ssh'." because of the wrong *HOME* environment variable.

Is there a way to prevent this? The job in question does not even make use of the EnvInject functionality, yet, injecting still happens at SCM polling time.

Add Comment