The GitHub API recommends setting the version of the API to interact with GitHub. They recommend setting it if you're building an application and care about stability.

Accept: application/vnd.github.v3+json

Jervis needs to create matrix jobs from more complicated .jervis.yml files which test multiple things.

The environment header script will tell you what hostname you're on as well as other host information.

There's no immediate need to implement the following languages. Just creating a quick inventory.

• Android
• C#, F#, and Visual Basic which uses mono
• D
• Dart
• Julia
• Objective-C

Scala projects need to fall back onto the default Java build tools if SBT is not used.

This is a requirement for the project to flourish properly.

See groovy example in #28 for interpolating ${jervis_toolchain_ivalue}.

import groovy.json.JsonSlurper
def file='/tmp/toolchains.json'
toolchains = new groovy.json.JsonSlurper().parse(new File(file).newReader())
ArrayList interpolate_ivalue(ArrayList cmds, String ivalue) {
    def z = []
    cmds.each{ z << it.replace('${jervis_toolchain_ivalue}',ivalue) }
    z
}
println interpolate_ivalue(toolchains['rvm']['*'],'2.1.5').join('\n')
//println toolchains['rvm']['*'].join('\n')

It will not be exactly that but along those lines... perhaps renaming the fileIO class to support more than just the readFile() command. It would be something akin to a helper class for extended .jervis.yml features.

Don't forget to unit test the lifecycleGenerator class.

Generic format

This is the general description of the supported language format listing default commands. This will be used to generate default commands depending on the language and files detected in the repository.

{
    "language": {
        "defaultKey": "somekey",
        "somekey": {
            "fileExistsCondition": ["/root/path", "somefile"],
            "fallbackKey": "some other key",
            "before_install": "some command",
            "install": "some command",
            "before_script": "some command",
            "script": "some command",
            "after_success": "some command",
            "after_failure": "some command",
            "after_script": "some command",
        },
        "some other key": {
            "fileExistsCondition": ["/root/path", "somefile"],
        }
    }
}

• "language" - is the language that the commands are set up for. e.g. groovy, python, ruby, java, etc. The language is the root key of the object and will be used to look up default commands for all of the different command generation cases. The following keys fall under the language. Validation: This key is required.
  • "defaultKey" - This is the default key which will be used to look up the default commands to be generated. Validation: This key is required. The value of this key must exist as another key in the same level as this key.
  • "somekey" - This key is one or more keys in which will, by convention, be named after the build tool the commands are related to. e.g. gradle, ant, maven, etc.

A more specific formatted example

Here's an example of our supported language key when we're supporting just the groovy language based on "Building a Groovy project" Travis CI Documentation.

{
    "groovy": {
        "defaultKey": "gradle",
        "gradle": {
            "fileExistsCondition": ["/", "build.gradle"],
            "fallbackKey": "maven",
            "before_install": "",
            "install": "gradle assemble",
            "before_script": "",
            "script": "gradle check",
            "after_success": "",
            "after_failure": "",
            "after_script": "",
        },
        "maven": {
            "fileExistsCondition": ["/", "pom.xml"],
            "fallbackKey": "ant",
            "install": "mvn install -DskipTests=true",
            "script": "mvn test",
        },
        "ant": {
            "fileExistsCondition": ["/", "pom.xml"],
            "install": "mvn install -DskipTests=true",
            "script": "mvn test",
        }
    }
}

If readFile(/somefile) is used then it should read the file from the filesystem relative to the root of the repository. That logic would look something like this...

x="readFile(/path/to/file.sh)"
if (x[0..8] == 'readFile(') {
    println "Read the file ${x[9..-2]}"
}
else {
    println "Handle the string as a script on a single line."
}

This should return an ArrayList that is a simple list of folders and files. This way we can load the list of files into the lifecycleGenerator to be used to generate the shell code.

#16 implements support for RSA encrypted strings. Implement support for the secure: field in .jervis.yml files. Execution in Jenkins should look something like this.

set +x
echo "Executing secure section."
#some decrypted secure section execution
set -x
#normal execution

Note: this would generate the secure contents as plain text inside of the Jenkins job so only Jenkins administrators should be able to see the Job configuration.

This issue is a reminder to write groovydoc for the lifecycleGenerator class when it has been finished.

securityIO class issuing git commands as part of it's instantiation causes issues when working with the Job DSL plugin. It should be refactored so it is no longer using scmGit and users of the library will have to be explicit about the paths of the keys being used.

