Travis-CI build enhancements #806

Merged
merged 2 commits into from Oct 5, 2016

Projects

None yet

3 participants

@mprins
Contributor
mprins commented Sep 23, 2016 edited

As discussed in #803 (comment) this PR brings JDK 9 builds on Travis-CI and automatic deployment of snapshots to the central repository.

  • Start testing on Java 9 with Maven 3.3.9
  • upgrade maven plugins and require Maven >= 3.2
  • set up for publishing snapshots to maven central

The latter needs to have the secure keys generated and added in the .travis.yml (there are some placeholders there now) so that after a succesful build of the master branch the snapshot artifacts are deployed.

This build no longer uses the /core/files/travis-build.sh not sure if that can be removed, it has some out-commented npm stuff.

@karussell
Member

Already really nice - thanks!

mprins added some commits Sep 23, 2016
@mprins mprins start building on java 9 and set up for publishing snapshots to maven…
… central
736779f
@mprins mprins upgrade some maven plugins and require maven 3.2
479313f
@mprins mprins changed the title from [WIP] Travis build enhancements to Travis-CI build enhancements Sep 24, 2016
@mprins
Contributor
mprins commented Sep 24, 2016 edited

@karussell this needs a little something on your side to add the secure keys to the travis file; deployment should then start working after merging into master.

Also I've set up to allow test failures on java 9, and it's showing some with a message of unable to unmap the mapped buffer. eg. https://travis-ci.org/graphhopper/graphhopper/jobs/162408743#L1011

@karussell
Member

Thanks - will read next week about how to setup the secure keys.

Regarding the JDK9: in #701 I already stumbled over this ugliness, but I'm unsure how to fix this yet (see the link there). Maybe we can exclude or ignore (for now) a single test for a specific JDK version?

-script: ./core/files/travis-build.sh
+
+script:
+ - mvn clean test verify -B
@karussell
karussell Sep 24, 2016 Member

I've looked up what the -B means (--batch-mode) ... why is this necessary?

@mprins
mprins Sep 26, 2016 Contributor

it would prevent the build waiting until it times out if any interactive response would be required

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
+ <version>3.0.2</version>
@karussell
karussell Sep 24, 2016 edited Member

As you already changed this in the parent pom, this is not necessary here (?) and when not being explicit here, we can then easier upgrade versions later on in the parent pom

@mprins
mprins Sep 26, 2016 Contributor

that would only work if the parent pom has a pluginManagement section where the version is specified otherwise the result of the version resolution of the plugin is undefined (maven will just pick one that's available), see: https://maven.apache.org/pom.html#Plugin_Management

@karussell
karussell Sep 27, 2016 Member

Ups, thanks for pointing this out :) ! Maybe it would then be better to have a plugin section in the root pom or are there disadvantages?

@mprins
mprins Oct 4, 2016 Contributor

You can setup the plugins in the parent pom like:

<build>
    <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-compiler-plugin</artifactId>
                    <version>3.5.1</version>
                    <configuration>
                        <source>${java.version}</source>
                        <target>${java.version}</target>
                    </configuration>
                </plugin>
...
            </plugins>
        </pluginManagement>

and then in the build section of the child projects and possibly the parent as well specify the plugins to be used for the build of that artifact. You can find a working example in https://github.com/B3Partners/flamingo-ibis/blob/master/pom.xml

the downside is that there is some duplication of plugins (they both the pluginManagement and the build section of a pom will have a plugins section)

</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-compiler-plugin</artifactId>
+ <artifactId>maven-compiler-plugin</artifactId>
+ <version>3.5.1</version>
@karussell
karussell Sep 24, 2016 Member

Same here: we could remove the version (?)

@mprins
mprins Sep 26, 2016 Contributor

as above, not really a good idea

@karussell
Member

Uhm, strange. How it comes I have a comment in my emails regarding the 2 profiles but not here?

You could specify two profiles, one for jdk8 and one for jdk9...

@karussell
Member

Nice! Deployment seems to work (according to the time stamps of the snapshot) but still something timed out: https://travis-ci.org/graphhopper/graphhopper/jobs/163212260

travis_jigger $! $timeout $cmd

Before I can merge it: would you mind to sign the CLA (you do not give away your rights, just agree to the Apache License) and send this to us. Or just send me your email so that I can send you an easier to handle digital signing doc.

