Defer version of test framework in dependencies

Help/Discuss
1

Hello!

We run a C++ project, and when testing locally, we use gradle to download the correct version of our testing frameworks (e.g. nunit, google test as well as a locally developed simulator).

We then have Jenkins compile and publish builds on Artifactory from several different repositories.

Later in the CI chain we need to run these tests on Jenkins, by downloading a build (ie binaries as well as other information such as relevant tool versions) but not the source code.

The gradle code in the repository that run the tests can’t be synchronized to all the different code repositories we have, so we need to determine the version to use after downloading the build.

Is this even possible?

2

Maybe write the information you need to a file and publish it too, either together with the binaries, or in a separate variant with only that file as artifact?

3

Publishing the information was the easy part.

The question is if I can use the dependency management in gradle, this is how the gradle code looks right now:

dependencies {
    nunit  "${nunitTestPath}${nunitVersion}@zip"
}

nunitTestPath and nunitVersion are set in gradle.properties, which works fine when running the tests locally from the source code repository.

However, the issue is when I have downloaded the build (including the file with the correct values for that specific build), can I ,

Ok, I think I have some kind of solution, if there is a file with the information, I read that, if not, I can still run the code to select and download the test.

I just have to split the test run in two different calls to gradle.

4

I have been working on this for a while now and this is the best I can do:

def buildInfoFileName = './build/build_info.json'
def buildInfo = [:]
File buildInfoFile = new File(buildInfoFileName)
if (buildInfoFile.exists()) {
    def jsonSlurper = new JsonSlurper()
    buildInfo = jsonSlurper.parse(buildInfoFile)
    buildInfo.each { k, v ->
        print("Setting ${k} = ${v}\n")
        project.setProperty(k,v)
    }
    dependencies {
        nunit "${nunitTestPath}${nunitVersion}@zip"
    }
}

The problem is that setProperty() requires that the property exists to change it. I would have much preferred if it was possible to add a property but can’t find any way to do that,

I suppose I could just add the properties I expect to use to gradle.properties and then I should be able to change them.

5

The problem is that setProperty() requires that the property exists to change it.

Either just use buildInfo.nunitTestPath, or use project.ext.setProperty the first time you define the property.
But actually almost all usages of ext / extra properties is a work-around for not doing something properly.

6

That is how I will solve it:
Set the properties I expect to use to dummy values.

If I were to be more security concious I would explicitely only set those I expect anyway.

7

Well, also with that you are setting ext / extra properties, just implicitly.
If you only use them for that substitution, as I said, just get the value directly from buildInfo.
Why first setting it as extra property?

8

The reason is that we have several different code repositories where these properties are set in gradle.properties, and then used in shared code.

We also need to maintain several different releases so we can’t just hard code everything everywhere.

This solution is intended for the repository with the test code that Jenkins uses, and Jenkins will test many different variants and version of artifacts from the code repositories.

So what you see here is just a test setup. I could have set the properties in gradle.properties and it would only have made the example incompete.

9

Sorry, but I still don’t get it.
What do you win with using

buildInfo.each { k, v ->
   print("Setting ${k} = ${v}\n")
   project.setProperty(k,v)
}
dependencies {
   nunit "${nunitTestPath}${nunitVersion}@zip"
}

or

buildInfo.each { k, v ->
   print("Setting ${k} = ${v}\n")
   project.ext.setProperty(k,v)
}
dependencies {
   nunit "${nunitTestPath}${nunitVersion}@zip"
}

over just doing

dependencies {
   nunit "${buildInfo.nunitTestPath}${buildInfo.nunitVersion}@zip"
}

?

10

Definitely a valid question considering the limited information.

The reason is that the actual code with the dependencies is in a shared repository used both by the test code repository and the production code repository, and I do not want to change all of the code repositories to set up a buildInfo variable instead of using gradle.properites as they do now.

1 Like