Continuous Integration

[rgleason]

for Linux and Windows
Appveyor vs Travis CI

Learning----

https://www.reddit.com/r/learnprogra..._travisci_for/

So, writing tests for code is good, right? Tests validate that a program is correct.
But tests can fail. If we pick up somebody's pull request or make a quick fix somewhere, we might have broken our system. When you later go and check out the code, maybe you've just broken the system, but you won't find out unless you run the tests.
Continuous Integration is the idea of running all of the tests upon checkin and validating that the tests still pass. Some developers go a step farther and deploy their code immediately upon a successful integration test run. That's called continuous deployment.
Travi-CI is simply a website that provides free continuous integration. People like it because when you see the badge, you know that the code you're about to download is probably not currently broken, or at least not in a way that its tests can determine.

https://tomassetti.me/continous-inte...-and-appveyor/

https://www.slant.co/versus/627/2481...is_vs_appveyor

https://www.g2crowd.com/compare/appveyor-vs-travis-ci


https://www.software.ac.uk/blog/2016...vis-ci-windows

https://stackshare.io/stackups/appve...s-vs-travis-ci

https://www.hanselman.com/blog/AppVe...yToBehold.aspx

[rgleason]

Appveyor Docs
https://www.appveyor.com/docs/

Appveyor with Github
https://www.appveyor.com/docs/deploy...very-tag-build

[seandepagnier]

continuous integration is interesting but...

1) How to build for OSX?
2) How to build for all platforms like arm 32 and 64. and x86 32 and 64? Maybe travis cl can cross compile mingw binaries for windows as well.
3) Can windows build somehow not have to rebuild all of wxwidgets every time? Is there a way to cache this? It wastes a lot of cpu, takes long time for results, and wastes server bandwidth.
4) android?

[nohal]

Originally Posted by boat_alexandra

continuous integration is interesting but...

1) How to build for OSX?

By finishing the travis configuration. Look at https://github.com/nohal/iacfleet_pi...er/.travis.yml for an example. Did not bother including it in my recent PRs as it will have to be updated for O5 and wx3.1.

2) How to build for all platforms like arm 32 and 64. and x86 32 and 64? Maybe travis cl can cross compile mingw binaries for windows as well.

Travis sure can cross compile the mingw binaries for windows as well (What is the use case for them having the native builds? Other than generating confusion for the normal public who has absolutely no idea what the difference is.), for the rest we have PPAs on Launchpad, https://build.opensuse.org, Fedora build tools etc.

3) Can windows build somehow not have to rebuild all of wxwidgets every time? Is there a way to cache this? It wastes a lot of cpu, takes long time for results, and wastes server bandwidth.

Yes, look at https://github.com/OpenCPN/OpenCPN/b...r/appveyor.yml for an example.

4) android?

Android what? Build? Probably doable on Travis as everything else.

[seandepagnier]

Originally Posted by nohal

By finishing the travis configuration. Look at https://github.com/nohal/iacfleet_pi...er/.travis.yml for an example. Did not bother including it in my recent PRs as it will have to be updated for O5 and wx3.1.

I will wait for this.

Travis sure can cross compile the mingw binaries for windows as well (What is the use case for them having the native builds? Other than generating confusion for the normal public who

Compiling with a non-free compiler has the implication that the resulting program is technically not free, as we do not anymore know exactly what it might do. Maybe there are exactly zero users who care since they are after all, running windows.

has absolutely no idea what the difference is.), for the rest we have PPAs on Launchpad, https://build.opensuse.org, Fedora build tools etc.

Are these built with the incremental builds or only for each release? Maybe there is not much reason to, as typically if one linux platform succeeds all of them will.

Yes, look at https://github.com/OpenCPN/OpenCPN/b...r/appveyor.yml for an example.

Ok.

Android what? Build? Probably doable on Travis as everything else.

[/quote]
Yes. I would like to build plugins for android automatically in this way, and generate the apk for download.

[nohal]

Originally Posted by boat_alexandra

Compiling with a non-free compiler has the implication that the resulting program is technically not free, as we do not anymore know exactly what it might do. Maybe there are exactly zero users who care since they are after all, running windows.