@karussell karussell added this to the 0.8 milestone Sep 27, 2016
@devemux86
Contributor
devemux86 commented Sep 28, 2016 edited

travis_jigger $! $timeout $cmd

That probably comes from travis_wait, is it needed (default 10 min)?

@mprins
Contributor
mprins commented Oct 4, 2016

the travis_wait may not be necessary, if there is output within the 10 mins. if the deploy produces no log output for 10min or more travis will fail the deploy as it seems stalled (to travis)

@mprins
Contributor
mprins commented Oct 4, 2016

Uhm, strange. How it comes I have a comment in my emails regarding the 2 profiles but not here?

You could specify two profiles, one for jdk8 and one for jdk9...

@karussell I commented on the original issue #701

@karussell karussell merged commit 59ae8a1 into graphhopper:master Oct 5, 2016

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@karussell
Member

Merged - thanks a lot again @mprins - really nice now :) !

We'll improve this now in an iterative manner later on ...

@mprins mprins deleted the mprins:travis-ci_enhancements branch Oct 5, 2016
@karussell
Member
karussell commented Oct 17, 2016 edited

Currently the 0.9 snapshots are not deployed anymore, e.g. see https://travis-ci.org/graphhopper/graphhopper/jobs/168299877

It says:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on project graphhopper-parent: Failed to deploy artifacts: Could not transfer artifact com.graphhopper:graphhopper-parent:pom:0.9-20161017.130625-2 from/to ossrh (https://oss.sonatype.org/content/repositories/snapshots): Failed to transfer file: https://oss.sonatype.org/content/repositories/snapshots/com/graphhopper/graphhopper-parent/0.9-SNAPSHOT/graphhopper-parent-0.9-20161017.130625-2.pom. Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1]

Any clue about this?

Also it says:

This job is running on container-based infrastructure, which does not allow use of 'sudo', setuid and setguid executables.

If you require sudo, add 'sudo: required' to your .travis.yml

And we have sudo: false in the root but in the matrix section we have sudo: required. Is this correct?

The latest snapshots here are triggered once (graphhopper-core-0.9-20161017.130102-1.jar) via manual deployment

@karussell karussell referenced this pull request Oct 17, 2016
@karussell karussell new development version 0.9-SNAPSHOT 699b04d
@mprins
Contributor
mprins commented Oct 17, 2016

Any clue about this?
The username and password are invalid; looking at the .travis.yml the are:

    - secure: "CI_DEPLOY_USERNAME=central_username"
    - secure: "CI_DEPLOY_PASSWORD=central_password"

those still need to be update to your (encrypted) credentials as I wrote up top

The latter needs to have the secure keys generated and added in the .travis.yml (there are some placeholders there now) so that after a successful build of the master branch the snapshot artifacts are deployed.

see: https://docs.travis-ci.com/user/environment-variables/#Defining-encrypted-variables-in-.travis.yml (and https://docs.travis-ci.com/user/encryption-keys )

ps When using the Travis gem I would not use the --add option, it will ruin the .travis.yml layout

And we have sudo: false in the root but in the matrix section we have sudo: required. Is this correct?

We are changing to a different build image as part of the build matrix; using

sudo: required
dist: trusty
group: edge

the sudo is required to update the java 9 jdk on that machine to a current version (there is no relation to the snapshot deployment failure)

@karussell
Member

those still need to be update to your (encrypted) credentials as I wrote up top

I think this is a merge issue (or something else) as I've definitely updated them - thanks for pointing me to this :) !

ps When using the Travis gem I would not use the --add option, it will ruin the .travis.yml layout

what do you mean here?

We are changing to a different build image as part of the build matrix; using

Thanks for the explanation!

@karussell karussell added a commit that referenced this pull request Oct 17, 2016
@karussell karussell updated secure vars once again, #806 f1e6dba
@karussell
Member

Works now - thanks again @mprins :) ! E.g. see here

@karussell
Member

Just as a reference there is a web UI to create those keys: http://rkh.github.io/travis-encrypt/public/index.html

@karussell karussell referenced this pull request in levigo/jbig2-imageio Nov 17, 2016
Closed

Java 9 IllegalArgumentException #10

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment