nolange79 also, since this bug report is about the git step and not the checkout step, it would be better to use a different location for your question and for the answer to your question. When you ask a question in an issue, you limit the number of people that will answer the question to only those that are monitoring that bug. A question asked in the Jenkins mailing lists or the Jenkins chat channels can be seen by a much larger group.

Yeah, I posted the entire declarative pipeline couple posts before.

I managed to get the variables with a script block, but I expected that there would be a way to get to this without breaking into scripting mode.

What is a default checkout: where would the pipeline know the url from?
Does withCheckout exist? its referenced in this thread.
Would be nice to get withEnv working like I illustrated above.

Docs send you completely in the wrong direction unfortunately.

Edit: I replied here because this is often referenced as "answer"

I managed to get the variables with a script block, but I expected that there would be a way to get to this without breaking into scripting mode.

The variables are available if you don't use the checkout step in the declarative pipeline. The declarative pipeline has an implicit checkout step that happens before the Pipeline executes.

What is a default checkout: where would the pipeline know the url from?

When the Jenkinsfile for the Pipeline is read from SCM, the declarative pipeline uses that URL.

Does withCheckout exist? its referenced in this thread.

No, withCheckout does not exist. It was added to the scm step plugin May 5, 2017 and then removed on May 16, 2017.

Docs send you completely in the wrong direction unfortunately.

Which docs send you in the wrong direction?

"Which docs send you in the wrong direction?"

Plain Pipelines using "inline Jenkinsfiles" seem to be largely ignored from all docs, similarly you often need to checkout multiple sources. If this is not explicitly mentioned, one would assume it works the same.
The step returns a map of env variables already, so pushing those into withEnv would be a natural fit.

That there is no "declarative" way to do this, is weird. I had many Problems with scripted pipelines, particularly when it comes to error handling (storing artifacts will silently fail, then cause an error at the end of the pipeline?) that I would want to stay clear of those.