There is also exactly zero people willing to do the publishing of two functionally identical products (multiplied by the number of plugins + the main package). If you wonder why, we may switch roles for the O5 release cycle...

Are these built with the incremental builds or only for each release? Maybe there is not much reason to, as typically if one linux platform succeeds all of them will.

I do the builds just for the releases. So far problems were rare enough not to do anything else. Nothing can prevent you from creating your own PPA, setting up a hook in git and submitting the build for every commit. IMO a waste of effort and electricity though and if you ask me, invest that time into checking your stuff with Coverity and actually fixing it...

Yes. I would like to build plugins for android automatically in this way, and generate the apk for download.

As I wrote, probably doable using Travis (And maybe Appveyor as well with likely more effort), but you will have to do it yourself.

[rgleason]

After reading your discusssion, I have two questions.
1. Does completing a travis ci or appveyor build successfully involve your having to wait for processsing and involve personnal computer time on your machine?
2. I can understand Pavel's point about maintaining two windows systems that do the same thing Mingw and MSVC. I just wonder if Mingw would be easier from a programming point of view, because we know MSVC is very picky.

Could there be a background "experiment" with Continuous Integration appveyor for Opencpn + some critical plugins to see if it would be an easier system to use? It would not be on the downloads page and would not interfere with the release process until everyone agreed that it was a better choice, and then you might switch over at the same time there was a wxWidget upgrade because all PI much be redone then?

Why do Windoze Users get such terrible characterizations? We just want things to work

Should I have upgraded to MSVC++ 2017 + wxWidgets 3.11 by now?
I found
https://github.com/nohal/OpenCPN/wik...n-Windows---O5

https://github.com/nohal/OpenCPN/wik...-Windows-build

Then I found this
https://github.com/nohal/OpenCPN/wik...--11-migration

NOTE FOR RICK GLEASON:

REMOVE THE LINKS TO THIS AND SIMILAR PAGES FROM THE DOCUMENTATION, PLEASE!!!!!!!!

How long has this been there?

Pavel, how the devil am I going to know that you put that there? Also, as Dave says, Don't shout.

You have my email and can send me a brief note, I usually can respond fairly quickly.


When I remove these links will you please remove this note?

This is just like being in a family!

[nohal]

Originally Posted by rgleason

After reading your discusssion, I have two questions.
1. Does completing a travis ci or appveyor build successfully involve your having to wait for processsing and involve personnal computer time on your machine?

No, it has nothing to do with your machine.

2. I can understand Pavel's point about maintaining two windows systems that do the same thing Mingw and MSVC. I just wonder if Mingw would be easier from a programming point of view, because we know MSVC is very picky.

No, mingw is not easier for a normal Windows developer.

Should I have upgraded to MSVC++ 2017 + wxWidgets 3.11 by now?

No, you should not.

Then I found this
https://github.com/nohal/OpenCPN/wik...-Windows-build

NOTE FOR RICK GLEASON:

REMOVE THE LINKS TO THIS AND SIMILAR PAGES FROM THE DOCUMENTATION, PLEASE!!!!!!!!

How long has this been there?

Exactly long enough for you to finally notice it.

Pavel, how the devil am I going to know that you put that there? Also, as Dave says, Don't shout.

Exactly the same way I'm supposed to know you fill the official documentation with my unordered and mostly unusable personal notes from a work in progress.

Pavel

[rgleason]

Removed
https://opencpn.org/wiki/dokuwiki/do...to_opencpn_482

Thanks

[zboss]

You are getting continuous integration and test driven development mixed up. TDD is a common aspect of CI but lots of devshops does one or the other. Don't even bring in devtestops.

What is most commonly misunderstood about CI and devops is that they are some how the wild west when in fact they are highly coordinated activities. The most effective CI/CD system compress the release trains down into a single push and everyone is developing off the latest code.

Also, CI/CD rarely works efficiently in legacy applications because they were not architected to support modern integration patterns. So most companies are either faced with refactoring the system to support a new pattern or they develop a new app and migrate clients.

Originally Posted by rgleason

for Linux and Windows
Appveyor vs Travis CI

Learning----

https://www.reddit.com/r/learnprogra..._travisci_for/

