Pipeline from SCM

[cvakiitho]

trafficstars

I'm not sure if that is even possible, however, it seems to me that you can't really use this plugin on pipelines defined in SCM. it can run the job, gather errors,.., but it doesn't run version from VSCODE, but version from SCM.

You can alter the job pipeline via retry in jenkins, so maybe it is supported in the API?

[cvakiitho]

As a workaround you need to set your scratch job to be just a pipeline job ( no pipeline from SCM), and rewrite your checkout scm to checkout([$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [[url: '<your checkout repo>']]])

maybe that's actually the preferred way anyway...

anyways, this plugin is sooo good, I finally don't have to git add; git commit --ammend --edit;git push -f every time I'm working with pipelines...(or use that small shitty html editor in jenkins). I just needed to write this somewhere. Kudos

[dave-hagedorn]

Haha - thanks. Yeah, the git add; ... "solution" got to me enough times... hence this.

You're right - the plugin only supports regular pipeline jobs - it works by modifying the script in the job's config (as you would in the job's config page).

I take it you want to have Jenkins checkout your sources like normal, but then write the Jenkinsfile in vscode? Not sure if this is possible in Jenkins, but I'll take a look.

[cvakiitho]

I take it you want to have Jenkins checkout your sources like normal, but then write the Jenkinsfile in vscode? Not sure if this is possible in Jenkins, but I'll take a look.

Exactly, 99% of our pipelines are inside repos with code you need to have to run the pipeline, so we always have checkout scm in it.

[dave-hagedorn]

The more I think about this, the more it seems to be impossible via Jenkins alone

The config for a multi-branch pipeline job can only use a Jenkinsfile from SCM:

There's no way for this plugin to inject a Jenkinsfile into the project's config, which is how this plugin works for a normal Pipeline job:

I dug through the Jenkins multi-branch pipeline plugin's sources, and couldn't find any hints there either.

I could see something completely different where:

• the plugin uses a branch you configure, in a repo that is used by a multibranch project
• you also tell the plugin what Jenkins multi-branch project uses that same repo
• on "run script", the plugin would commit the Jenkinsfile back to the repo, and kick the Jenkins job to rebuild the now-updated Jenkinsfile in that repo's branch

That's dealing with repo access outside Jenkins though - could be SVN, GIt, etc. Not sure if that's a good approach or not.

For now I would recommend your workaround - make a test pipeline job and using that to develop your pipeline script. When you're happy with your script, you can move it back to your multi-branch pipeline job.

For now, I can at least update the docs to describe this workaround, and have the plugin warn if you try to use it on a multi-branch job

More info:

The internal job config for a pipeline job allows specifying the pipeline script:

<?xml version='1.1' encoding='UTF-8'?>
<flow-definition plugin="[email protected]">
  <actions>
    <org.jenkinsci.plugins.pipeline.modeldefinition.actions.DeclarativeJobAction plugin="[email protected]"/>
    <org.jenkinsci.plugins.pipeline.modeldefinition.actions.DeclarativeJobPropertyTrackerAction plugin="[email protected]$
      <jobProperties/>
      <triggers/>
      <parameters>
        <string>message</string>
      </parameters>
      <options/>
    </org.jenkinsci.plugins.pipeline.modeldefinition.actions.DeclarativeJobPropertyTrackerAction>
  </actions>
  <description></description>
  <keepDependencies>false</keepDependencies>
  <properties>
    <hudson.model.ParametersDefinitionProperty>
      <parameterDefinitions>
        <hudson.model.StringParameterDefinition>
          <name>message</name>
          <description></description>
          <defaultValue>Default</defaultValue>
          <trim>false</trim>
        </hudson.model.StringParameterDefinition>
      </parameterDefinitions>
    </hudson.model.ParametersDefinitionProperty>
  </properties>
  <definition class="org.jenkinsci.plugins.workflow.cps.CpsFlowDefinition" plugin="[email protected]">
    <script>
echo env.PWD</script>
    <sandbox>true</sandbox>
  </definition>
  <triggers/>
  <quietPeriod>0</quietPeriod>
  <disabled>false</disabled>
</flow-definition>

But not for a multi-branch project

?xml version='1.1' encoding='UTF-8'?>
<org.jenkinsci.plugins.workflow.multibranch.WorkflowMultiBranchProject plugin="[email protected]">
  <properties/>
  <folderViews class="jenkins.branch.MultiBranchProjectViewHolder" plugin="[email protected]">
    <owner class="org.jenkinsci.plugins.workflow.multibranch.WorkflowMultiBranchProject" reference="../.."/>
  </folderViews>
  <healthMetrics>
    <com.cloudbees.hudson.plugins.folder.health.WorstChildHealthMetric plugin="[email protected]">
      <nonRecursive>false</nonRecursive>
    </com.cloudbees.hudson.plugins.folder.health.WorstChildHealthMetric>
  </healthMetrics>
  <icon class="jenkins.branch.MetadataActionFolderIcon" plugin="[email protected]">
    <owner class="org.jenkinsci.plugins.workflow.multibranch.WorkflowMultiBranchProject" reference="../.."/>
  </icon>
  <orphanedItemStrategy class="com.cloudbees.hudson.plugins.folder.computed.DefaultOrphanedItemStrategy" plugin="[email protected]">
    <pruneDeadBranches>true</pruneDeadBranches>
    <daysToKeep>-1</daysToKeep>
    <numToKeep>-1</numToKeep>
  </orphanedItemStrategy>
  <triggers/>
  <disabled>false</disabled>
  <sources class="jenkins.branch.MultiBranchProject$BranchSourceList" plugin="[email protected]">
    <data/>
    <owner class="org.jenkinsci.plugins.workflow.multibranch.WorkflowMultiBranchProject" reference="../.."/>
  </sources>
  <factory class="org.jenkinsci.plugins.workflow.multibranch.WorkflowBranchProjectFactory">
    <owner class="org.jenkinsci.plugins.workflow.multibranch.WorkflowMultiBranchProject" reference="../.."/>
    <scriptPath>Jenkinsfile</scriptPath>
  </factory>
</org.jenkinsci.plugins.workflow.multibranch.WorkflowMultiBranchProject>

[dave-hagedorn]

FYI - In the meantime I've added #12 and #13 to at least make this case more friendly

[dave-hagedorn]

On second thought - there might be a way to exploit the replay feature to achieve this