Answers: <p>One of the major advantage of the container technology is standardisation: easily replicating the same environment wherever a specific container is used, be it, for example, on your own machine during development or on the CI machine during the execution of the CI/CD pipeline.</p>
  
  <p>Building and using custom containers is a pretty standard way of including OS-level dependencies (like libraries and toolsets, for example) which aren't included in a service provider's default container images. Depending on the provider the choices for the base image you'd use <em>might</em> be limited.</p>
  
  <p>If you have a CI/CD provider which accepts custom-built containers (not all of them do, at least not yet) and you can meet their custom container restrictions (if any) then building the custom container for your case is IMHO a valuable investment. Not only for the CI execution, but even for developing of your app and ultimately for showcasing the container technology as a development technology itself :)</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-04-19T05:35:38.650Z
Answers: In the end this is how I put it up. Jenkins, buddy and Travis all allow users to specify a container setup, which is usually a linux machine, with additional install directives to download qt-specific binaries and tools. The difference is that Travis runs them every time the machine is booted up while buddy seems to cache the machine somehow. However, this setup allowed me to implement relatively easily my CI.
Answers: phagio
Answers: CC BY-SA 4.0
Answers: 2019-03-02T17:36:34.967Z
Answers: 2019-03-02T17:36:34.967Z
Answers: Dan Cornilescu
Answers: <p>You could use Jenkins along with Gitlab for your CI. Both are free. As far as the Qt project goes, you could use the <code>sh</code> or <code>bat</code> steps to run qmake, or cmake for that matter, from within the build job.</p>
  
  <p>There are also a lot of plugins to extend Jenkins and integrate it with Gitlab. This includes plugins that allow you to trigger builds when pushing to a particular branch or even generating the build badge you'd like to have. See: <a href="https://wiki.jenkins.io/display/JENKINS/Embeddable+Build+Status+Plugin" rel="nofollow noreferrer">Embeddable Build Status Plugin</a></p>
  
