search

epics-base / ci-scripts

Continuous Integration Scripts for EPICS Modules
Other
8 stars 18 forks source link

Version 2: multiple dependencies, settings files, caching of releases #9

Closed ralphlange closed 4 years ago

ralphlange commented 5 years ago

Major reorganization.

features:

ralphlange commented 5 years ago

I pushed the change that affects the API. The other changes - which are internal - will have to wait a few days (will be off line next week).

So: @mark0n and @dirk-zimoch, please test it for some more complex modules.

ralphlange commented 5 years ago

@mark0n , @dirk-zimoch: Möööp!

mdavidsaver commented 5 years ago

It might be friendly to error if $SETUP_PATH and/or $BASE_REPONAME aren't set. I decided to... simulate... a naive user who just updates my submodule w/o changing .travis.yml.

Taking your .travis.yml.example-full more or less verbatim I see a failure in the Base builds with clang++ or g++ w/ std=c++11 .

../../testApp/misc/testTypeCast.cpp:425:12: error: use of undeclared identifier
      'isnan'
    testOk(isnan( xfloat ), "Test cast double NAN to float NAN yields: %...

epicsMath.h is being included. I'm not sure what is going on here.

The RTEMS builds error because the older cross gcc doesn't understand -std=c++11.

The OSX build errors on readlink -f as apparently -f isn't supported.

The cross mingw64 build fails, though this is my problem. While apparently not necessary atm. , It would be a good idea to add g++-mingw-w64-x86-64 to the apt package list.

https://travis-ci.org/mdavidsaver/pvxs/builds/607303840

ralphlange commented 5 years ago

Almost there... just found that sed on MacOS also has a different syntax. Duh!

dirk-zimoch commented 5 years ago

I see this in mingw builds: $ mingw --version mingw: command not found

ralphlange commented 5 years ago

@mdavidsaver I think all your comments have been addressed now. If you feel like taking it for another ride.... thanks!

TBD: fix the RTEMS builds (OS_CLASS missing?), better logging in the terse format, improve documentation.

mdavidsaver commented 5 years ago

https://travis-ci.org/mdavidsaver/pvxs/builds/616796771

The same builds are failing, though RTEMS and OSX for different reasons (from a superficial glance).

dirk-zimoch commented 5 years ago

I have updated and use "trusty" now instead of "xenial". Now it fails in the host build of base 3.14.12.8: https://travis-ci.org/dirk-zimoch/StreamDevice/jobs/617079252#L557

dirk-zimoch commented 5 years ago

The mingw builds have: $ export TRAVIS_COMPILER=mingw which later leads to: $ mingw --version mingw: command not found

https://travis-ci.org/dirk-zimoch/StreamDevice/jobs/617079255#L508

ralphlange commented 5 years ago

I see this in mingw builds: $ mingw --version mingw: command not found

For the MinGW-cross-WIN builds the compiler is set to "mingw" in .travis.yml - mostly for having reasonable information on the job overview web page of the build.

Travis uses this setting (way before our scripts are called) when trying to get the compiler version printed - which fails because for our cross-MinGW there is no binary called "mingw" in the PATH. This output can safely (and should) be ignored.

ralphlange commented 5 years ago

RTEMS failures are fixed by 9df85ff.

ralphlange commented 4 years ago

Ok, I think this is ready to be merged now. Testing was extended and more detailed documentation added.

As far as I can see, the remaining build failures in specific jobs are due to unreleased fixes for the underlying issues in EPICS Base.

Any last words?

dirk-zimoch commented 4 years ago

Builds fail with the last update:

Module     Tag          Binaries    Commit
-----------------------------------------------------------------------------------
base       R3.14.12.8   rebuilt     922ed30 Set EPICS_DEV_SNAPSHOT for the final 3.14.12.8 release
fatal: Cannot change to '/home/travis/.cache/asyn-': No such file or directory
The command ".ci/travis/prepare.sh" failed and exited with 128 during .

https://travis-ci.org/dirk-zimoch/StreamDevice/jobs/621595180

ralphlange commented 4 years ago

Ok, found it. You're using the default setting for the tag (in this case 'master') - that case I will have to add to the tests, who are only verifying explicit release/branch setting. Thanks a lot!

ralphlange commented 4 years ago

@dirk-zimoch: your issue showing up when using the default should be fixed.

dirk-zimoch commented 4 years ago

All mingw builds fail: /usr/bin/x86_64-w64-mingw32-gcc: Command not found

dirk-zimoch commented 4 years ago

Can you remove the test in travis/utils.sh line 166, please. It fails on Windows. Or at least weaken it from -x to -f on Windows. (I guess Travis sets some variables to indicate that it runs on Windows.)

dirk-zimoch commented 4 years ago

Also ANSI colors seem not to work on Windows. In C one has to use SetConsoleMode() with the flag ENABLE_VIRTUAL_TERMINAL_PROCESSING. I am not sure how to do this from a script.

ralphlange commented 4 years ago

Windows on Travis is not supported. (Where did you get the idea it would?)

dirk-zimoch commented 4 years ago

https://docs.travis-ci.com/user/reference/windows It's "experimental", not "unsupported".

ralphlange commented 4 years ago

It's "experimental" on Travis, correct. But it's "unsupported" by the EPICS ci scripts.

Reason: no-one has ever managed (yet) to use the experimental Windows support on Travis to build EPICS Base. In this state the ci-scripts are not supporting it. Windows builds for EPICS are currently done using AppVeyor - I am working on integrating this on a separate branch of ci-scripts.

ralphlange commented 4 years ago

For the mingw builds, you might be missing the required packages: (from .travis.yml.example-full)

addons:
  apt:
    packages:
    # for all EPICS builds
    - libreadline6-dev
    - libncurses5-dev
    - perl
    # for clang compiler
    - clang
    # for mingw builds (32bit and 64bit)
    - g++-mingw-w64-i686
    - g++-mingw-w64-x86-64
    # for RTEMS cross builds
    - qemu-system-x86
ralphlange commented 4 years ago

As setup files should be working on Linux and macOS (using bash) but also for Windows/AppVeyor/Azure (using PowerShell), they have to be read instead of sourced by the shell.

dirk-zimoch commented 4 years ago

For the mingw builds, you might be missing the required packages: (from .travis.yml.example-full) ...

Oh, I thought they might be installed automatically when I select mingw.

ralphlange commented 4 years ago

It's a compromise. They could be added to the job lines in .travis.yml - which would make those complex and awful to look at. So we rather keep them in the general add-on package install part, which slows down all the builds by a few seconds, but keeps the job lines clean.

dirk-zimoch commented 4 years ago

I took out the Windows build and added the missing packages. Now only 1 job fails and that is in the asynDriver prerequisite.

ralphlange commented 4 years ago

Against my own version of Base that has the fixes to Base that I pushed to 3.15 and pvData earlier today, the test builds (of the example app with sequencer) work fine now: https://travis-ci.org/ralphlange/ci-scripts/builds/623651174