Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Expand travis tests to multiple Linux distros #839

Open
7 of 12 tasks
berkowski opened this issue Jan 15, 2020 · 17 comments
Open
7 of 12 tasks

Expand travis tests to multiple Linux distros #839

berkowski opened this issue Jan 15, 2020 · 17 comments

Comments

@berkowski
Copy link

berkowski commented Jan 15, 2020 •
edited
Loading

I'd like to help expand MB-System's automated tests to more Linux variants. Getting automated builds for MacOSX or Windows would be out of scope for this effort, but the result should not prevent making those targets available in the future.

Desired coverage

We shouldn't look to cover every distribution under the sun for tests. Given the little traffic I've paid attention to I have seen at least the desire for the following:

  • Tests with distrubtion-standard versions
    • Ubuntu 19.04 (Disco) with default versions of gcc, gdal, gmt
    • Ubuntu 18.04 (Bionic) with default versions of gcc, gdal, gmt
    • Ubuntu 16.04 (Xenial) with default versions of gcc, gdal. GMT built from 6.0.0 sources
    • CentoOS 7 with default versions of gcc, gdal, gmt.
  • Tests with "latest" versions of PROJ (6.3) and GMT (6.0)
    • Ubuntu 18.04 (Bionic)
    • CentOS 8 (CentOS 7 sqlite3 version too old for PROJ 6)
  • Other test targets
    • Some distro with clang?

If there are other targets or combinations (such as building against packages available in ubuntugis) they can be added.

Approach

We'll need to use docker images since some of the desired linux targets are not provided as built-in distributions for travis-ci. Using docker images will also help automate keeping efforts such as #807 up to date.

Create a separate repository for MB-System dockerfiles

This would be the simplest way forward. Docker Hub can monitor a repo and automatically build multiple docker images any time the repo changes. A standard README file will also be used for Docker Hub's landing page for the images to help users decide which image is right for their use.

However, making tagged releases would require coordination between this separate repo and the main MB-System code repo.

Keep Docker files in main MB-System repo

Keeping everything in the same repo eliminates the need for extra coordination but is more complex. QGIS follows this model and I've been able to replicate something similar for MB-System. The travis-ci machinery to get this working is more complex, but nothing a detailed README shouldn't be able to cover. The current workflow looks like this:

  • Docker images with MB-System build dependencies are built weekly as travis-ci cron jobs and pushed to hub.docker.com
  • MB-System build tests run on every push on master (or PR, etc.) and pull the docker images with all the build dependencies from hub.docker.com

Discussion Points

  • What build targets do we want?
  • Which approach is most appropriate
  • How to hand over/test hub.docker.com credentials during PR
@berkowski
Copy link
Author

@schwehr, any thoughts? Builds are ticking over at https://travis-ci.com/berkowski/MB-System . Docker images are at https://hub.docker.com/r/zberkowitz/mbsystem-deps/tags . The framework for the single-repo approach seems to be working, so figuring out what you'd like for coverage and when things are built would seem to be the next step.

@dwcaress
Copy link
Owner

dwcaress commented Jan 17, 2020 via email

@berkowski
Copy link
Author

Dave,

Right now I'm just using whatever is available as "standard" for each repo, except for Xenial which doesn't have a new enough version of GMT:

  • Ubuntu 19.04
    • GCC: 8.3.0
    • PROJ: 5.2.0
    • GMT: 5.4.5
  • Ubuntu 18.04
    • GCC: 7.4.0
    • PROJ: 4.9.3
    • GMT: 5.4.3
  • Ubuntu 16.04
    • GCC: 5.4.0
    • PROJ: 4.9.2
    • GMT: 6.0.0 (from source)
  • CentOS 7
    • GCC: 4.8.5
    • PROJ: 4.8.0
    • GMT: 5.4.4

I think if you want to test against specific combinations of PROJ and GMT it'd be best to pick a single distribution and install those project versions from source. That's easily doable.

@dwcaress
Copy link
Owner

dwcaress commented Jan 17, 2020 via email

@berkowski
Copy link
Author

Sure. I'll start putting together two more images with the intention on tracking the latest versions of PROJ and GMT on Ubuntu and CentOS and update the list.

@schwehr
Copy link
Collaborator

schwehr commented Jan 17, 2020

Anything with a 2nd config is better that the single configuration that we have now, so wishing... :)

My wish for the short term would be to have builds that cover at least once the following. The GEOS CI system builds 33 different configs, but that's nuts.

  • MB-System configs
    • With gsf, with trn*, default debugging and optimization (-g -O2)
    • disable-gsf, without trn, -g0 no debugging, -O3 aggressive optimization, -DNDEBUG
  • Compiler
    • recent llvm/clang
    • recent gcc
  • OS
    • ubuntu 20.04LTS
    • ubuntu 18.04LTS
    • CentOS something
    • Mac OSX whatever is easiest on Travis
  • PROJ
    • 6.3
    • 5.[2-9].[0-9]
    • 4.9.?
    • Eventually Proj 7
  • GMT
    • 6.x
    • 5.4.x

