Shulou(Shulou.com)06/02 Report--

This article mainly shows you "how to use Jenkins to build iOS/Android continuous integration packaging platform", the content is easy to understand, clear, hope to help you solve your doubts, the following let the editor lead you to study and learn "how to use Jenkins to build iOS/Android continuous integration packaging platform" this article.

First of all, I would like to show you the overall effect of the completion of the platform:

There are three main functions of the platform:

Check the GitHub warehouse regularly and automatically perform build packaging if there are updates.

After successful construction, the QR code is generated according to ipa/apk, and each version of the QR code can be displayed in the historical build list. The corresponding version can be installed directly by scanning the QR code on the mobile phone.

The results of the current build (Artifact, such as .ipa, .app, .apk, info.plist, etc.) are displayed on the build results page, which can be downloaded by users who need it.

Next, this paper begins to introduce the complete implementation process of the platform construction in detail.

Install Jenkins

Jenkins depends on the Java runtime environment, so you need to install Java first.

There are many ways to install Jenkins. You can run the installation package of the corresponding system type, obtain the image through docker, or run the war package directly.

Personally, I prefer to run the war package directly. After downloading jenkins.war, run the following command to start Jenkins.

$nohup java-jar jenkins_located_path/jenkins.war-httpPort=88 &

If you do not specify that the default port for httpPort,Jenkins is 8080.

Jenkins plug-in

Jenkins has a lot of plug-ins that can extend a variety of functions.

For the built iOS/Android continuous integration packaging platform, I used the following plug-ins.

GIT plugin

SSH Credentials Plugin

Git Changelog Plugin: get the commit log submitted by the warehouse

Build-name-setter: used to modify the Build name

Description setter plugin: used to modify Build description information and add display QRCode (QR code) to the description information

Post-Build Script Plug-in: implement some additional functionality by executing scripts after compilation is complete

Xcode integration: dedicated to iOS (optional)

Gradle plugin: dedicated to Android (optional)

The installation method is also relatively simple. Search for the above plug-ins directly in the plug-in management page of Jenkins and click install.

Create a project (Job)

In Jenkins, a build project exists in the form of a Job, so you need to create a Job for each project. Sometimes, multiple branches of a project may be under development at the same time, or a Job can be created for each branch in order to build separately.

There are many ways to create a Job. This time, you only need to create a Freestyle project type.

Main page-> New Item-> Freestyle project

For a continuous integration packaging platform, each package consists of four steps: trigger build, pull code, execute build, and build post-processing. Correspondingly, each Job also corresponds to the configuration of these items.

Configure the Git code repository

To build the project, it is essential to configure the project's code repository. Since our project is currently hosted in a private GitHub repository, Git needs to be configured here.

Under the [Source Code Management] configuration column, if the previous GIT plugin installation was successful, the Git option appears.

When configuring a Git code repository, there are three items that must be configured: the repository URL address (Repository URL), the repository permissions verification method (Credentials), and the code branches that the current Job needs to build (Branches to build).

When configuring Repository URL, you can choose either HTTPS URL or SSH URL. However, it should be noted that Credentials corresponds to Repository URL, that is to say:

If the Repository URL is in the form of HTTPS URL, then Credentials uses the GitHub username and password verification method; moreover, if 2FA (two-factor authentication) is turned on in GitHub, you also need to create a Personal access token in GitHub and enter the Personal access token as the password when entering the password.

If Repository URL is in the form of SSH URL, you need to first create a SSH key pair on the server where Jenkins resides, and add the public key to the SSH keys of GitHub. Then, when entering Credentials, select the verification method of SSH Username with private key, and enter GitHub Username, SSH private key, and the Passphrase set when creating the SSH key pair.

If the concept of Git permission check is still vague, you can refer to "Git permission check".

Branches to build can be configured in a variety of forms, including branch name (branchName), tagName, commitId, and so on. The form of branch name is most commonly used. For example, if you are building a master branch, fill in refs/heads/master, and if you are building a develop branch, enter refs/heads/develop.

In addition to the required configuration items for Git above, sometimes the default configuration items for Jenkins may need to be modified depending on the actual situation of the project.

One of the more common situations is to modify the configuration of clone.

In the default configuration of Jenkins, clone code pulls all historical versions of the code, and the default timeout period is only 10 minutes. This results in that in some projects, due to the large amount of code itself, a large number of historical versions, and the fact that the network environment is not very good, Jenkins simply cannot pull all the code within 10 minutes, and the task will be automatically terminated after the timeout (error status code 143).

The solution to this problem is also simple: either pull less code (do not get the historical version) or increase the timeout period. The corresponding configuration is in Advanced clone behaviours:

Shallow clone: do not get the historical version when checked

Timeout (in minutes) for clone and fetch operation: overrides the default timeout period after configuration.

Configure build trigger

The code repository is configured, which means that Jenkins has access to the GitHub code repository and can pull the code successfully.

So when does Jenkins execute the build?

This requires the configuration of the build trigger policy, that is, the build trigger, and the configuration item is located in the [Build Triggers] column.

Triggers support a variety of types, including:

Build regularly (Build periodically)

Build based on submission (Build when a change is pushed to GitHub)

Check for code updates periodically and build them if any (Poll SCM)

The choice of a build trigger is a composite option, and if multiple types are selected, the build will be performed when any type meets the build conditions. If all types are not selected, the Jenkins Job does not perform an automatic build, but the build can be triggered by manually clicking [Build Now].

The format of the timer (Schedule) is briefly described as follows:

MINUTE HOUR DOM MONTH DOW

MINUTE: Minutes within the hour (0-59)

HOUR: The hour of the day (0-23)

DOM: The day of the month (1-31)

MONTH: The month (1-12)

DOW: The day of the week (0-7) where 0 and 7 are Sunday.

In general, you need to specify multiple values, and you can use the following operator (priority from top to bottom):

* fit all valid values. If one item is not specified, the space will be occupied by *.

Mmurn adapts a range of values. For example, 7-9 indicates that all of them are satisfied on 7-8-9.

M-N/X or * / X: spaced by X

A _ C: enumerates multiple values.

In addition, to prevent multiple tasks from triggering a build at the same time, you can use the H character together for a specified period of time. After adding the H character, Jenkins will randomly select a time point within the specified time period as the start time, and then add the set time interval to calculate the subsequent time point. Until the next cycle, Jenkins will re-randomly select a point in time as the starting time, and so on.

For ease of understanding, here are a few examples:

Hhand 15 *: means every 15 minutes, and the start time is uncertain. This hour may be: 07Grammer 22 jiggle 37JZ 52, the next hour may be: 03jiggle 18gle 3jingle 48.

H (0-29) / 10 *: represents every 10 minutes in the first half hour, and the start time is uncertain. This hour may be: 04 Magi 14 Magi 24, the next hour may be: 09 Jing Jing 19 Jing Lou 29

H 23 * 1-5: sometime between 23:00 and 23:59 every night on weekdays

Configure the construction mode

After the trigger policy is configured, Jenkins automatically executes the build according to the set policy. But how to perform the build operation, this also requires us to configure the build method to set.

The common construction method is to install the corresponding plug-in according to the specific type of the construction object, and then adopt the corresponding construction method. For example, if you are building an Android application, after installing Gradle plugin, you can select Invoke Gradle script and then use Gradle to build; if you are building an iOS application, after installing the Xcode integration plug-in, you can select Xcode and then select Xcode to build.

The advantage of this method is that it is easy to operate, UI visualization, and can quickly meet the needs when the scene is not complex. However, the disadvantage is that it depends on the existing functions of the plug-in. If the scenario is complex, a single plug-in may not be able to meet the requirements, so you need to install other plug-ins. Moreover, some plug-ins may have some problems, such as poor compatibility with certain operating system versions or XCode versions, and we will be more passive when there are problems.

