[GRASS-dev] Still Failing: GRASS-GIS/grass-ci#1898 (master - 7fa0125)

Travis_CI · January 29, 2017, 2:15pm

GRASS-GIS / grass-ci (master)

Build #1898 is still failing.

5 minutes and 46 seconds

Moritz Lennert

7fa0125 Changeset →

v.to.db: added bounding box as additional measure (one suggestion of #2122)

git-svn-id: https://svn.osgeo.org/grass/grass/trunk@70451 15284696-431f-4ddb-bdfa-cd5b030d7da7

Want to know about upcoming build environment updates?

Would you like to stay up-to-date with the upcoming Travis CI build environment updates? We set up a mailing list for you! Sign up here.

	Documentation about Travis CI Need help? Mail support! Choose who receives these build notification emails in your configuration file.

Would you like to test your private code?

Travis CI for Private Projects could be your new best friend!

mlennert · January 29, 2017, 2:48pm

There seems to be an issue with Travis which cannot download trunk:

**********************************
==> Cloning https://svn.osgeo.org/grass/grass/trunk

Error validating server certificate for 'https://svn.osgeo.org:443':

- The certificate is not issued by a trusted authority. Use the

fingerprint to validate the certificate manually!

Certificate information:

- Hostname: *.osgeo.org

- Valid: from Thu, 28 Apr 2016 00:00:00 GMT until Wed, 01 May 2019
23:59:59 GMT

- Issuer: www.ssl.com, SSL.com, US

- Fingerprint:
56:50:0d:63:0f:47:10:92:7a:3a:b5:a9:83:f8:97:92:fe:d6:19:95

(R)eject, accept (t)emporarily or accept (p)ermanently? svn: E175002:
Unable to connect to a repository at URL
'https://svn.osgeo.org/grass/grass/trunk’

svn: E175002: OPTIONS of 'https://svn.osgeo.org/grass/grass/trunk’:
Server certificate verification failed: issuer is not trusted
(https://svn.osgeo.org)

Error: Failed to download resource "grass-trunk"
*******************************

Moritz

Le Sun, 29 Jan 2017 14:15:13 +0000,
Travis CI <builds@travis-ci.org> a écrit :

Build Update for GRASS-GIS/grass-ci
-------------------------------------

Build: #1898
Status: Still Failing

Duration: 5 minutes and 46 seconds
Commit: 7fa0125 (master)
Author: Moritz Lennert
Message: v.to.db: added bounding box as additional measure (one
suggestion of #2122)

git-svn-id: https://svn.osgeo.org/grass/grass/trunk@70451
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset:
https://github.com/GRASS-GIS/grass-ci/compare/e3953483e94b...7fa01253b0a8

View the full build log and details:
https://travis-ci.org/GRASS-GIS/grass-ci/builds/196338327

--

You can configure recipients for build notifications in
your .travis.yml file. See
https://docs.travis-ci.com/user/notifications

neteler · January 29, 2017, 3:00pm

On Jan 29, 2017 3:49 PM, “Moritz Lennert” <mlennert@club.worldonline.be> wrote:

There seems to be an issue with Travis which cannot download trunk:

==> Cloning https://svn.osgeo.org/grass/grass/trunk

Error validating server certificate for ‘https://svn.osgeo.org:443’:

The certificate is not issued by a trusted authority. Use the

…

Thanks for checking this.
I have informed SAC about it.

Markus

wenzeslaus · January 30, 2017, 10:20pm

On Sun, Jan 29, 2017 at 9:48 AM, Moritz Lennert <
mlennert@club.worldonline.be> wrote:

(R)eject, accept (t)emporarily or accept (p)ermanently? svn: E175002:
Unable to connect to a repository at URL
'https://svn.osgeo.org/grass/grass/trunk’

svn: E175002: OPTIONS of 'https://svn.osgeo.org/grass/grass/trunk’:
Server certificate verification failed: issuer is not trusted
(https://svn.osgeo.org)

Error: Failed to download resource "grass-trunk"
*******************************

It seems to me that would be better if Travis for GRASS used the actual
source code from the repository directly and not use Homebrew and the
Homebrew installation would be tested separately.

https://trac.osgeo.org/grass/ticket/3250

Now http://grass.osgeo.org/ (which probably shouldn't have the test badge
at all) shows failed build because of missing certificates while nothing
being bad with GRASS source code.

Travis CI cannot build repo based on another repo:

https://github.com/travis-ci/travis-ci/issues/631

But it has cron jobs:

https://docs.travis-ci.com/user/cron-jobs/

Daily build of the Homebrew formula repo seems more appropriate for testing
than the workaround in the code.

Since Travis CI is not 100% reliable for Mac, it will also separate all the
false positives. It still can send messages to grass-dev (all Travis is
already white listed, right?) but more people should get access to the repo
if that's the case.

Vaclav

neteler · February 2, 2017, 10:03am

On Mon, Jan 30, 2017 at 11:20 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
...

Daily build of the Homebrew formula repo seems more appropriate for testing
than the workaround in the code.

Since Travis CI is not 100% reliable for Mac, it will also separate all the
false positives. It still can send messages to grass-dev (all Travis is
already white listed, right?) but more people should get access to the repo
if that's the case.

Silly question: why does our Mac script fetch from SVN and not from
git? This would solve it.

Markus

neteler · February 2, 2017, 10:20am

On Thu, Feb 2, 2017 at 11:03 AM, Markus Neteler <neteler@osgeo.org> wrote:

On Mon, Jan 30, 2017 at 11:20 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
...

Daily build of the Homebrew formula repo seems more appropriate for testing
than the workaround in the code.

Since Travis CI is not 100% reliable for Mac, it will also separate all the
false positives. It still can send messages to grass-dev (all Travis is
already white listed, right?) but more people should get access to the repo
if that's the case.

Silly question: why does our Mac script fetch from SVN and not from
git? This would solve it.

Extra question: where is the script actually doing this job?

Markus

Rainer_Krug · February 6, 2017, 7:49am

Markus Neteler <neteler@osgeo.org> writes:

On Mon, Jan 30, 2017 at 11:20 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
...

Daily build of the Homebrew formula repo seems more appropriate for testing
than the workaround in the code.

Since Travis CI is not 100% reliable for Mac, it will also separate all the
false positives. It still can send messages to grass-dev (all Travis is
already white listed, right?) but more people should get access to the repo
if that's the case.

Silly question: why does our Mac script fetch from SVN and not from
git? This would solve it.

It is using the svn repo, as it is the original GRASS repo. Technically,
there would be no problem at all to use the git repo, but I thought it
makes more sense to rely on the original authoritative repo.
Otherwise, there is no problem at all with using the git repo.

Rainer

Markus

--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

Rainer_Krug · February 6, 2017, 7:52am

Markus Neteler <neteler@osgeo.org> writes:

On Thu, Feb 2, 2017 at 11:03 AM, Markus Neteler <neteler@osgeo.org> wrote:

On Mon, Jan 30, 2017 at 11:20 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
...

Daily build of the Homebrew formula repo seems more appropriate for testing
than the workaround in the code.

Since Travis CI is not 100% reliable for Mac, it will also separate all the
false positives. It still can send messages to grass-dev (all Travis is
already white listed, right?) but more people should get access to the repo
if that's the case.

Silly question: why does our Mac script fetch from SVN and not from
git? This would solve it.

Extra question: where is the script actually doing this job?

How do you mean? The script is in the folder .travis (hidden to be
in line with the naming of the .travis.yml file and as it is of no
importance for GRASS itself). There were the scripts (see changeset
https://trac.osgeo.org/grass/changeset/70483 )

Rainer

Markus

--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

neteler · February 6, 2017, 1:50pm

On Mon, Feb 6, 2017 at 8:49 AM, Rainer M Krug <Rainer@krugs.de> wrote:

Markus Neteler <neteler@osgeo.org> writes:

On Mon, Jan 30, 2017 at 11:20 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
...

Daily build of the Homebrew formula repo seems more appropriate for testing
than the workaround in the code.

Since Travis CI is not 100% reliable for Mac, it will also separate all the
false positives. It still can send messages to grass-dev (all Travis is
already white listed, right?) but more people should get access to the repo
if that's the case.

Silly question: why does our Mac script fetch from SVN and not from
git? This would solve it.

It is using the svn repo, as it is the original GRASS repo. Technically,
there would be no problem at all to use the git repo, but I thought it
makes more sense to rely on the original authoritative repo.

At time Travis does not accept the SSL certificate of svn.osgeo.org,
that's why the job failed.

Otherwise, there is no problem at all with using the git repo.

Perhaps yes if that brings back the Mac tests at lowest cost (I know
there is also the homebrew or not thing to decides as well).

Markus

neteler · February 6, 2017, 1:52pm

On Mon, Feb 6, 2017 at 8:52 AM, Rainer M Krug <Rainer@krugs.de> wrote:

Markus Neteler <neteler@osgeo.org> writes:
How do you mean? The script is in the folder .travis (hidden to be
in line with the naming of the .travis.yml file and as it is of no
importance for GRASS itself). There were the scripts (see changeset
https://trac.osgeo.org/grass/changeset/70483 )

Yes - I was just wondering where the "svn" call is located which I
cannot see in these scripts.

Markus

wenzeslaus · February 6, 2017, 2:43pm

On Mon, Feb 6, 2017 at 8:52 AM, Markus Neteler <neteler@osgeo.org> wrote:

On Mon, Feb 6, 2017 at 8:52 AM, Rainer M Krug <Rainer@krugs.de> wrote:
> Markus Neteler <neteler@osgeo.org> writes:
> How do you mean? The script is in the folder .travis (hidden to be
> in line with the naming of the .travis.yml file and as it is of no
> importance for GRASS itself). There were the scripts (see changeset
> https://trac.osgeo.org/grass/changeset/70483 )

Yes - I was just wondering where the "svn" call is located which I
cannot see in these scripts.

That's the reason it should not be done the way that the travis test/build
(.travis.yml) in the main repo (its git copy) uses code which is actually
in a different repo (the Homebrew recipe) and is downloaded again for the
test (from Subversion repo in this case). Unless there are strong reasons
to do it otherwise, the test/build instructions in the main repo should
trigger builds which are based only on the code from that repo.

wenzeslaus · February 6, 2017, 2:50pm

On Mon, Feb 6, 2017 at 8:50 AM, Markus Neteler <neteler@osgeo.org> wrote:

> Otherwise, there is no problem at all with using the git repo.

Perhaps yes if that brings back the Mac tests at lowest cost

Assuming that the Homebrew repo will be tested separately, the question is
if we want to bring in another dependency - OSGeo Subversion to GitHub sync
- or if we want to keep dependencies to minimum. For now, getting code from
GitHub is the only way it works because of the broken SSL certificates, so
sure we can use it, but that's for now.

Rainer_Krug · February 6, 2017, 6:03pm

Markus Neteler <neteler@osgeo.org> writes:

On Mon, Feb 6, 2017 at 8:52 AM, Rainer M Krug <Rainer@krugs.de> wrote:

Markus Neteler <neteler@osgeo.org> writes:
How do you mean? The script is in the folder .travis (hidden to be
in line with the naming of the .travis.yml file and as it is of no
importance for GRASS itself). There were the scripts (see changeset
https://trac.osgeo.org/grass/changeset/70483 )

Yes - I was just wondering where the "svn" call is located which I
cannot see in these scripts.

There is some magic involved - there are the lines

,----
| head do
| url "https://svn.osgeo.org/grass/grass/trunk"
| end
`----

which specify the URL and homebrew is "doing the right thing" to
download the repo for compilation.

Rainer

Markus

--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

Rainer_Krug · February 6, 2017, 6:05pm

Vaclav Petras <wenzeslaus@gmail.com> writes:

On Mon, Feb 6, 2017 at 8:50 AM, Markus Neteler <neteler@osgeo.org> wrote:

> Otherwise, there is no problem at all with using the git repo.

Perhaps yes if that brings back the Mac tests at lowest cost

Assuming that the Homebrew repo will be tested separately, the question is if we want to bring in another dependency - OSGeo Subversion to GitHub sync - or if we want to keep
dependencies to minimum. For now, getting code from GitHub is the only way it works because of the broken SSL certificates, so sure we can use it, but that's for now.

I can look into these issues beginning of March but I agree that that
using the github would be the best solution and the homebrew should be
tested separately.

Rainer

--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982