The following jervis.remotes.GitHub class functions still need to be tested.

• fetch()
• branches()
• getFile()
• fileExists()

This will require service mocking for the GitHub API.

Potentially helpful link: http://groovy.dzone.com/news/writing-unit-tests-using-groov

http://stackoverflow.com/questions/574809/load-a-resource-contained-in-a-jar

Seems achievable if we treat the resources as streams and use the loadLifecyclesString and loadToolchainsString functions.

Then a user can simply call code like...

import jervis.lang.lifecycleGenerator
def generator = new lifecycleGenerator()
generator.loadDefaults()
generator.loadYamlString('language: ruby')

The generator.loadDefaults() function would call generator.loadLifecyclesString(java.lang.String) and generator.loadToolchainsString(java.lang.String) functions. More testing needed 🎯

I would like better defined exceptions. For example,

throw new MissingKeyException(transNbr, originalException);

Rather than a simple,

throw new Exception("some message")

Exceptions should ideally extend from better defined exceptions from the default list of exceptions. An example where poorly defined exceptions are being used is the lifecycleValidator.

Get version of groovy in Jenkins. Visit Manage Jenkins > Manage Nodes > master > Script Console. Then execute the following code.

println GroovySystem.version

Jenkins ver. 1.590 is running Groovy 1.8.9. All unit tests should be tested with Groovy 1.8.9 until they update it.

Must be able to generate Jervis api docs using groovydoc in gradle.

gradle groovydoc

It currently generates the groovydoc. However, the documentation is pretty horrible. This will need to be improved.

Jervis needs to support building ruby projects.

The securityIO class has most of its unit tests implemented from #16. Still not unit testing a few functions:

• generate_rsa_pair
• rsaEncrypt
• rsaDecrypt

Jervis needs to support building python projects.

A bug report surrounding a MissingPropertyException being thrown for an extended property reference has been filed with the upstream gradle project.

https://discuss.gradle.org/t/missingpropertyexception-thrown-for-extended-properties-used-in-build-dependencies-section-of-build-gradle/2103

It's not obvious that fileIO is using scmGit as part of reading the file. This should be better documented.

See an example interface

http://groovy.codehaus.org/Groovy+Mocks

Jervis needs to allow a core and recommended Jenkins plugins to co-exist. As recommended plugins are installed then Jenkins provides more features automaticaly. e.g. virus scanning of artifacts when the ClamAV plugin is installed.

plugins = []
default_plugins = ["Plugin:pam-auth", "Plugin:antisamy-markup-formatter", "Plugin:maven-plugin", "Plugin:cvs", "Plugin:external-monitor-job", "Plugin:credentials", "Plugin:mailer", "Plugin:subversion", "Plugin:translation", "Plugin:matrix-project", "Plugin:ssh-credentials", "Plugin:ant", "Plugin:ldap", "Plugin:junit", "Plugin:javadoc", "Plugin:windows-slaves", "Plugin:matrix-auth", "Plugin:ssh-slaves", "Plugin:scm-api", "Plugin:mapdb-api"]
installed_plugins = []
hudson.model.Hudson.instance.pluginManager.plugins.each {
    plugins << it.toString()
}
println "Installed plugins:"
plugins.each {
    if(!(it in default_plugins)) {
        installed_plugins << it
    }
}
installed_plugins.each { println it }
null

loadYaml currently takes a String which is the contents of a YAML file. However, loadToolchains and loadLifecycles arguments are a String that is a file path to read the contents of a file. loadToolchainsString and loadLifecyclesString uses a String which contains the contents of the respective files.

Therefore, loadYaml should be renamed to loadYamlString. loadYamlString will take a String which is the contents of a YAML file.

loadYaml will now be a file path to read the contents of a file.

install: true

is interpreted as a boolean and throws an exception. Jervis scripts should be able to handle this with string conversion.

Need a nifty way of storing toolchains that are easy to extend similar to how lifecycles was done.

The following are potential missing items that might be categorized within the toolchains file. Android projects have Android components. Perhaps it would be good to extend the toolchains file beyond build matrices.

• lein (Clojure)
• d (D)
• dart (Dart)
• otp_release (Erlang)
• go (Go)
• ghc (Haskell)
• node_js (JavaScript with Node.js)
• julia
• xcode_sdk and xcode_scheme (Objective-C)
• perl (Perl)
• php (PHP)
• rust (Rust)
• scala (Scala)

Jervis needs to support excluding branches in .travis.yml files.

# blacklist
branches:
  except:
    - legacy
    - experimental

# whitelist
branches:
  only:
    - master
    - stable

http://docs.travis-ci.com/user/build-configuration/#Specify-branches-to-build

Take a leaf out of DotCI for templating of the .jervis.yml.

https://github.com/groupon/DotCi/blob/master/docs/InstallPackages.md

Read the YAML file via the GitHub API and then parse the template like the following.

http://groovy.codehaus.org/Groovy+Templates

Tested in Jenkins ver. 1.590. Tried this after reading JENKINS-19401. This is how I will parse the .travis.yml.

@Grab(group='org.yaml', module='snakeyaml', version='1.14')
import org.yaml.snakeyaml.Yaml

def my_yaml = "language: ruby\nrvm:\n - 1.9.3\n - 2.0.0\n - 2.1.1"

println my_yaml

Yaml yaml = new Yaml()
def build_info = yaml.load(my_yaml)
//print all the versions of ruby in rvm to test
build_info.rvm.each {
  println build_info.language + " " + it
}
println build_info

Jervis needs to be able to create a simple job from .travis.yml.

This issue has already been tracked in the upstream project cobertura/cobertura#184. Code coverage drastically goes down when performing code coverage on Groovy 2.1.X and later. This is a bug in cobertura.

This issue is simply to link the upstream issue as a known issue. This is not currently an issue for Jervis because Jenkins embeds Groovy 1.8.9. However, if the Groovy runtime in Jenkins is upgraded this will definitely become an issue.

This issue is to track a bug report opened with the Groovy project.

Passing Groovy versions:

1.8.9, 2.0.8, 2.1.9, 2.2.2, 2.3.0

Affects Groovy Version/s:

2.3.1, 2.3.2, 2.3.3, 2.3.4, 2.3.5, 2.3.6, 2.3.7, 2.3.8, 2.3.9, 2.4.0-rc-1

Testing Environments:

OS: Ubuntu 14.04 LTS
Java: JDK 1.7.0_65, vendor: Oracle Corporation 24.65-b04
Gradle 2.2.1

OS: Ubuntu 12.04 LTS
Java version: JDK 1.7.0_72, vendor: Oracle Corporation
Gradle 2.2.1

Description

When traversing a HashMap that was created from a parsed JSON file my unit tests start failing on Groovy versions 2.3.1 and later. There seems to be some sort of regression introduced.

To explore and debug this problem you may view my travis builds testing the latest versions of Groovy from 1.8.9 through 2.4.0-rc-1.

https://travis-ci.org/samrocketman/jervis/builds/45633511

If you would like to check out and debug the problem yourself you can do the following:

git clone https://github.com/samrocketman/jervis.git
cd jervis
git checkout 2590bf2be5f8f2aaa1a25bcd63912506059da8c7
#passing build
GROOVY_VERSION="2.3.0" ./gradlew check
#first failing build
GROOVY_VERSION="2.3.1" ./gradlew check

gradlew check will automatically download Gradle 2.2.1, download the version of Groovy requested, assemble dependencies, compile, and execute unit tests.

Current Assessment

This is not much of a problem for me now because Jenkins CI embeds Groovy 1.8.9. However, future looking I think it would be good to address this.

Jervis needs to support generating groovy jobs... After all, Jervis is groovy :)

From Power User Moves I should be building jobs using my own DSL. It is also a good template for unit testing Job DSL code.

It would be preferable to automatically install plugins via groovy script. It is easy to detect what plugins are installed (or not installed).

It is not very easy to install the plugins when it is known one is missing.

This ensures that the docs are good. Also, a review of the documentation would be good as well.

I know the Job DSL plugin can configure the config.xml for jobs. However, it would be nice if it can configure some of the root settings in config.xml of $JENKINS_HOME. This would be useful during initial setup where Jervis can prompt for some settings and, if necessary, apply sane defaults.

When the first release of Jervis is ready the library should be published to Maven Central. This eases its use.

https://issues.sonatype.org/browse/OSSRH-13869

There must be at least 80% test coverage for Jervis before the first stable release. Check coverage:

./gradlew coberturaCheck test

