-
Improvement
-
Resolution: Fixed
-
Major
-
None
For JENKINS-40370, we'll be doing new syntax for when. Given certain similarities to agent, it makes sense to have a common look and feel to the two sections' syntax, and we already had an interest in making the agent syntax more flexible going forward, so let's move from
agent label: 'foo'
to
agent {
label 'foo'
}
We'll still support agent none and agent any, since they're useful shortcuts that we've already got special logic for.
- is blocking
-
JENKINS-39684 Use docker images from private registry
-
- Closed
-
-
JENKINS-40915 update help message on docker label in config
-
- Closed
-
- links to
[JENKINS-40524] Rework agent syntax to be more extensible
| Epic Link |
New:
|
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
| Status | Original: In Progress [ 3 ] | New: In Review [ 10005 ] |
| Remote Link | New: This issue links to "PR #73 (Web Link)" [ 15141 ] |
So I'd really like to get some feedback on two possible syntax approaches - I'm fine with either one, so I need input. =)
First, which is what's currently in the PR:
agent {
label "foo"
}
agent {
docker "httpd:2.4.12"
dockerArgs "-v /tmp:/tmp -p 80:80"
label "foo"
// the below would be for things like private registry, kubernetes pod config, whatever
someComplicatedOption {
optA "banana"
optB "monkey"
}
}
agent {
dockerfile "true"
dockerArgs "-v /tmp:/tmp -p 80:80"
label "foo"
}
Second:
agent {
// i.e., DeclarativeAgent types with only one required argument and only one specified argument don't need the nested block
label "foo"
}
agent {
// Also would work with 'docker "httpd:2.4.12"' if the image is the only desired argument
docker {
image "httpd:2.4.12"
args "-v /tmp:/tmp -p 80:80"
label "foo"
// the below would be for things like private registry, kubernetes pod config, whatever
someComplicatedOption {
optA "banana"
optB "monkey"
}
}
agent {
// Also would work with 'dockerfile true' as above
dockerfile {
args "-v /tmp:/tmp -p 80:80"
label "foo"
}
}
And of course, agent any and agent none will still be working.
Thoughts, hrmpw, michaelneale, jamesdumay, rsandell, herau, imod, lsglick, pleibiger?
Logan Glickfield
added a comment - I'm a fan of option 2.
The first option leaves some confusion as to what exactly label means. It's unclear to me whether it will prefer an existing labeled node and fall back to docker, or whether it will always create a new docker node and just apply that label. The second provides some clarity that the label is just an attribute of the docker/dockerfile nodes.
Logan Glickfield
added a comment - I'm a fan of option 2.
The first option leaves some confusion as to what exactly label means. It's unclear to me whether it will prefer an existing labeled node and fall back to docker, or whether it will always create a new docker node and just apply that label. The second provides some clarity that the label is just an attribute of the docker/dockerfile nodes. question abayer
the second example in the second option
agent {
// Also would work with 'docker "httpd:2.4.12"' if the image is the only desired argument
docker {
image "httpd:2.4.12"
args "-v /tmp:/tmp -p 80:80"
label "foo"
// the below would be for things like private registry, kubernetes pod config, whatever
someComplicatedOption {
optA "banana"
optB "monkey"
}
}
What does label refer to? Is that the agent label or the container label? Would this be supported?
agent {
label "nodename"
docker {
image "httpd:2.4.12"
args "-v /tmp:/tmp -p 80:80"
label "foo"
// the below would be for things like private registry, kubernetes pod config, whatever
someComplicatedOption {
optA "banana"
optB "monkey"
}
}
hrmpw - no, the second would not be possible. label inside docker or dockerfile would be equivalent to label 'foo' - i.e., which agent to run on in the first place.
PR up at https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/73