Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-38433

Make declarative pipelines agent section pluggable

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      The agent section in Declarative Pipelines should be pluggable, so that we can have multiple implementations with their own logic. Once JENKINS-37011 is done, we'll be able to implement steps that compose other steps, which is what we're going for here.

      So we'll have, e.g., a "label" provider for just running on an agent directly, a "docker" provider for Docker Pipeline, a "kubernetes" provider for the Kubernetes plugin, a "docker-slaves" provider for the Docker Slaves plugin, etc.

        Attachments

          Activity

          abayer Andrew Bayer created issue -
          Hide
          jglick Jesse Glick added a comment -

          A Step, which is what JENKINS-37011 would provide an alternate way of writing, is something that would appear under Snippetizer and be available for inclusion as an item in a declarative stage, as well as anywhere in Pipeline Script. That does not seem at all appropriate here. I think what you want is more like

          public abstract class AgentKind extends AbstractDescribableImpl<AgentKind> implements ExtensionPoint {
            public abstract URL groovyImplementation();
            @Override public AgentKindDescriptor getDescriptor() {return (AgentKindDescriptor) super.getDescriptor();}
          }
          public abstract class AgentKindDescriptor extends Descriptor<AgentKind> {
            protected AgentKindDescriptor() {super(); check();}
            protected AgentKindDescriptor(Class<? extends AgentKind> clazz) {super(clazz); check();}
            private void check() {if (SymbolLookup.getSymbolValue(this).isEmpty()) throw new IllegalStateException("add @Symbol");}
          }
          

          You also want some kind of configuration UI, though my understanding was that this would come from B.O. and so the Describable part might not be desirable—you could have a naked ExtensionPoint if there is no need to provide config snippets in classic Jenkins UI.

          The handler of the image syntax needs to load the supplied implementation in a CPS-transformed shell and runs it. Now perhaps that would be made easier to implement by a certain amount of shared utility methods from JENKINS-37011, but that is a different matter. You do not strictly need anything more than

          String symbol = …;
          Map<String,String> args = …;
          Closure body = {…};
          String groovyImplementation = SomeUtilities.findAgentKindImplementation(symbol);
          def function = evaluate(groovyImplementation);
          function(args, body);
          

          assuming the implementation does not need to be trusted code—and for this purpose I think it does not: none would just be

          {args, body -> node {body()}}
          

          label would be

          {args, body -> node(args.name) {body()}}
          

          and docker would be

          {args, body -> node(args.label) {docker.image(args.image).inside {body()}}}
          

          Now if you want to parse structured arguments then that is a bit trickier; we would need to extract some of the stuff in DSL and Snippetizer into other utilities if you were using classic Jenkins UI, or some other system TBD if using B.O.

          Show
          jglick Jesse Glick added a comment - A Step , which is what JENKINS-37011 would provide an alternate way of writing, is something that would appear under Snippetizer and be available for inclusion as an item in a declarative stage , as well as anywhere in Pipeline Script. That does not seem at all appropriate here. I think what you want is more like public abstract class AgentKind extends AbstractDescribableImpl<AgentKind> implements ExtensionPoint { public abstract URL groovyImplementation(); @Override public AgentKindDescriptor getDescriptor() { return (AgentKindDescriptor) super .getDescriptor();} } public abstract class AgentKindDescriptor extends Descriptor<AgentKind> { protected AgentKindDescriptor() { super (); check();} protected AgentKindDescriptor( Class <? extends AgentKind> clazz) { super (clazz); check();} private void check() { if (SymbolLookup.getSymbolValue( this ).isEmpty()) throw new IllegalStateException( "add @Symbol" );} } You also want some kind of configuration UI, though my understanding was that this would come from B.O. and so the Describable part might not be desirable—you could have a naked ExtensionPoint if there is no need to provide config snippets in classic Jenkins UI. The handler of the image syntax needs to load the supplied implementation in a CPS-transformed shell and runs it. Now perhaps that would be made easier to implement by a certain amount of shared utility methods from JENKINS-37011 , but that is a different matter. You do not strictly need anything more than String symbol = …; Map< String , String > args = …; Closure body = {…}; String groovyImplementation = SomeUtilities.findAgentKindImplementation(symbol); def function = evaluate(groovyImplementation); function(args, body); assuming the implementation does not need to be trusted code—and for this purpose I think it does not: none would just be {args, body -> node {body()}} label would be {args, body -> node(args.name) {body()}} and docker would be {args, body -> node(args.label) {docker.image(args.image).inside {body()}}} Now if you want to parse structured arguments then that is a bit trickier; we would need to extract some of the stuff in DSL and Snippetizer into other utilities if you were using classic Jenkins UI, or some other system TBD if using B.O.
          abayer Andrew Bayer made changes -
          Field Original Value New Value
          Status Open [ 1 ] In Progress [ 3 ]
          Hide
          abayer Andrew Bayer added a comment -

          So without actually having read this comment, I ended up getting fairly far along in something similar today. heh. I am currently putting the CPS-transformed code in separate classes a la Docker.groovy and friends, but that may make sense to change towards what you laid out in the future. No big deal either way.

          Right now, the problem I'm having is a UX problem rather than an implementation problem - well, not that level of implementation, at least. How can I tell that agent label:'foo', docker:'bar' means "Use the Docker Pipeline agent implementation and not the label agent implementation"? Ok, that particular one is simple enough on the face of it - there's a docker key, so therefore... - but when we allow extensions to have any arbitrary key, how do we know that docker here means "Docker Pipeline" and not "Some other Docker implementation"?

          I can think of at least one way to handle this, but it breaks existing syntax and has a couple different ways we could actually format the syntax:

          agent docker: [label:'foo', image:'bar']
          // or docker:'bar' instead of image if we want to keep that consistent from the current syntax)
          
          // or
          
          agent docker {
              label 'foo'
              image 'bar'
          }
          
          // or
          
          agent {
              docker {
                  label 'foo'
                  image 'bar'
              }
          }
          

          In all cases, the top-level key docker corresponds to a Symbol on the descriptor for the Docker Pipeline implementation.

          Michael Neale, Stephen Connolly, Patrick Wolf, James Dumay, rsandell - thoughts on compatibility-breaking like this?

          Show
          abayer Andrew Bayer added a comment - So without actually having read this comment, I ended up getting fairly far along in something similar today. heh. I am currently putting the CPS-transformed code in separate classes a la Docker.groovy and friends, but that may make sense to change towards what you laid out in the future. No big deal either way. Right now, the problem I'm having is a UX problem rather than an implementation problem - well, not that level of implementation, at least. How can I tell that agent label:'foo', docker:'bar' means "Use the Docker Pipeline agent implementation and not the label agent implementation"? Ok, that particular one is simple enough on the face of it - there's a docker key, so therefore... - but when we allow extensions to have any arbitrary key, how do we know that docker here means "Docker Pipeline" and not "Some other Docker implementation"? I can think of at least one way to handle this, but it breaks existing syntax and has a couple different ways we could actually format the syntax: agent docker: [label: 'foo' , image: 'bar' ] // or docker: 'bar' instead of image if we want to keep that consistent from the current syntax) // or agent docker { label 'foo' image 'bar' } // or agent { docker { label 'foo' image 'bar' } } In all cases, the top-level key docker corresponds to a Symbol on the descriptor for the Docker Pipeline implementation. Michael Neale , Stephen Connolly , Patrick Wolf , James Dumay , rsandell - thoughts on compatibility-breaking like this?
          Hide
          abayer Andrew Bayer added a comment -

          A couple things I forgot to mention:

          • none and any would still look the same in any of the scenarios. If the argument to agent isn't a Map or a method call, i.e., no args, it'll just look up the appropriate symbol.
          • It's theoretically possible that I could rig in compatibility with the existing syntax - with the new syntax working for any implementation (replacements for the current functionality and new ones/improvements of the existing ones) but any new ones or improvements to the existing ones would require using the new syntax. But I'd prefer to just junk the old syntax support entirely if we're going to change going forward - we're pre-1.0, after all!
          Show
          abayer Andrew Bayer added a comment - A couple things I forgot to mention: none and any would still look the same in any of the scenarios. If the argument to agent isn't a Map or a method call, i.e., no args, it'll just look up the appropriate symbol. It's theoretically possible that I could rig in compatibility with the existing syntax - with the new syntax working for any implementation (replacements for the current functionality and new ones/improvements of the existing ones) but any new ones or improvements to the existing ones would require using the new syntax. But I'd prefer to just junk the old syntax support entirely if we're going to change going forward - we're pre-1.0, after all!
          Hide
          abayer Andrew Bayer added a comment -

          Oh yeah! One other possibility:

          agent docker(label:'foo', image:'bar')
          
          // or
          
          agent docker label:'foo', image:'bar'
          

          Since the individual implementations are Describable, I can treat instantiating them like I do with job properties. This approach might make it more clear that you can only have one agent implementation, where the map or closure approaches might confuse people and make them think you can have multiple.

          Show
          abayer Andrew Bayer added a comment - Oh yeah! One other possibility: agent docker(label: 'foo' , image: 'bar' ) // or agent docker label: 'foo' , image: 'bar' Since the individual implementations are Describable , I can treat instantiating them like I do with job properties. This approach might make it more clear that you can only have one agent implementation, where the map or closure approaches might confuse people and make them think you can have multiple.
          Hide
          pleibiger Peter Leibiger added a comment -

          I like the extra image parameter, would go well with an args parameter for the current dockerArgs.

          agent docker label:'foo', image:'bar', args:'-v /foo:/bar -p 90:80'
          
          Show
          pleibiger Peter Leibiger added a comment - I like the extra image parameter, would go well with an args parameter for the current dockerArgs . agent docker label: 'foo' , image: 'bar' , args: '-v /foo:/bar -p 90:80'
          Hide
          abayer Andrew Bayer added a comment -

          Peter Leibiger So is that the syntax that feels best for you?

          Show
          abayer Andrew Bayer added a comment - Peter Leibiger So is that the syntax that feels best for you?
          Hide
          rsandell rsandell added a comment -

          With my latest change the docker label would be optional, so it could be slightly closer to what we have now.

          agent docker 'foo'

          or with named parameters

          agent docker image: 'foo', args: '-v /foo:/bar -p 90:80'

          Show
          rsandell rsandell added a comment - With my latest change the docker label would be optional, so it could be slightly closer to what we have now. agent docker 'foo' or with named parameters agent docker image: 'foo', args: '-v /foo:/bar -p 90:80'
          Hide
          jglick Jesse Glick added a comment -

          when we allow extensions to have any arbitrary key, how do we know that docker here means "Docker Pipeline" and not "Some other Docker implementation"?

          Well in general extensions need to be written coöperatively so they do not clash. That applies to @Symbol too.

          Anyway agent label:'foo', docker:'bar' is compatible with a modularized system so long as you design the extension point appropriately:

          public abstract class AgentKind implements ExtensionPoint {
            public abstract boolean handles(@Nonnull Map<String,String> arguments);
            public abstract @Nonnull URL groovyImplementation();
          }
          

          where the DockerAgentKind would simply have a higher ordinal than the LabelAgentKind, which in turn would have a higher ordinal than the AnyAgentKind.

          Show
          jglick Jesse Glick added a comment - when we allow extensions to have any arbitrary key, how do we know that docker here means "Docker Pipeline" and not "Some other Docker implementation"? Well in general extensions need to be written coöperatively so they do not clash. That applies to @Symbol too. Anyway agent label:'foo', docker:'bar' is compatible with a modularized system so long as you design the extension point appropriately: public abstract class AgentKind implements ExtensionPoint { public abstract boolean handles(@Nonnull Map< String , String > arguments); public abstract @Nonnull URL groovyImplementation(); } where the DockerAgentKind would simply have a higher ordinal than the LabelAgentKind , which in turn would have a higher ordinal than the AnyAgentKind .
          Hide
          pleibiger Peter Leibiger added a comment -

          Andrew Bayer Yes, I would say so.

          Show
          pleibiger Peter Leibiger added a comment - Andrew Bayer Yes, I would say so.
          Hide
          abayer Andrew Bayer added a comment -

          Ok, I've just about got the agent label: 'foo', docker: 'bar' syntax working. It does lead to one caveat - we can't introduce any bare indicators like none and any outside of this plugin itself.

          Show
          abayer Andrew Bayer added a comment - Ok, I've just about got the agent label: 'foo', docker: 'bar' syntax working. It does lead to one caveat - we can't introduce any bare indicators like none and any outside of this plugin itself.
          Hide
          michaelneale Michael Neale added a comment -

          Andrew Bayer ok so I am not quite sure what you got up to here (there are no tests/examples in the PR at least that I could see so not 100% sure).

          named parameters seem to make sense. What about an executor that takes more config than may easily fit in a named parameter? Or will they always take named parameters (but one of them may be a config map specific to that type of agent plugin?)

          So in the simplest case of label:

          agent label:"foo"

          Right?

          Then docker:

          agent docker:'image name' (optional label:'executor label here') - based on your last comment (although that doesnt' have an explicit image which Peter suggests is nice).

          Show
          michaelneale Michael Neale added a comment - Andrew Bayer ok so I am not quite sure what you got up to here (there are no tests/examples in the PR at least that I could see so not 100% sure). named parameters seem to make sense. What about an executor that takes more config than may easily fit in a named parameter? Or will they always take named parameters (but one of them may be a config map specific to that type of agent plugin?) So in the simplest case of label: agent label:"foo" Right? Then docker: agent docker:'image name' (optional label:'executor label here') - based on your last comment (although that doesnt' have an explicit image which Peter suggests is nice).
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Andrew Bayer
          Path:
          pipeline-model-declarative-agent/pom.xml
          pipeline-model-declarative-agent/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/DeclarativeAgent.java
          pipeline-model-declarative-agent/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/DeclarativeAgentDescriptor.java
          pipeline-model-declarative-agent/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/DeclarativeAgentScript.java
          pipeline-model-definition/pom.xml
          pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Agent.groovy
          pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Root.groovy
          pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/validator/ModelValidatorImpl.groovy
          pipeline-model-definition/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/Any.java
          pipeline-model-definition/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/DockerPipeline.java
          pipeline-model-definition/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/Label.java
          pipeline-model-definition/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/None.java
          pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ClosureModelTranslator.groovy
          pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ModelInterpreter.groovy
          pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/DockerPipelineScript.groovy
          pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/LabelScript.groovy
          pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/NoneScript.groovy
          http://jenkins-ci.org/commit/pipeline-model-definition-plugin/d07730e7939fee12e9c287a0537e67570edf52c9
          Log:
          JENKINS-38433 Make the agent section pluggable.

          This is very preliminary - I expect a lot more iteration. But it
          works. The DeclarativeAgent* classes are in a separate plugin so that
          they can be depended on by other plugins with minimal transitive
          dependencies in the process (just workflow-cps-plugin currently - may
          try to find a way to narrow that down further).

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: pipeline-model-declarative-agent/pom.xml pipeline-model-declarative-agent/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/DeclarativeAgent.java pipeline-model-declarative-agent/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/DeclarativeAgentDescriptor.java pipeline-model-declarative-agent/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/DeclarativeAgentScript.java pipeline-model-definition/pom.xml pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Agent.groovy pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Root.groovy pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/validator/ModelValidatorImpl.groovy pipeline-model-definition/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/Any.java pipeline-model-definition/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/DockerPipeline.java pipeline-model-definition/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/Label.java pipeline-model-definition/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/None.java pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ClosureModelTranslator.groovy pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ModelInterpreter.groovy pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/DockerPipelineScript.groovy pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/LabelScript.groovy pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/NoneScript.groovy http://jenkins-ci.org/commit/pipeline-model-definition-plugin/d07730e7939fee12e9c287a0537e67570edf52c9 Log: JENKINS-38433 Make the agent section pluggable. This is very preliminary - I expect a lot more iteration. But it works. The DeclarativeAgent* classes are in a separate plugin so that they can be depended on by other plugins with minimal transitive dependencies in the process (just workflow-cps-plugin currently - may try to find a way to narrow that down further).
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Andrew Bayer
          Path:
          pipeline-model-api/pom.xml
          pipeline-model-declarative-agent/pom.xml
          pipeline-model-declarative-agent/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/DeclarativeAgent.java
          pipeline-model-declarative-agent/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/DeclarativeAgentDescriptor.java
          pipeline-model-declarative-agent/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/DeclarativeAgentScript.java
          pipeline-model-definition/pom.xml
          pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Agent.groovy
          pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Root.groovy
          pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Stage.groovy
          pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/validator/ModelValidatorImpl.groovy
          pipeline-model-definition/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/Any.java
          pipeline-model-definition/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/DockerPipeline.java
          pipeline-model-definition/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/Label.java
          pipeline-model-definition/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/None.java
          pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ClosureModelTranslator.groovy
          pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ModelInterpreter.groovy
          pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/DockerPipelineScript.groovy
          pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/LabelScript.groovy
          pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/NoneScript.groovy
          pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/AbstractModelDefTest.java
          pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/AgentTest.java
          pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/ValidatorTest.java
          pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/LabelAndOtherFieldAgent.java
          pipeline-model-definition/src/test/resources/agentAnyInStage.groovy
          pipeline-model-definition/src/test/resources/agentTypeOrdering.groovy
          pipeline-model-definition/src/test/resources/errors/agentMissingRequiredParam.groovy
          pipeline-model-definition/src/test/resources/errors/agentUnknownParamForType.groovy
          pipeline-model-definition/src/test/resources/errors/unknownAgentType.groovy
          pipeline-model-definition/src/test/resources/errors/unknownBareAgentType.groovy
          pipeline-model-definition/src/test/resources/json/agentTypeOrdering.json
          pipeline-model-definition/src/test/resources/json/errors/agentMissingRequiredParam.json
          pipeline-model-definition/src/test/resources/json/errors/agentUnknownParamForType.json
          pipeline-model-definition/src/test/resources/json/errors/unknownAgentType.json
          pipeline-model-definition/src/test/resources/json/errors/unknownBareAgentType.json
          pipeline-model-definition/src/test/resources/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/LabelAndOtherFieldAgentScript.groovy
          pom.xml
          http://jenkins-ci.org/commit/pipeline-model-definition-plugin/9e9b0bbb67f8417e458672e6c70a49b989a062fa
          Log:
          Merge pull request #35 from abayer/pluggable-agent

          JENKINS-38433 Make the agent section pluggable.

          Compare: https://github.com/jenkinsci/pipeline-model-definition-plugin/compare/83a83f675427...9e9b0bbb67f8

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: pipeline-model-api/pom.xml pipeline-model-declarative-agent/pom.xml pipeline-model-declarative-agent/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/DeclarativeAgent.java pipeline-model-declarative-agent/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/DeclarativeAgentDescriptor.java pipeline-model-declarative-agent/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/DeclarativeAgentScript.java pipeline-model-definition/pom.xml pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Agent.groovy pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Root.groovy pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Stage.groovy pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/validator/ModelValidatorImpl.groovy pipeline-model-definition/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/Any.java pipeline-model-definition/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/DockerPipeline.java pipeline-model-definition/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/Label.java pipeline-model-definition/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/None.java pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ClosureModelTranslator.groovy pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ModelInterpreter.groovy pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/DockerPipelineScript.groovy pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/LabelScript.groovy pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/NoneScript.groovy pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/AbstractModelDefTest.java pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/AgentTest.java pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/ValidatorTest.java pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/LabelAndOtherFieldAgent.java pipeline-model-definition/src/test/resources/agentAnyInStage.groovy pipeline-model-definition/src/test/resources/agentTypeOrdering.groovy pipeline-model-definition/src/test/resources/errors/agentMissingRequiredParam.groovy pipeline-model-definition/src/test/resources/errors/agentUnknownParamForType.groovy pipeline-model-definition/src/test/resources/errors/unknownAgentType.groovy pipeline-model-definition/src/test/resources/errors/unknownBareAgentType.groovy pipeline-model-definition/src/test/resources/json/agentTypeOrdering.json pipeline-model-definition/src/test/resources/json/errors/agentMissingRequiredParam.json pipeline-model-definition/src/test/resources/json/errors/agentUnknownParamForType.json pipeline-model-definition/src/test/resources/json/errors/unknownAgentType.json pipeline-model-definition/src/test/resources/json/errors/unknownBareAgentType.json pipeline-model-definition/src/test/resources/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/LabelAndOtherFieldAgentScript.groovy pom.xml http://jenkins-ci.org/commit/pipeline-model-definition-plugin/9e9b0bbb67f8417e458672e6c70a49b989a062fa Log: Merge pull request #35 from abayer/pluggable-agent JENKINS-38433 Make the agent section pluggable. Compare: https://github.com/jenkinsci/pipeline-model-definition-plugin/compare/83a83f675427...9e9b0bbb67f8
          abayer Andrew Bayer made changes -
          Resolution Fixed [ 1 ]
          Status In Progress [ 3 ] Resolved [ 5 ]
          Hide
          bitwiseman Liam Newman added a comment -

          Bulk closing resolved issues.

          Show
          bitwiseman Liam Newman added a comment - Bulk closing resolved issues.
          bitwiseman Liam Newman made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            Assignee:
            abayer Andrew Bayer
            Reporter:
            abayer Andrew Bayer
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: