Open cvakiitho opened 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
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.
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.
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:
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>
FYI - In the meantime I've added #12 and #13 to at least make this case more friendly
On second thought - there might be a way to exploit the replay feature to achieve this
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?