[Felgo User]

Hi there,

i am looking for a possibility to enhance my build process using a build server. I found this ressource:

https://felgo.com/build-server-3/build-server-improvements

but all links referenced in this side are dead. Also this project seems to host a build server on v-play owned machines. My preferred solution is to run a build server on my own ressources. So is there maybe a self-hostable version of this old reference? I think already some helper script for installation and setup would be nice. I found a github project providing exactly this for vanilla qt and android builds:

https://github.com/benlau/qtci

Maybe a v-play support at first only for android in such a way would be a step forward for good automated development processes.

[AlexFelgo Team]

Hi,

Cool that you bring up that discussion. The referenced blog post is talking about Felgo Build Server for Felgo version 1, a handy tool we had back before switching to Felgo 2 (and Qt 5), so that’s a little outdated and does not work with the current Felgo SDK. The good news is, we are actually working on that right now! 😎

I would love to discuss some requirements and ideas you have in mind about a build server:

You mentioned that you prefer an on-premise solution.

1.: Is your idea to have a self-hosted server instance that performs all builds in your local network or would you want to just build them on your local development machine?

2.: How many projects would you build in parallel approximately (speaking of different products in parallel, not time-wise)?

3.: And what are your requirements for distribution? Just a downloadable APK/IPA file or automated distribution to Google Play/App Store Connect / HockeyApp / etc?

Looking forward to the discussion!

Alex

[Felgo User]

Sorry for the late answer. I was really busy the last days. Thanks for involving direct feedback from the community. You guys rock!

First i try to answer directly your question:

1. I prefere to build on a local network machine (espacially using a docker image)
2. We have currently only one proof of concept v-play project. So i would say currently one. Additionally we have some productive pure Qt-projects, where we do not use v-play currently. When those get some mobile focus the number could raise instantly.
3. For the proof of concept state, downloadable APK, IPA files are sufficient. For productive deployment in another project state the store or hockay app deployment would be nice.

Secondly i will highlight some internal development details, which has impact to the build-server requirements:

We work agile using scrum and try to automate as much as possible using a continuous integration pipeline. In contrast to pure Qt desktop development, the mobile and v-play dev-stack is much more hard to handle.

To achieve the same workflow as for desktop Qt development, we would need:

1. current compiler stack for build-server builds –> enabling C++17 support (e.g. using the clang pipeline of the android NDK)
2. automatic build for all target plattforms –> dekstop, android, iOS
3. automatic test for all plattforms
   1. unit tests
   2. UI tests (using Qt internal UI tests, rendering against a offscreen plattform using the xvfb x11-virtual-frame-buffer)
4. integrated key handling to sign the build artifacts
5. integration into common CI tools like bamboo or gitlab-ci runner; running inside a docker container would be nice because it will instantially run in all CI-runner capable of handling docker
6. cmake support instead of qt-project file handling would be nice, because external dependency management of 3rd party external libraries are way more straight forward to handle

I also look forward to the discussion 🙂

Christian

[AlexFelgo Team]

Hi Christian,

Thanks for your great input!

 

Docker currently only supports building Android apps because of the nature of Docker, running containers as a Linux sub-system. For iOS apps, you still need a macOS host system. That’s a reason why we look into providing a hosted option in first place. For self-hosting (on-premise), this would mean that you would have to run the service on a macOS machine locally in your network.

1. Is a hosted service an alternative to your local environment approach (like integrating into CircleCI, GitLab Hosted Option or into our planned solution)?

 

Regarding your current workflow:

2. Which test frameworks do you use? Are you triggering tests via the build system or as own commands?
3. Do UI tests only run against Linux Desktop builds or are you also using UI tests on Android/iOS targets at the moment?
4. You are mentioning cmake, so you are not using qmake/qbs build systems for your projects?

 

Best,

Alex from Felgo

[Felgo User]

 1. Is a hosted service an alternative to your local environment approach (like integrating into CircleCI, GitLab Hosted Option or into our planned solution)?

Currently we do as much as possible on premise. We see two main advantages:

•  we can scale necessary performance requirements on in house existing hardware
•  we can keep all development data together controlled on own infrastructure is crucial for two reasons for us:
  • we have NDAs of external partners, where external hosting of project related internal development data can be critical
  • we can handle even GDPR related stuff; doing this on external infrastructure would complicate the development process
  • summarizing using external services handling our code, would lead us to asking and documenting of the question “Are we allowed to put the exact part of data there? Do we have to inform related persons? Do we need special contracts of the service provider?” –> the most of this questions can be omitted by hosting ourself

2. Which test frameworks do you use? Are you triggering tests via the build system or as own commands?

• We use currently QtTest to be able to do some kind of UI tests in addition to Unit-Tests. We start them with make check. On pure Qt projects without V-play we use cmake for our project and dependency management. There we encapsulate the QtTest into ctest.

3. Do UI tests only run against Linux Desktop builds or are you also using UI tests on Android/iOS targets at the moment?

• Currently we do the UITests against the linux desktop build. This was the easiest and fastest starting point to get tests in place based on our knowledge from desktop based Qt / QML projects. UI testing of mobile targets would be beneficial. Especially running inside the (x86) emulator, would bring alot more real world test behavior into our tests. If our app goes productive, we will focus this absolutely.

4. You are mentioning cmake, so you are not using qmake/qbs build systems for your projects?

• We have currently one project, where we test an idea if it is solvable via an mobile App. This is the only project where we currently use Felgo. For this project we use the preconfigured build system shipped by Felgo using the qmake build system.
• All other projects we develop are desktop based pure Qt projects, where we use a cmake based project configuration. We try to maintain our project structures as similar as possible, to benefit from shared knowledge between our projects. Therefore it would be beneficial for us to use cmake also for the Felgo based projects.

I wrote earlier:

“[…] we would need: current compiler stack for build-server builds –> enabling C++17 support (e.g. using the clang pipeline of the android NDK)”

• We noticed that our other external libraries like OpenCV, Boost, (pure Qt), STL, etc. are directly compilable from source. So we can benefit from a shared current compiler stack. For Android development using Felgo we have the problem, that we can only rely on the precompiled Felgo version shipped by the installer. The armv7 is compiled via gcc with libstdc++, which is depricated by the android NDK. To get modern C++(17) support, we should use the libc++ compilation using clang. Are there plans to ship a libc++ based compiled Felgo version in the near future? Or will it be possible to compile ourself, when subscibing to your developer program?

best,

Christian Günther

[AlexFelgo Team]

Hi Christian,

Thanks a lot for the additional input! So what I see is that you definitely would benefit from an on-premise build system with built-in support for testing frameworks. Here is some more input from my side:

2. Your GUI tests then trigger key and mouse events and compare widget states (like text, color, etc)? Or are you also comparing actual screenshots with predefined results (so on a “rendering level”)?

4. Now that The Qt Company deprecated Qbs this week, we are also looking closer into CMake support for Felgo projects (no timeline for that yet though).

Regarding Android NDK with clang/libc++: We already provide prerelease Felgo builds with clang support based on Qt 5.12 Beta for our enterprise customers. If that’s interesting for you, just shoot us a line at support@felgo.com for more information.

Best,

Alex from Felgo