Same issue.

Debian 10

Jenkins 2.319.2

Code:

APP = sh(script: 'git tag --contain', returnStdout: true )
app.push("${APP}")

If print "APP" variable, i get "1.4.2".

If replay Job with the code:
app.push("1.4.2")

It works fine.

rameshar I think it would help a lot if you included the part of your Jenkinsfile that causes this issue to appear. There's not enough here to diagnose the problem.

fbisso: Is there any chance that sh call is including a newline or similar in the output? If you replay with the variable literally set to "1.4.2", i.e.

APP = "1.4.2"
app.push("${APP}")

does it still reproduce? The string "1.4.2" does not contain a tag (no :), so the existing code would never have reached the line where it reports "Tag must follow the pattern". (Edit: I had overlooked that push in docker-workflow-plugin tags a tag name, not a repository name, and builds the full image name from it.)

If anything, I suspect the issue here would lie in docker-workflow-plugin, because that's where all the string manipulations are, based on the stack trace in the description. I wonder if something in that stack is somehow failing to interpolate the g-string before it gets to Java, and so the Java code is seeing literally some-image-name:${APP}.

As another test for fbisso's case, what about

app.push(APP)

since APP is already a string.

If that works, but the other variants do not, then that is likely to be the problem, and I'm not sufficiently on-top of Groovy to know at what point that g-string is supposed to be resolved, if not "immediately".

To rule out simple string bugs in docker-workflow-plugin, it'd be handy to log app.id and something like

tokens = new org.jenkinsci.plugins.docker.workflow.ImageNameTokens(app.id)

and log tokens.userAndRepo and tokens.tag, so that all the inputs to push are known.

Thanks for your help.

You was right, the output of the "sh" command had a new line at the end and that was the problem.

I replaced it with

"APP = sh(script: 'git tag --contain | tr -d \'\\n\'', returnStdout: true )"

And it works.

Is it possible that before the update, the call to "push" did the trimming?

Before the update, the trailing newline was being passed all the way through to the shell, but the tagged image name variable was the last thing on the line, so it would have had no effect, as it would have run

docker tag ImageID REALTAG

and

docker push REALTAG

instead of the intended

docker tag ImageID REALTAG

and

docker push REALTAG

This illustrates the security issue that required this change, as a newline in the middle of the tag (or even something like ;) would have allowed the `docker push` to be followed by arbitrary shell commands under the control of the person who defines the tag, who could potentially modify the image and repush it.

For the record, the fix is that the shell command is now literally

docker tag "$JD_ID" "$JD_TAGGED_IMAGE_NAME"

and

docker push "$JD_TAGGED_IMAGE_NAME"

and withEnv is used to populate the JD_ variables so that newlines and other special characters are not handled as shell characters, but are passed right through to the command being run.

So without the regexp check (i.e. before you fixed APP's value, setting the validation mode to SKIP), I expect you'd have had failures from docker itself complaining that \n isn't a valid character in the tag name. (Although docker CLI might strip such things from the end of CLI strings anyway, so it might have just transparently worked in this case.)

I had the same issue on a pipeline job and managed to find a workaround for my use case.

My docker agent was previously getting the tag of the docker image from an environment variable as below:

agent {
    dockerfile {
        image 'trion/ng-cli-karma:${ANGULAR_VERSION}'
    }
}

Since updating all plugins to the latest version, I've been getting the "Tag must follow the pattern '^:[a-zA-Z0-9_]([a-zA-Z0-9_.-]){0,127}'" error message immediately after the git checkout for this stage. I managed to fix it by putting the version directly in the image string:

agent {
    dockerfile {
        image 'trion/ng-cli-karma:11.2.12'
    }
}

I'm not sure if supporting environment variables as tags in the agent image definition is intended or not.

My Jenkins instance is running on docker. 2.319.3-lts-jdk11, with agents running 4.11-1-jdk11

Thank you Paul for your explanation, very clear.

mrussell16: If the environment variable is visible to the Jenkinsfile, i.e. it's not something set on the host outside Jenkins, then this would probably work:

agent {
    dockerfile {
        image "trion/ng-cli-karma:${env.ANGULAR_VERSION}"
    }
}

That way, the ANGULAR_VERSION is interpreted in the Groovy script, and what's sent to the plugin will be the same string your latter solution uses.

That said, I'm not super-familiar with Declarative Pipeline, and you haven't shown how you set that environment variable, so it's possible the env-var was being set after the agent is evaluated, and I don't believe that's supported anymore.

https://stackoverflow.com/q/60376597/166389 suggests that the obvious approach won't actually work in Declarative pipeline. Answers on https://stackoverflow.com/q/46630168/166389 show examples of doing this using Scripted Pipeline to set a Groovy variable before the pipeline block, which might work for your use-case, depending on what controls ANGULAR_VERSION.

Thanks Paul.

Using double quotes and env also works for me. I was declaring the ANGULAR_VERSION in an environment section at the top of the pipeline file.

I ran into this same problem and with the information above was able to get it to work.

We use the current date in our tags and after the upgrades, the jobs were breaking.

Adding a .trim() solved the issue.

DATENOW = sh(script: 'TZ=America/New_York date +"%Y-%m-%d_%H-%M"', returnStdout: true).trim()