Answers: CC BY-SA 4.0
Answers: 2019-04-18T19:30:46.877Z
Answers: 2019-04-18T19:30:46.877Z
Answers: Argyle
Body: <p>To build up my portfolio I'm writing an application to showcase all the best practices I'm aware of, including unit tests and continuous integration.</p>
  
  <p>The project was originally started in C++, and I took advantage of buddy.works to compile it and run my tests there. Managing <code>CMakeLists</code> was a pain but I endured for the greater good.</p>
  
  <p>After a while I noticed that Qt would have been a better fit for my purposes. Being this a non-commercial open source project I'm allowed to use Qt Creator for free. However, buddy.works (and almost all other free CI tools) only allow bare <code>GCC</code> build environments. In my case I'd need a fully configured Qt environment, as when I install the IDE, plus Android SDK and NDK.</p>
  
  <p>I see buddy.works allows to run commands in a "private container", but I'm not sure if building a container myself (something I'd start looking into if I knew this would work).</p>
  
  <p>I guess the safest choice would be to rent an Amazon EC2 instance, install on that everything I need (Qt, SDKs, Jenkins) and configure it to communicate with my GitHub or Bitbucket, but it would cost me (and I can't say how much exactly). I expect the CI process to only run like thrice per week, with an average build time that at most would take half an hour. I also liked the idea of the green build badge in the readme file, something buddy.works offered and with an EC2 instance shutting down could be trickier to achieve (if I was to purchase an instance that boots every day, runs CI and shuts down). However, a free alternative would be much appreciated.</p>
  
  <p>Any hint about this? Thank you very much.</p>
  
Comments: CC BY-SA 4.0
Comments: 2019-03-02T15:20:38.150Z
Comments: Absolutely not sure but perhaps gitlab has something that works for qt too
Comments: Marged
Comments: CC BY-SA 4.0
Comments: 2019-03-02T19:03:39.150Z
Comments: As mentioned by Marged, you could use Gitlab as your source control instead of GitHub. Would save you all of the cost and would be free as a docker alternative to your situation. Plus, since both would be running on AWS, they can talk to each other and help to trigger the auto build too. Once you get your hands dirty, you should be able to figure out the intricacies involved in this.
Comments: Karthik Venkatesan
Tags: <continuous-integration><containers><amazon-ec2><software-engineering>
Title: What is the cheapest way to get CI for a Qt project?
UserDisplayName: phagio
ThreadText: # What is the cheapest way to get CI for a Qt project?
  
  (Asked by: username_0 on 2019-03-02)
  
  To build up my portfolio I'm writing an application to showcase all the best practices I'm aware of, including unit tests and continuous integration.
  
  The project was originally started in C++, and I took advantage of buddy.works to compile it and run my tests there. Managing `CMakeLists` was a pain but I endured for the greater good.
  
  After a while I noticed that Qt would have been a better fit for my purposes. Being this a non-commercial open source project I'm allowed to use Qt Creator for free. However, buddy.works (and almost all other free CI tools) only allow bare `GCC` build environments. In my case I'd need a fully configured Qt environment, as when I install the IDE, plus Android SDK and NDK.
  
  I see buddy.works allows to run commands in a "private container", but I'm not sure if building a container myself (something I'd start looking into if I knew this would work).
  
  I guess the safest choice would be to rent an Amazon EC2 instance, install on that everything I need (Qt, SDKs, Jenkins) and configure it to communicate with my GitHub or Bitbucket, but it would cost me (and I can't say how much exactly). I expect the CI process to only run like thrice per week, with an average build time that at most would take half an hour. I also liked the idea of the green build badge in the readme file, something buddy.works offered and with an EC2 instance shutting down could be trickier to achieve (if I was to purchase an instance that boots every day, runs CI and shuts down). However, a free alternative would be much appreciated.
  
  Any hint about this? Thank you very much.
  
  **Tags:** continuous-integration, containers, amazon-ec2, software-engineering
  
  > **Comments:**
  > **username_1**: Absolutely not sure but perhaps gitlab has something that works for qt too  
  > **username_2**: As mentioned by username_1, you could use Gitlab as your source control instead of GitHub. Would save you all of the cost and would be free as a docker alternative to your situation. Plus, since both would be running on AWS, they can talk to each other and help to trigger the auto build too. Once you get your hands dirty, you should be able to figure out the intricacies involved in this.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2019-03-02. Score: 2 | Accepted answer
  
  One of the major advantage of the container technology is standardisation: easily replicating the same environment wherever a specific container is used, be it, for example, on your own machine during development or on the CI machine during the execution of the CI/CD pipeline.
  
  Building and using custom containers is a pretty standard way of including OS-level dependencies (like libraries and toolsets, for example) which aren't included in a service provider's default container images. Depending on the provider the choices for the base image you'd use *might* be limited.
  
  If you have a CI/CD provider which accepts custom-built containers (not all of them do, at least not yet) and you can meet their custom container restrictions (if any) then building the custom container for your case is IMHO a valuable investment. Not only for the CI execution, but even for developing of your app and ultimately for showcasing the container technology as a development technology itself :)
  
  > **Comments:**
  > **username_0**: In the end this is how I put it up. Jenkins, buddy and Travis all allow users to specify a container setup, which is usually a linux machine, with additional install directives to download qt-specific binaries and tools. The difference is that Travis runs them every time the machine is booted up while buddy seems to cache the machine somehow. However, this setup allowed me to implement relatively easily my CI.  
  
  ---
  
  ### Answer by username_4 on 2019-04-18. Score: 1
  
  You could use Jenkins along with Gitlab for your CI. Both are free. As far as the Qt project goes, you could use the `sh` or `bat` steps to run qmake, or cmake for that matter, from within the build job.
  
  There are also a lot of plugins to extend Jenkins and integrate it with Gitlab. This includes plugins that allow you to trigger builds when pushing to a particular branch or even generating the build badge you'd like to have. See: [Embeddable Build Status Plugin](https://wiki.jenkins.io/display/JENKINS/Embeddable+Build+Status+Plugin)
  
  
  ---
  
  