dave-hagedorn / jenkins-runner

VS Code plugin to develop and run Jenkins Pipeline scripts
MIT License
30 stars 8 forks source link

Pipeline from SCM #11

Open cvakiitho opened 5 years ago

cvakiitho commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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:

image

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:

image

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:

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="workflow-job@2.31">
  <actions>
    <org.jenkinsci.plugins.pipeline.modeldefinition.actions.DeclarativeJobAction plugin="pipeline-model-definition@1.3.4.1"/>
    <org.jenkinsci.plugins.pipeline.modeldefinition.actions.DeclarativeJobPropertyTrackerAction plugin="pipeline-model-definition@1.3.4$
      <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="workflow-cps@2.61.1">
    <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="workflow-multibranch@2.20">
  <properties/>
  <folderViews class="jenkins.branch.MultiBranchProjectViewHolder" plugin="branch-api@2.1.2">
    <owner class="org.jenkinsci.plugins.workflow.multibranch.WorkflowMultiBranchProject" reference="../.."/>
  </folderViews>
  <healthMetrics>
    <com.cloudbees.hudson.plugins.folder.health.WorstChildHealthMetric plugin="cloudbees-folder@6.7">
      <nonRecursive>false</nonRecursive>
    </com.cloudbees.hudson.plugins.folder.health.WorstChildHealthMetric>
  </healthMetrics>
  <icon class="jenkins.branch.MetadataActionFolderIcon" plugin="branch-api@2.1.2">
    <owner class="org.jenkinsci.plugins.workflow.multibranch.WorkflowMultiBranchProject" reference="../.."/>
  </icon>
  <orphanedItemStrategy class="com.cloudbees.hudson.plugins.folder.computed.DefaultOrphanedItemStrategy" plugin="cloudbees-folder@6.7">
    <pruneDeadBranches>true</pruneDeadBranches>
    <daysToKeep>-1</daysToKeep>
    <numToKeep>-1</numToKeep>
  </orphanedItemStrategy>
  <triggers/>
  <disabled>false</disabled>
  <sources class="jenkins.branch.MultiBranchProject$BranchSourceList" plugin="branch-api@2.1.2">
    <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 commented 5 years ago

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

dave-hagedorn commented 5 years ago

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