I think we should not have a Ubuntu 16.04LTS build. And as soon as there is an Ubuntu 20.04LTS, we should not have 19.04 or 19.10.

@berkowski
Copy link
Author

I've got an image with Ubuntu 18.04 using PROJ 6.3, GMT 6.0.0, and GDAL 3.0.3 now. CentOS 7 would require building sqlite3 from sources to satisfy PROJ 6.3 requirements. The machinery is there for CentOS 8, but I guess I'd like to see what their pre-built packages are going to look like first.

For selfish reasons I'd like to keep Ubuntu 16.04 on the list, though I don't think it needs to be built every push to master. I'd be quite happy with it being built only for new tag releases as part of the PR approval. Could even make it "fail ok"

I think the individual MB-System config builds (-O2, -O3, etc) should use a single base image, along with the clang target and the build case against the latest PROJ and GMT. Do you have a preference?

Anything with a 2nd config is better that the single configuration that we have now, so wishing... :)

My wish for the short term would be to have builds that cover at least once the following. The GEOS CI system builds 33 different configs, but that's nuts.

* MB-System configs
  
  * With gsf, with trn*, default debugging and optimization (-g -O2)
  * disable-gsf, without trn, -g0 no debugging, -O3 aggressive optimization, -DNDEBUG

* Compiler
  
  * recent llvm/clang
  * recent gcc

* OS
  
  * ubuntu 20.04LTS
  * ubuntu 18.04LTS
  * CentOS something
  * Mac OSX whatever is easiest on Travis

* PROJ
  
  * 6.3
  * 5.[2-9].[0-9]
  * 4.9.?
  * Eventually Proj 7

* GMT
  
  * 6.x
  * 5.4.x

I think we should not have a Ubuntu 16.04LTS build. And as soon as there is an Ubuntu 20.04LTS, we should not have 19.04 or 19.10.

@schwehr
Copy link
Collaborator

schwehr commented Jan 18, 2020

My pref would be Ubuntu 20.04LTS Focal if that's possible. Assuming that it's not still a mess from development

@berkowski
Copy link
Author

Ubuntu Focal doesn't seem too bad and I think I've gotten most of the linux build iterations working now. I've put together a few tables of what's being built at

https://github.com/berkowski/MB-System/blob/master/ci/README.md

@schwehr
Copy link
Collaborator

schwehr commented Jan 19, 2020

Very cool! But, GDAL 1? Eeek. That's really scary. We should probably put something in the MB-System configure that just says no to GDAL < 2. There were literally thousands of bugs fixed since then.

@berkowski
Copy link
Author

I'd only ask that you add the GDAL check after making a final 5.7.6 release as we need the EM2040 capability.

At this point it seems like the major linux targets have been addressed. If someone wants to do a quick writeup of how they compile from source on OSX I can add that process too. Otherwise I think we're at the point to start the PR process.

There's still work to do, like migrating the images to a new account on hub.docker.com and creating some new API keys for the travis config, but those can be tickboxes in the PR.

@schwehr
Copy link
Collaborator

schwehr commented Jan 19, 2020 via email

@berkowski
Copy link
Author

It's not that the EM2040 needs gdal 1.x, it's just that the Sentry AUV switched to the EM2040 and we're still using 16.04. There is the desire to move to a newer Ubuntu but no definite plan. Introducing the GDAL version requirement would force us to either use the last-good (for us) beta version or an unplanned update to our processing OS.

@schwehr
Copy link
Collaborator

schwehr commented Jan 19, 2020

Ok. Makes sense to not actively ban GDAL less than 2. However, as a maintainer of GDAL, I strongly urge you to make a plan to upgrade GDAL.

@dwcaress
Copy link
Owner

GDAL is only in the mix because it is required by GMT. MB-System does not make any GDAL calls directly, and in common usage does not trigger any use of GDAL through GMT. This could change of course, but for now what version of GDAL is there is really a GMT package manager issue.

@berkowski berkowski mentioned this issue Jan 21, 2020
Merged
7 tasks
@berkowski
Copy link
Author

I hadn't expected #866 to be merged so quickly without migrating the Docker images to an MB-System controlled account. I don't mind keeping them there for now but I figure at some point you'll want to "own" the whole stack.

I'm going to make a small PR to ensure that docker images are only built by travis when triggered by dwcaress/MB-System and close this issue.

@berkowski
Copy link
Author

PR mentioned above is up at #868

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@schwehr @berkowski @dwcaress