Nowadays, we are running builds against every commit, but when someone opens a pull request, they don’t get automated builds or feedbacks. If the PR submitter even knows about Jenkins and has network access and a login, they can look at it to find out how the tests went, but most people aren’t going to have that visibility (especially if your Jenkins server is private). We need to make sure Jenkins is aware of the pull request and that it updates the PR with the status.

Our end goal is for each PR to start a Jenkins build and update the PR with a successful check when done.

This actually solved the problem if someone will get to know what things have failed so the developer can eventually solve the bug and could fix the bug on his/her end. This helps to achieve the product less buggy and the chances to revert a feature would be very minimal.

Worry about the triggering of the job on every push?

- Don't worry skip it in the shell script. (Amazing)

This session will help beginners who are interested in mobile testing and help them kick start right away, we will start from ground 0 and then move on to providing better understanding of the tool and writing scripts using the tool. This session is for participants who perceive mobile testing to be difficult and that it requires good coding skill. I will demonstrate by automating (running) all types of application supported by Appium. Appium is an open source project and has made design and tool decisions to encourage a vibrant contributing community.