So, writing tests for code is good, right? Tests validate that a program is correct.
But tests can fail. If we pick up somebody's pull request or make a quick fix somewhere, we might have broken our system. When you later go and check out the code, maybe you've just broken the system, but you won't find out unless you run the tests.
Continuous Integration is the idea of running all of the tests upon checkin and validating that the tests still pass. Some developers go a step farther and deploy their code immediately upon a successful integration test run. That's called continuous deployment.
Travi-CI is simply a website that provides free continuous integration. People like it because when you see the badge, you know that the code you're about to download is probably not currently broken, or at least not in a way that its tests can determine.

https://tomassetti.me/continous-inte...-and-appveyor/

https://www.slant.co/versus/627/2481...is_vs_appveyor

https://www.g2crowd.com/compare/appveyor-vs-travis-ci


https://www.software.ac.uk/blog/2016...vis-ci-windows

https://stackshare.io/stackups/appve...s-vs-travis-ci

https://www.hanselman.com/blog/AppVe...yToBehold.aspx

[transmitterdan]

O built with MSVC Community Edition is not restricted as far as I know. We cannot distribute the sources for the MSVC runtime but that doesn’t mean that O isn’t still free. I don’t see this ever changing. Microsoft has fully embraced open source projects like O. They won’t go back on that I think.

[seandepagnier]

2. I can understand Pavel's point about maintaining two windows systems that do the same thing Mingw and MSVC. I just wonder if Mingw would be easier from a programming point of view, because we know MSVC is very picky.

since mingw is gcc, it tends to compile existing code that compiles on gcc with fewer changes than what msvc requires. It's about half the effort to support compared to msvc.

I have found bugs after building with mingw, because it uses an alternate compiler to build windows specific code which makes the sources more robust. In the same way, msvc also occasionally helps. I have also build with llvm on linux and found issues.

More compilers and platform combinations gives better code quality.

Originally Posted by nohal

No, mingw is not easier for a normal Windows developer.

It is easier for me, and I don't know what is a normal windows developer. It appears you and dave both have little interest in using mingw which is fine. also don't really care since it's windoze anyway. Just annoying to have to implement msvc specifics in every single plugin, but I can live with it.

Originally Posted by transmitterdan

O built with MSVC Community Edition is not restricted as far as I know. We cannot distribute the sources for the MSVC runtime but that doesn’t mean that O isn’t still free. I don’t see this ever changing. Microsoft has fully embraced open source projects like O. They won’t go back on that I think.

If we link with code that we do not have the source code to, then technically, our software is no longer free software, and this is also a violation of GPL. It does not matter static or dynamic linking is the same. It is for us to enforce this or not, and since we don't care it is "ok"

I met richard stallman in person and discussed this exact issue.

I do care that OpenCPN be free software, at least on free OS, but I don't care about non-free OS.

[transmitterdan]

Whether MAC or Windows no code can execute without linking to the underlying OS and BIOS. If Stallman wants to argue that no GPL license is valid on Windows or MAC he will be in a small minority. I think a strict read of the O GPL will tell you that there is no problem with the GPL license.

[seandepagnier]

Originally Posted by transmitterdan

Whether MAC or Windows no code can execute without linking to the underlying OS and BIOS. If Stallman wants to argue that no GPL license is valid on Windows or MAC he will be in a small minority. I think a strict read of the O GPL will tell you that there is no problem with the GPL license.

This is not the underlying OS or BIOS, but the MSVC runtime.

The same issue exists for non-free linux kernel modules such as closed source drivers. They are technically a violation of GPL, but the kernel developers allow it, so it's ok.

In any case, any software running on mac or windows cannot be considered safe, as the OS has unreasonable control over the user.

[nohal]

Originally Posted by boat_alexandra

It is easier for me

Nobody prohibits you from using mingw and maintaining support for it, of course. There just so far does not appear to be anybody wanting to share this fun with you. But there is nothing wrong about that as far as I can say, we all have our choice.

and I don't know what is a normal windows developer.

One using the Visual Studio toolchain he gets from Microsoft, the supplier of the OS.
There is also, due to the implementation of the toolchain, technically somewhat closer to what you use, group of normal macOS developers using Xcode and not even knowing it is just a GUI frontend to LLVM, LLDB and a couple of other open source tools.