When deploying to multiple nodes, shouldn't we build the project on each node? why specifying BUILD_HOST in config file?
The project is built only on the build node, not on each node. According to the documentation :
For build commands the following configuration variables must be set:
APP: the name of your release which should be built
BUILD_HOST: the host where to build the release
BUILD_USER: the local user at build host
BUILD_AT: the directory on build host where to build the release. must exist.
The built release is then copied to your local directory .deliver/releases and can then be delivered to your production servers by using one of the deploy commands.
Related
First of all, I'm completely new in CI.
I am trying to set up a Jenkins to build several C++ projects I am hosting on my own Gitea instance.
The applications I want to add to my Jenkins build pipeline are mostly Qt or MSBuild projects.
I have installed the MSBuild plugin for Jenkins, however I couldn't find a Qt plugin.
Since the Jenkins docker container runs inside a Linux environment and runs on Linux itself too, I couldn't find out how to make Jenkins build MSBuild (.sln) or qt (.pro) projects.
How do I have to configure Jenkins to make it build MSBuild or Qt repositories?
Do I have to create makefile or CMakeLists files?
My goal is to have automated release builds inside my repositories built using my Jenkins docker container running on my Linux machine.
I really couldn't find a useful tutorial or explanation on this.
Thanks a lot in advance.
Background
I was using a laptop with openSUSE Leap 15.1 to develop a Qt app. I upgraded to openSUSE Tumbleweed. Now I realize that library versions which my app is dependent upon are not available for Tumbleweed. Now I have these options:
Reinstall openSUSE Leap 15.1 (or maybe 15.2?)
Set up a development environment with some Docker images
Set up a development environment with a virtual machine
Unavailable dependencies: grab their binary packages directly and install them manually on openSUSE Tumbleweed
...?
Question
About 2nd option i.e. Docker.
It's known how to use Docker to deploy the app. You set up the development container with all the dependencies and run some deployment scripts with it.
However, I don't know:
Is it possible to set up Docker containers in a way that Qt Creator debugger can be used for development? If I use Docker, would I be able to step through the code with Qt Creator debugger?
Is this scenario possible:
Pull an openSUSE Leap 15.1 Docker image
Set up a bindmount volume that links the /usr/lib64/ directory from inside the container to the ~/leaplib directory on the host machine. It means ~/leaplib:/usr/lib64/
Do the same for development headers i.e. ~/leapinclude:/usr/include/
Bindmount procedure is explained here
Install all the Qt project dependencies on the openSUSE Leap 15.1 container
Therefore, all dependency libraries and header files would be installed inside the container bindmount volumes
Inside Qt Creator project on the host machine, add ~/leaplib to library path
Inside Qt Creator project on the host machine, add ~/leapinclude to include path
The Qt project source code repository is of course on the host machine
Use Qt Creator to open project repository source code
You should be able to develop and debug the code with Qt Creator debugger, right?
The above plan is not tested yet. Not sure if it would work. Any idea? Am I missing something?
Another scenario:
Make use of docker-compose and Dockerfile suggested by #DavidMaze
Create a docker-compose.yml file defining custom bindmount volumes to be able to share data between container and the host
Create a Dockerfile starting with FROM opensuse/leap:15.1
Install all the dependency packages inside Dockerfile with zypper --root /usr/local/
Needed container data would be inside /usr/local/lib64/, /usr/local/lib/ and /usr/local/include/
Share needed container data with the host by copying data to custom bindmount volumes defined inside docker-compose.yml file
Add bindmount volumes to Qt Creator library path and include path
Use Qt Creator to debug the source code in the host machine
Is something missed?
currently our process works, but it takes too much time due that the fronend Ember app needs to be build into every single environment we have ( 5 environments ). because we never know which environment will be available when we release it.
we intend to add even more environments because every developer should have his own working development environment. (because of the backend)
how we do it, is that we create a frontend build and a backend build which creates artifacts.
now the frontent build takes around 2 minutes for every environment.
ember build --env=test and ember build --env=acceptance and ember build --env=development ... and more
when the artifacts are created we then create the release picking the correct ones depending on which environment we release (this done via release pipeline).
my question is can we make a frontend ember build somehow not depending on the environment?
i would like to note that we are using azure service fabric.
I don't think there is anyway around multiple Ember builds because each one will be different (i.e. production vs. development).
You can batch together each build inside one CI build/build task and produce artifact(s) to be used in your release pipeline.
Run the following command once for each environment you have (assuming you are using Ember-CLI) sequentially in one build task.
ember build --environment={{YOUR-ENV-HERE}} --output-path="dist/{{YOUR-ENV-HERE}}/"
You can then either upload the entire dist/ folder as an artifact and scope each environment in your release pipeline to the corresponding artifact subdirectory, or you can upload each folder inside /dist as an individual artifact and scope each environment in your release pipeline to its corresponding artifact.
only the configuration it changes. basically the api endpoints
I'm a newer to Qt project,strange to its project structure.
I have used jenkins+git+github+MSBuild+xUnit to build CI for VS project in windows.
Now my job is to configure jenkins so that it can auto build and test my qt project(in Ubuntu).
However,it seems there is few information about "jenkins build Qt project".
I don't know which plugins should I use on jenkins and how to configure them.
Can you show me how to do that?(I use Ubuntu 16.04)
I have read this blog,and try to run that way:
https://www.peter.hartmann.tk/single-post/2015/06/17/Minimal-Continuous-Integration-for-Git-projects-with-Jenkins-and-a-Qt-example
In this blog,it use "qmake && make && make check" to do all the thing(build and test) without installing any plugin.what does this command do?Does it work for all Qt project?
What's more,in Ubuntu,can I pack my Qt project using jenkins?If yes,how to do that?(Windows can pack qt project as .exe file, Ubuntu pack as what kind of file?)
I'll just link to already existing materials, which there's plenty of.
In general there's three main steps in what you want to do:
Trigger Jenkins build after git push: How can I make Jenkins CI with git trigger on pushes to master?. That gives you Jenkins job execution (that at this point does nothing) after each git push automatically.
Pulling changes from SCM - that is a ready step within regular Jenkins project that you just click through.
Building your project - in case of QT project which can be built from command line (Compile a Qt project from command Line) you can add this as a simple shell command build step in Jenkins.
Optionally you can then run tests on the result, store your artifacts after a successful build and/or trigger email notifications on failed builds.
As for storing artifacts - there's a ready plugin for that (https://wiki.jenkins.io/display/JENKINS/Compress+Artifacts+Plugin).
I've modified a .jsp file in the org.wso2.carbon.identity.entitlement.ui package, in order to customize the server for my purposes.
The problem is that when I build the project with Eclipse, the build is successful, but I don't understand how I can actually run the compiled code. How can I do it?
Once you build the project with maven, in the target directory you will find the jar (OSGi bundle). In your IS Server under /repository/component/patches, create a new directory something similar to "patch0100". Copy the jar inside this "patch0100" directory and restart the IS server.
The number in the patch directory (0100 in this case) is important. If you put the same jar to a patch directory with a higher number, say pactch0200, that particular jar with override the earlier one. That's how patching works in WSO2 Carobon Server, which is the platform on which the products are built.