Any workspace change between LTS 2.138 and 2.150?

[martinda]

Something changed between Jenkins LTS 2.138 and 2.150 with regards to the workspace.

Since LTS 2.150 the workspace set by the external workspace manager plugin is ignored inside: stage, withEnv, withCredentials (and possibly others).

Below is an example. Inside the stage step, the workspace is not the same as immediately outside the stage.

I wrote the actual workspace path returned, beside each line as a comment.

The code below can also be found in https://gist.github.com/martinda/fae71b37dc20bcb0e239ab46de3be291

def extWorkspace
stage('Allocate Workspace') {
    extWorkspace = exwsAllocate 'diskpool1'
}

node() {                  // Running on Jenkins in /localdisk/martin/jenkins/jenkins/workspace/test-exws
    exws(extWorkspace {   // Running in /localdisk/martin/diskpool1/test-exws/8
        sh 'pwd'          // /localdisk/martin/diskpool1/test-exws/8
        stage("Stage") {
            sh 'pwd'      // ??? /localdisk/martin/jenkins/jenkins/workspace/test-exws ???
        }
        sh 'pwd'          // /localdisk/martin/diskpool1/test-exws/8
    }
}

Can someone explain why the inner-most sh step has a different workspace since LTS 2.150?

Thanks,
Martin

[Daniel Beck]

> On 15. Oct 2019, at 14:30, martinda <martin....@gmail.com> wrote:
>
> Can someone explain why the inner-most sh step has a different workspace since LTS 2.150?

Identical versions of plugins between the two?

[martinda]

Excellent question. No they are not. I re-ran my test and carefully made sure I kept track of plugin versions.

Here is what I have found. The LTS 1.138.4 and 1.150.3 have no impact on the problem.

However when I upgrade plugins like below, the external workspace is no longer applied inside the "stage". "withEnv" or "withCredentials" steps:

Ant: 1.9 -> 1.10

Credentials Binding: 1.18 -> 1.20

Docker Commons: 1.14 -> 1.15

Lockable Resources: 2.5 -> 2.6

Mailer: 1.23 -> 1.29

Matrix Authorization Strategy: 2.4.2 -> 2.5

Pipeline: Basic Steps: 2.16.1 -> 2.18

Pipeline: Declarative: 1.3.8 -> 1.3.9

Pipeline: Declarative Extension Points API: 1.3.8 -> 1.3.9

Pipeline: Model API: 1.3.8 -> 1.3.9

Pipeline: Nodes and Processes: 2.28 -> 2.31

Pipeline: Stage Tags Metadata 1.3.8 -> 1.3.9

SSH Slaves: 1.29.4 -> 1.30.2

Timestamper 1.9 -> 1.10

I think the Pipeline plugins have something to do with it. Anyone has any idea of what's different?

Martin

[martinda]

I suspect this change:

https://github.com/jenkinsci/workflow-durable-task-step-plugin/pull/101/files#diff-08a6dd4e3141d4c4e0c00e1e80734e19

might have broken the external workspace manager plugin. If this is right, how should it be modified so that it works again?

Thanks,

Martin

[Jesse Glick]

On Wed, Oct 16, 2019 at 8:54 AM martinda <martin....@gmail.com> wrote:
> I suspect this change:
> https://github.com/jenkinsci/workflow-durable-task-step-plugin/pull/101/files#diff-08a6dd4e3141d4c4e0c00e1e80734e19
>
> might have broken the external workspace manager plugin.

`FilePathDynamicContext`? Quite possibly. Update your `test`-scoped
dependencies (or use the BOM) and check.

> If this is right, how should it be modified so that it works again?

Possibly just by wrapping in `FilePathDynamicContext.createContextualObject`.

[martinda]

`FilePathDynamicContext`? Quite possibly. Update your `test`-scoped
dependencies (or use the BOM) and check.

> If this is right, how should it be modified so that it works again?

Possibly just by wrapping in `FilePathDynamicContext.

createContextualObject`.

Thanks. I have spend a few hours trying to update the external workspace manager plugin pom.xml to pick up the FilePathDynamicContext from org.jenkins-ci.plugins.workflow:workflow-durable-task-step:2.31. But I was not successful in aligning the other dependencies. I get in a spiral where workflow plugins race to their most recent versions and I run out of options. Also, I do not know what you mean by "use the BOM". I use the "enforcer", it tells me what's wrong (see https://gist.github.com/martinda/cfb51b953e2a4709dc73abf8a41a396c#file-maven-txt-L11).

Martin

[Mark Waite]

The BOM (bill of materials) provides a set of dependency versions that are known to work together and that do not have enforcer conflicts.

Refer to https://github.com/jenkinsci/git-plugin/pull/762/files and https://github.com/jenkinsci/git-plugin/pull/768/files for an example of the transition from not using the BOM to using the BOM.

Other references might be https://github.com/jenkinsci/git-client-plugin/pull/460/files plus https://github.com/jenkinsci/git-client-plugin/pull/465/files and https://github.com/jenkinsci/platformlabeler-plugin/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aclosed+BOM 

I like what the BOM provides, since it reduces my workload to select dependencies and reduces dramatically the number of enforcer exclusions I need.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/fbb16917-ba92-4d82-8c61-285b9af6f5d9%40googlegroups.com.

--

Thanks!

Mark Waite

[Jesse Glick]

On Wed, Oct 16, 2019 at 5:29 PM martinda <martin....@gmail.com> wrote:
> I do not know what you mean by "use the BOM".

Relatively new:

https://github.com/jenkinsci/bom#usage

as mentioned in:

https://jenkins.io/doc/developer/plugin-development/updating-parent/

[martinda]

Thank you Jesse. The BOM is actually awesome. It solved my problem.