./gradlew check will generate a cobertura report in build/reports/cobertura.

Double Exception

YAML

language: python
python: 2.6

Throws an unfriendly exception when the user should be using

language: python
python: "2.6"

This should definitely be handled because user input can create this exception.

Calling keySet() on null object

Calling toolchainValidator.supportedTool("derpy", "derp") gives unfriendly exception when it is actually a problem with that function not throwing a more friendly exception on the fact that "derpy" does not exist as a toolchain in the toolchains file. Do we really care? I can't think of where a user would actually use this. Remains to be seen. For now it is documented in groovydoc.

This really only affects developers developing Jervis and not end users so not sure I care too much about this. Don't care...

Jervis must support encrypted strings, preferably public key encryption.

In order to support after_success, after_failure, and after_script the following plugins need to be installed.

• Plugin:flexible-publish
• Plugin:postbuildscript

For more information see the Build overview wiki entry.

config.xml

The parent structure is:

<project>
  <publishers>
  </publishers>
</project>

The following XML describes the behavior of post-build actions of after_success, after_failure, and after_script.

  <publishers>
    <org.jenkins__ci.plugins.flexible__publish.FlexiblePublisher plugin="[email protected]">
      <publishers>
        <org.jenkins__ci.plugins.flexible__publish.ConditionalPublisher>
          <condition class="org.jenkins_ci.plugins.run_condition.core.AlwaysRun" plugin="[email protected]"/>
          <publisherList>
            <org.jenkinsci.plugins.postbuildscript.PostBuildScript plugin="[email protected]">
              <buildSteps>
                <hudson.tasks.Shell>
                  <command>echo &apos;after_success commands&apos;</command>
                </hudson.tasks.Shell>
              </buildSteps>
              <scriptOnlyIfSuccess>true</scriptOnlyIfSuccess>
              <scriptOnlyIfFailure>false</scriptOnlyIfFailure>
              <markBuildUnstable>false</markBuildUnstable>
            </org.jenkinsci.plugins.postbuildscript.PostBuildScript>
            <org.jenkinsci.plugins.postbuildscript.PostBuildScript plugin="[email protected]">
              <buildSteps>
                <hudson.tasks.Shell>
                  <command>echo &apos;after_failure commands&apos;</command>
                </hudson.tasks.Shell>
              </buildSteps>
              <scriptOnlyIfSuccess>false</scriptOnlyIfSuccess>
              <scriptOnlyIfFailure>true</scriptOnlyIfFailure>
              <markBuildUnstable>false</markBuildUnstable>
            </org.jenkinsci.plugins.postbuildscript.PostBuildScript>
            <org.jenkinsci.plugins.postbuildscript.PostBuildScript plugin="[email protected]">
              <buildSteps>
                <hudson.tasks.Shell>
                  <command>echo &apos;after_script commands&apos;</command>
                </hudson.tasks.Shell>
              </buildSteps>
              <scriptOnlyIfSuccess>false</scriptOnlyIfSuccess>
              <scriptOnlyIfFailure>false</scriptOnlyIfFailure>
              <markBuildUnstable>false</markBuildUnstable>
            </org.jenkinsci.plugins.postbuildscript.PostBuildScript>
          </publisherList>
          <runner class="org.jenkins_ci.plugins.run_condition.BuildStepRunner$Fail" plugin="[email protected]"/>
        </org.jenkins__ci.plugins.flexible__publish.ConditionalPublisher>
      </publishers>
    </org.jenkins__ci.plugins.flexible__publish.FlexiblePublisher>
  </publishers>

2.2.6 is out.

https://plugins.gradle.org/plugin/net.saliman.cobertura

Jervis needs to support building java projects.

Just read the https://api.github.com/repos/samrocketman/jervis/contents/ api link and parse out the file name. Same could be said for any path to read the parent folder instead of the file.

Filed an upstream bug with the Jenkins Job DSL Plugin. It's not correctly setting the workspace directory causing Jervis to fail. This will be closed when a workaround is found or a fix is released by the developers.

https://issues.jenkins-ci.org/browse/JENKINS-26849

Research GVM to test against multiple versions of groovy. Perhaps that's a better method.

Since parts of this program depend on the third party APIs of GitHub it would be good to have integration tests with it. Perhaps, repository re-organization is in order.

http://selimober.com/blog/2014/01/24/separate-unit-and-integration-tests-using-gradle/