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.

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

Add additional compilers and platforms to Travis testing #171

Merged
merged 2 commits into from Feb 27, 2020
Merged

Add additional compilers and platforms to Travis testing #171

merged 2 commits into from Feb 27, 2020

Conversation

noloader
Copy link
Contributor

@noloader noloader commented Feb 27, 2020

Hi Everyone,

This PR adds additional compiler and platform testing to Travis. It will probably help avoid surprises in the future. It is an inexpensive insurance policy that takes nearly no effort once setup. The trick is digging into the Travis docs to set it up. (It is a lot easier when someone provides a Travis config as a starting point).

We use a similar Travis config for Crypto++. I know Jack Lloyd uses a similar Travis config for Botan. In fact, Crypto++ uses Travis for Linux, OS X, Android and iOS testing.

On the downside, I have not been able to fully test it. I think GitHub is having some problems. When I try to enable Unbound testing on my GitHub fork, I get an error "An error happened when we tried to alter settings on GitHub. It may be caused by API restrictions, please review and add your authorized Orgs."

Travis is generous with opens source projects. They provide containers with two cores, and ask we keep jobs below about 80 or 100 or so. Unbound will be fine with a dozen jobs.

@gthess gthess self-assigned this Feb 27, 2020
@noloader
Copy link
Contributor Author

noloader commented Feb 27, 2020

Thanks @gthess. Sorry I could not run the tests before it landed on your desk.

OK, the first Travis results are good. Most platforms tested OK. The one failure is OS X.

You have several choices now. First, you can add OS X as an allowed failure so Travis will report success. So you can add this to the bottom of .travis.yml:

  allow_failures:
    -os: osx

OS X provides an antique version OpenSSL, so you will probably want to update it eventually so the test succeeds.

Second, you can use Brew to install an updated version of OpenSSL. That might looks something like this:

before_install:
  - |
    if [ "$TRAVIS_OS_NAME" = "osx" ]; then
        brew update
        brew install openssl
    fi

Third, you can fetch OpenSSL using curl, and build and install OpenSSL in the before_install recipe. The one sharp edge is, OS X provides curl out of the box, not wget.

The choice is Unbound's how to proceed.

@gthess
Copy link
Member

gthess commented Feb 27, 2020

Nice, thanks for this!
We were also thinking about the brew option. If the osx test passes this PR is ready.

@noloader
Copy link
Contributor Author

noloader commented Feb 27, 2020

Thanks @gthess.

I think we are close. Here is the failed configure message after the Brew install of OpenSSL.

checking for SSL... configure: error: Cannot find the SSL libraries in /usr/local/ssl /usr/lib/ssl /usr/ssl /usr/pkg /usr/local /opt/local /usr/sfw /usr

I'm thinking configure may need to look in /usr/local for Brew installs of OpenSSL on OS X. That is, headers are in /usr/local/include and libs are in /usr/local/lib. But it is just a guess at this point.

I asked a question on the Travis message boards at Where does Brew install OpenSSL on OS X?

gthess added a commit that referenced this pull request Feb 27, 2020
@gthess gthess merged commit e382b88 into NLnetLabs:master Feb 27, 2020
1 check failed
@gthess
Copy link
Member

gthess commented Feb 27, 2020

I did some tests and it seems that
/configure --enable-debug --disable-flto --with-ssl=/usr/local/opt/openssl/
works; merged it.
Thanks again!

@noloader
Copy link
Contributor Author

noloader commented Feb 27, 2020

@gthess,

Here's some reading on Travis and C projects. Another good page is Build Environments, where you can find what is available for Linux, OS X, Windows, etc. You can also find the environmental variables like TRAVIS_OS_NAME.

Generally speaking, use Bionic images unless you are testing an old compiler. Old compilers give trouble using Trusty and Xenial on PowerPC and s390x. Testing old compilers (like GCC 4.8) is fine, you just have to know what to expect.

Also, avoid the "matrix expansion". You do that by (1) avoiding the top level keys like os: and compiler:, and (2) specifying the exact job you want to run in jobs:.

For example, don't do this (this implicitly creates the matrix expansion):

# top level keys
os:
  - linux
  - osx
compiler:
  - gcc
  - clang

Instead, do this (this is what you are doing now):

# only job is top level
jobs:
  include:
    - os: linux
      compiler: gcc
      arch: amd64
      dist: bionic
    - os: linux
      compiler: clang
      arch: amd64
      dist: bionic
    ...

Avoiding matrix expansion will save you a lot of headaches down the road when you are trying to craft tests on platforms. Especially if you add Android and iOS testing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants