Run integration tests with specific files in workspace directory

[seanfisk]

Hi, thank you for creating this library!

We are hoping to run an integration test with a particular set of files in our workspace directory to ensure our pipeline is running successfully. We've consulted the example repository but have only found examples that run with an empty workspace.

Is there an easy way to populate the workspace with these files before the test is run?

We have used Jenkins for a while in my organization but are just starting with shared libraries, and I found this plugin in hopes that I'll be able to use it to test our first shared library. This may be a basic question, but we're stuck on it and since your project is very active, I figured I would ask! Thank you!

[mkobit]

Good question - there isn't an example for this right now, and this is a pretty obvious use case I've missed. I'll try and think about it and come up with an answer tomorrow.

[mkobit]

Would you expect it to work with the existing scm functionality? Like checkout(scm)? Or some other method to put stuff in the workspace?

[seanfisk]

Hm, good question. I think there is definitely a trade-off here:

• Use of SCM functionality is not necessary for my use case, and also complicates inclusion into a project (e.g., storing a Git repo in another Git repo, or having a separate repo).
• That said, some build systems require presence of an SCM. I'm thinking specifically of systems that run git rev-parse …, etc.

As I mentioned, dropping some files into the workspace while effectively turning checkout(scm) into a no-op is fine for my use case, but I could think of cases where having a true SCM would be helpful.

Thanks for the quick and thoughtful response!

[mkobit]

• Use of SCM functionality is not necessary for my use case, and also complicates inclusion into a project (e.g., storing a Git repo in another Git repo, or having a separate repo).

I definitely think including a another repository, submodules, or separate repository, is too much overhead.

I'm thinking that if there is a way to inject a "mock scm" global variable into the pipeline that you can say whatever files you want into it, or if there is a better/different way to "mock" which files to put into the workspace.

I haven't been a Jenkins user for a while, so I'm trying to think of how users would typically get stuff into their workspace, and I feel like checkout(scm) was the "normal" case. However, for shared library tests there could be a different desired path to put stuff into a workspace.

---

A not-so-pleasant workaround for now could use the writeFile (that page has a terrible time loading for me) to set up the workspace for you. Here is a test similar to the others in ExampleSrcSpockSpec.groovy in the example project:

  def "use files in workspace"() {
    given:
    WorkflowJob workflowJob = rule.createProject(WorkflowJob, 'project')
    String someWorkspaceFileContents = """
      some file with text
      be careful about indentation
      also be careful with escaping
    """.stripIndent()
    workflowJob.definition = new CpsFlowDefinition("""
        node {
          writeFile(file: 'file.txt', text: '''
           $someWorkspaceFileContents
          '''.stripIndent())
          sh 'cat file.txt'
        }
    """.stripIndent(), true)

    when: 'workflow executed'
    QueueTaskFuture<WorkflowRun> defaultsRun = workflowJob.scheduleBuild2(0)

    then: 'build output echos file contents'
    WorkflowRun result = rule.assertBuildStatusSuccess(defaultsRun)
    rule.assertLogContains(someWorkspaceFileContents, result)
  }

I definitely think there can be some improvements here, not sure about the best route and user experience for this feature, yet.

[seanfisk]

I definitely think including a another repository, submodules, or separate repository, is too much overhead.

Agreed!

I haven't been a Jenkins user for a while, so I'm trying to think of how users would typically get stuff into their workspace, and I feel like checkout(scm) was the "normal" case.

I would say so, yes.

A not-so-pleasant workaround for now could use the writeFile (that page has a terrible time loading for me) to set up the workspace for you.

It's a bit of a hack, but it looks like it would work for us! StringEscapeUtils#escapeJava could get us most of the way in terms of escaping.

We will try the workaround while a cleaner solution is in the works. Thank you so much for your help!

[mkobit]

I found https://jenkins.io/doc/developer/testing/ which has a similar suggestion to mine and and also shows an example of using the unzip step from the Pipeline Utility Steps plugin which might work better.

Unfortunately, it doesn't show a way to basically mock the scm variable for pipeline runs, so I'll have to investigate or post on the Jenkins developer forum.

[Jonatha1983]

I think you can mock by creating a Script instance with

InvokerHelper.createScript(null, new Binding()) 

and then in the before method

mockScript.scm = "astring" // OR { aClouser -> aClouser() }

[seanfisk]

Thanks, guys. For now we are just using vanilla JenkinsPipelineUnit, but if an easier-to-maintain solution pops up here, we may consider it.

[mkobit]

My fault @seanfisk , I thought you were talking about integration testing using JenkinsRule.