Is there a way/plugin to integrate the new Xcode service and/or the new Apple CI with Jenkins?
Why?
A main issue with having a Jenkins server + an OSX build slave connected via ssh is that Unit Tests do not work, as the iOS Simulator needs a graphical environment which is not present in this configuration.
I hope that it is possible to integrate the Xcode service (which supports Unit Testing) with Jenkins.
It could be that using the Apple CI will be enough for my needs, but this question aims at the integration of the Xcode service with Jenkins.
What I do already know
I have experience with the existing Xcode Jenkins plugin, but it seems not to support the brand new Xcode service or the new Apple CI. I'm especially keen on unit testing via CI (which did not work properly over a ssh session with the old way).
What I want to know
I'd like info on the following issues currently not working with Jenkins and an ssh connected build slave:
Unit Tests on a headless system
Acceptance tests with Frank or similar
Automatic Provisioning Profile updating (Apple CI does that)
And info on things that currently do work fine with Jenkins and an ssh connected build slave and still should work with an Xcode service integration:
Builds of different build configurations (Release, Debug, TestFlight) / schemes
Automatic Build number increment
(With Jenkins I can set the build number in my project to ${BUILD_NUMBER}, and Jenkins sets this environment variable according to its build number. When the Apple CI does the builds most probably it will set the build number instead.)
Handling/synchronization of Build number between Jenkins & Apple CI
Accessing build products of the Apple CI from different Jenkins Jobs
e.g. for a Job to upload to TestFlight
Backup of builds
Automatic builds on git push to a specific branch
E-Mail notifications
Some additional questions/hints
I'm not sure whether the Apple CI == Xcode service or if the Apple CI just uses the Xcode service. In the latter case the Xcode service just would be like an intelligent build slave, and Jenkins maybe could use that to do builds and tests, but manage build numbers and products by itself.
I'm aware that the Apple CI is an separate CI, and integrating several CIs with each other is not the most easy or useful way to go. I just fear that the Apple CI is not flexible enough for my needs (see above), and that the old way with Jenkins bears some problems (see above).
I believe you are going to have to choose either jenkins or xcode server, not both. I don't know much about xcode server, but I do know about jenkins and xcode 5.
Builds with different configurations:
In the xcode plugin, you can set the scheme to use.
Automatic Build Number Increment
I added a parameter to my jenkins job called XCODEBUILDNUMBER. And whenever I start a build, I simply copy the build number out of my xcode project (I increment it manually. Mine looks like 080813A) and paste it into the XCODEBUILD parameter. I use this to name my output files, etc. There are plugins for jenkins that can automatically increment your build number, but they don't integrate, or sync with xcode.
Handling/synchronization of Build number between Jenkins & Apple CI
As I said before, I don't know of a way to sync the build numbers, but I just thought of a possible solution. You could use the command line tool plistbuddy, to set the build number in your info.plist, as a build step in your jenkins job.
Unit Tests
I have not successfully made unit tests work with Xcode5, but I know that the xcode plugin for jenkins supports it. I believe that the absence of the "Test After Build" key in the project settings may have something to do with it. If you make it work, i'd love to know. (I am also keen on making this work)
Acceptance Tests
From what I can tell, Frank is a command line tool. You can easily integrate it into your Jenkins job, and I believe that it will fail the build if your tests don't pass.
Accessing build products of the Apple CI from different Jenkins Jobs
Not completely sure what you mean, but with jenkins you can archive your build product (a .ipa), for later download and upload to a service like testflight. Again, I don't know much about Xcode Server (CI).
Backup of builds
As I said before, jenkins can archive your build product. Also, I use the the ${BUILD_NUMBER} variable in my build products directory, so I have a different directory for each build. This directory is also backed up to my Time Machine, and important builds copied to my web directory.
Automatic builds on git push to a specific branch
With the jenkins git plugin, you can make jenkins poll your scm in a interval specified by you, and can trigger a build on a change.
E-Mail notifications
I am sure that there is a plugin for this. (that emails you when a build failed/succeeded. in fact, this may be built-in)
In Closing
The xcode CI is a full independent CI, that may be hard to integrate with jenkins. Personally, I would recommend jenkins simply due to its extendability. Sorry I don't know much about Xcode Server.
I've got unit tests running in Jenkins with Xcode 5 on my OS X build slave. Instead of using the Xcode plugin, I run as an execute shell build step:
xcodebuild test -scheme <scheme> -configuration Coverage -sdk iphonesimulator7.0 -destination OS=7.0,name="iPhone Retina (4-inch)"
My coverage configuration is the exact same as my Debug config, except Generate Test Coverage Reports is set to YES, and Instrument Program Flow is set to YES. This is done so test coverage files are created. Due to a bug in Xcode 5, I call __gcov_flush(); in the tearDown of all my tests. I pipe the output of this xcodebuild command into ocunit2junit to get test reports in Jenkins.
Related
We are currently moving from our legacy build server to Jenkins.
In our previous system, we had the following system:
You don't directly build a release version, but you build a "BETA".
After you are satisfied with the result, you can promote the "BETA" to "RELEASE".
For that, you click on the build (the actual pipeline run) and click on a button "BETA to RELEASE".
This button triggers a script to do the actual promotion (the actual steps are irrelevant for this question).
For Jenkins, I haven't found something like that yet. To be precise: I would like to choose one of the successful builds and then click on some kind of button to promote the results of that build to RELEASE. So even if I have build 1.2.0-BETA, 1.2.1-BETA and 1.2.2-BETA, I can choose 1.2.1-BETA and release it to 1.2.1.
What would be a good approach for this?
I would like to suggest the following
We can create a Jenkins pipeline for an Application (Ex: API Services). In this API deployment pipeline, there are many stages,
Get source code from GIT
Restore the dependent libraries
Build the solution & generate the deployment artifacts (with suitable version , ex: Beta 1)
Deploy the artifacts to Dev environment
We have a wait time (ex: 1 day) using a timeout in Jenkins pipeline
Once the dev team validates the build and finds that it is suitable for promotion to QA
they click on Approve
Approved build gets updated with the version (ex: QA-1)
Await QA team approval
Once approved, move to production.
Reference Link: https://jenkins.io/doc/pipeline/steps/pipeline-input-step/
Example Snippet of pipeline code
stage("Validate before Apply") {
timeout(time:30, unit:'MINUTES') {
input 'Are you sure to promote this build to QA?'
}
}
I think that Promoted Builds Plugin is what you need.
Basically, after installing the plugin, you create a job that build your BETA version and in its configuration, you set up a promotion, manually approved, that run your promotion script.
Depending of your need, you maybe configure as well the number of days you want to keep the builds of the job.
I am looking for implementation of CI/CD in to my current project here is what i think will work.
Environment consists of
- Jenkins
- git
- docker
- gradle
- Linux servers
- Sonar
- Ansible.
Each tool will be used as following.
Git:- Developers will push there code to this CVS.
Jenkins:- On detecting Check-in Jenkins will trigger a build and will deploy to one of the server.
Sonar:- will be used for code coverage and will check the code before building the same through Jenkins.
ansible:- ansible will be used to quickly prepare added nodes so that code can be deployed to them.
Docker in case if we need fresh test environments every time we can use docker+ ansible combo for doing the things.
Flow of work will be
User run unit test cases on his machine and commits the code to the server.
Jenkins will pull the code from git and will run sonar on the same and will generate reports.
jenkins will create build and will deploy the same on dev server.
A jenkins job will run and will perform the integration testing on the dev server
Any other automated tests can be run.
Finally builds pushed to next server using Jenkins.
I will use shell commands inside Jenkins to push compiled code from one server to another.
In my this scenario can some one answer me following.
Where will sonar get fit and how to use the same?
I see there are CD tools, cant i push compiled code to the servers using shell scripts written inside the Jenkins jobs to automatically deploy the things? What extra benefits a CD tool provides
Is is wise to create fresh test environment or we can keep using the old one again and again?
Will this complete CI/CD?
can someone share there implementation
You say you plan to use Git. I'll outline a scenario using Git on GitHub
Developers push code changes here as pull requests
The SonarQube GitHub Plugin kicks off an initial analysis of only the code changed in the PR looking for the introduction of new issues (note that coverage and duplications are not included in this check)
Once the PR is merged, Jenkins (in one job or several, depending on your needs)
builds
fires integration tests & any other automated tests
runs SonarQube Scan. Note that this comes last to include integration test results.
pushes build to next server
Note that the ability to break the build when the project doesn't pass the SonarQube Quality Gate you've set up may be desirable in your situation. Unfortunately, it's not available in the current server version: 5.2. It is available in 5.1, and is should return soon.
I have a Jenkins (which I'm new to) system that has a few constraints imposed on it:
master/slave arrangement
slave is Windows 7
installing plugins is likely to experience significant resistance
builds are to be archived to a Windows share
The goal is to have the output of the build and the log of the build archived to:
//server/share/archive/%BUILD_TAG%/
I'm using the post-build step Send build artifacts to a windows share to push the binaries to the archiving server, but I've yet to find a way to arrange for the build log to end up there too. I have discovered that the console output is available at http://jenkins/job/$jobTitle/$buildNumber/consoleText, but I'm not sure how useful that is going to be - I can't cause anything to run on the archive server to run. I'd like to maintain the separation that the master Jenkins knows about the slave and the archive, but the slave and archive are unaware of each other (that's assuming the Send build artifacts... step is running on the master rather than being pushed down to the slave to action).
Another approach I explored was to have Jenkins store the artifacts locally (via Archive the artifacts), but then I don't see a way to promtply push the result + log to the external server.
It seems that Jenkins is very flexible and that this scenario is likely already catered for, but I've yet to find out how.
Using the Post Build Task plugin, you can get the console output with a wget command:
wget -O console-output.log ${BUILD_URL}consoleText
I have my Xcode pro on svn repository,
on archiving I can successfully upload and distribute my app through crashlytics,
But now I wish to invoke jenkins to do unit testing after I update on svn and want jenkins to upload it to Crashlytics via or some other way.
I have automated the same, that is running the tests after which the build is uploaded to Crashlytics using a tool called Fastlane. It is pretty simple setting up by following the docs provided. You just have to include the fastlane commands in the shell while configuring the build steps of the job and also the api token and build secret as environment variables in Jenkins.
https://docs.fastlane.tools/
Using a single server that is only contains one Jenkins building for dev, test, etc.
Using separate Jenkins on each dev, test servers to build and run tests.
Edit ;
this is an explanation of step by step our deployment and release model
Our server side developers develop and commit/push their code to github.
CI server that Jenkins is located in poll SCM and fetch changes than build. (within CI server), run unit tests.
After building process and deploying artifacts to repository server (artifactory server)
Then CI server starts to deploy latest successful build into Development Server.
then client mobile developers can develop on latest successful snapshot build of server side.
These are our standard deployment process.
By the way,
We are also doing test deployment to test server via CI server with another different job on Jenkins (same CI server) but, this is handling/triggering by manual.
Preproduction and production transitions are done by manual also. (preproduction and production are different servers of course)
Questions;
Integration tests should be run on test server. How can i figure it out by building system on remote CI server instead of building system on the same machine (test server) ?
As a further step, what would the best option be to construct a Continuous Delivery system. ?
Thanks
A good approach is to have a single CI system that builds the system continuously as development makes changes. This build will on each build run all the unit tests as well and result in some kind of package that can be deployed. That can be further connected with automation that deploys and runs other tests or it can be used by e.g. testers to further test the system.
Depending on your release model and branching strategy as well as type of system/product this basic setup can be adjusted to fit your needs.
If you want more details please explain what you build and how you release/deploy.