Personally, I prefer another approach, which is to write my own packaging script, customize to implement all the build functions in the script, and then execute it in Execute Shell. This approach is more flexible, the construction needs of various scenarios can be met, and problems can be quickly repaired by themselves.

In addition, for the construction of iOS applications, there is another point that requires additional attention, that is, the configuration of developer certificates.

If you use the Xcode integration plug-in to build, the configuration will be more complex, you need to import the development certificate in Jenkins and fill in multiple configuration items. However, it would be much easier to build using a packaged script. As long as the developer certificate is installed on the computer on which Jenkins is running and the packaging command works in Shell, there will be no problem executing the packaging script in Jenkins.

Build post-processing

After the build is completed, the generated compiled fruit (ipa/apk) is located in the specified directory. However, it is troublesome to install ipa/apk files directly in your phone. Not only do you need to transfer tens of megabytes of installation packages when you distribute the test package, but you also need to connect the phone to your computer through a data cable during installation, and then install it using tools such as PP Assistant or Pea Pod.

At present, one of the more elegant ways is with the help of platforms such as dandelion (pgyer) or fir.im, after uploading the ipa/apk file to the platform, the platform generates the QR code, and then only needs to distribute the QR code link to experience that the user can quickly install the QR code by scanning the QR code through the mobile phone, and the efficiency has been greatly improved.

Upload the installation package file and generate the QR code

No matter dandelion or fir.im, there is a corresponding Jenkins plug-in. After installing the plug-in, you can upload the installation package in Post-build.

In addition to using the Jenkins plug-in, fir.im also supports command upload, and dandelion also supports upload via HTTP Post interface.

I personally recommend uploading commands or interfaces and calling them in the build script. Flexibility is on the one hand, the greater advantage is that if the upload fails, it can be retried, which is extremely necessary when the network environment is not very stable.

After Jenkins successfully completes the upload of the installation package, the pgyer/fir.im platform will generate a QR code image and return the URL link address of the image in the response.

Show the QR code picture

The URL link for the QR code image is available, so how can the QR code image be displayed in the historical build list of the Jenkins project?

Another plug-in, description setter plugin, is needed here. After installing the plug-in, the description setter function will be added in the "Post-build Actions" column, which can be used to set the description information of the current build after the construction is completed. This description is displayed not only in the build page, but also in the list of historical builds.

With this premise, it seems possible to display the QR code picture in the historical build list. The intuitive way is to use the img tag of HTML to set the

Write to the build description information.

The idea of this method is correct, but it will not achieve the desired results in the future.

This is because Jenkins for security reasons, the Markup Formatter of all description information defaults to Plain text mode, in which the HTML code in build description information is not parsed.

It's also easy to change, Manage Jenkins-> Configure Global Security, just change the setting of Markup Formatter to Safe HTML.

After changing the configuration, we can insert the picture in the build description using the img tag of HTML.

There is another point that needs to be added. If you use the dandelion (pyger) platform, you will find that the QR code image returned after each upload of the installation package is a short link, which is miraculously fixed (for the same account). This short link always points to the recently generated QR code image, but for the * URL address of the QR code image, the platform does not return it in the response. In this case, it doesn't make sense for us to save the URL link to the QR code image after each build.

The solution is to download and save the QR code image locally through the returned QR code picture short link after each upload of the installation package, and then reference the Jenkins address of the picture in the build description.

Collect and compile into fruit (Artifacts)

After each build, more files are compiled, but not all of them are what we need.

Usually, we may only need some of these files, such as .ipa / .app / .plist / .apk, and so on, which can be collected separately and displayed on the build page so that we can download them when needed.

To achieve such a function, you need to add Archive the artifacts in the [Post-build Actions] column, and then specify the path to the artifact file through regular expressions in Files to archive.

After setting up, after each build is completed, Jenkins will search and match with the set regular expression in Console Output, and if it can successfully match the file, it will collect the file.

The above is all the contents of the article "how to build an iOS/Android continuous Integration Packaging platform with Jenkins". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.