- #Fastlane xcode cloud how to#
- #Fastlane xcode cloud for mac#
- #Fastlane xcode cloud install#
- #Fastlane xcode cloud code#
- #Fastlane xcode cloud simulator#
When running a test action, Xcode Cloud will provide us with a $CI_RESULT_BUNDLE_PATH variable which we can use to provide coverage results to SonarQube. Sonar_runner_args: "-Dsonar.projectBaseDir=$CI_WORKSPACE -Dsonar.c.file.suffixes=github" \Īs you can see, this analysis has failed, in part because we haven’t met the code-coverage requirements. We can call this directly, or create a Fastfile: fastlane run sonar \
#Fastlane xcode cloud install#
I’ve used the Fastlane plugin for SonarQube as it was the easiest way to install and run SonarQube on the build agent.
This will help us to understand the overall health of our code-base. We can start by performing an analysis on a shared branch, i.e. As a single agent performs the build before handing off to multiple agents to run the tests in parallel, placing this in the ci_post_clone.sh won’t work as this is only run on the initial build agent. We can do this in our ci_pre_xcodebuild.sh script. To run Sonar Analysis, we’ll need to install three additional things on the build agent: fastlane, sonar-scanner and the fastlane plugin for converting Xcode’s test coverage output into JUnit format. They have Xcode, Homebrew, anything that comes pre-installed on macOS and that’s about it. Xcode Cloud agents are currently quite light on pre-installed software.
#Fastlane xcode cloud how to#
In this article, I will detail how to quickly and easily create a home-screen widget for your app, using the London Underground status board as a real-world example. I won’t cover how to create an Xcode Cloud build, as others have covered that already and the Apple Documentation is fairly well written.Ĭreate a Tube Status home-screen Widget for iOS 14 I’m using SonarCloud for this, as it’s free for open source projects, but you can also use this for your own privately hosted SonarQube instances.
#Fastlane xcode cloud code#
I’ll be using the Fastlane plugin for SonarQube and attempting to output a report on code quality and test coverage from an Xcode Cloud pull request validation build. Here I’ll be implementing SonarQube for a project I’ve written about before: my London Underground Status app. From a development perspective, I’ve seen intense debates on what the format for a pull request title should be, while the code itself is violating multiple SOLID principles. This is usually because the important items are more complex and we don’t spend the time to fully understand them, so we focus on the those that we can understand quickly. These tools can help to ensure developers always meet the required standards in their code, and can reduce (or even prevent) the amount of bike-shedding on our merge requests.īike-shedding is where we spend a disproportionate amount of time discussing trivial things and leave important matters undiscussed. I like to use a combination of SonarQube and SwiftLint to enforce quality standards on the codebases I work on. SonarQube can be a great tool for finding smells, bugs and duplications in your code. If your main process stops everything else and the container stops with it.Attempting SonarQube Analysis on Xcode Cloud Approx: 7 minutes reading time Note that it has only ever been tested to run the fastlane tests (that don't depend on macOS-only software), so it doesn't actually claim to run fastlane reliably.ĭocker allows multiple processes, it just doesn't allow more than one main process. That being said, there is a fastlane docker image that is being worked on here that is also available on the Docker Hub. You can also set it up to run those during building (with Xcode's script build phases), so that no one can accidentally forget to install something that is needed for the build.
Instead, it would be advisable to use things like Gemfile and Brewfile to list all your dependencies, and have a small setup.sh script that runs brew bundle and bundle install to install them on your colleague's machines.
fastlane's match, cert, pem and sigh)Īll in all you're probably going to be very limited. Downloading/Creating certificates, provisioning profiles and push certificates (i.e.Uploading your app with iTMSTransporter (i.e.Building the JS code (I assume, since RN should work on Linux).
Here's things that you could potentially use your docker container for:
#Fastlane xcode cloud simulator#
Take screenshots of your app or run your app in the Simulator.Here's what you definitely won't be able to do, at least not without a non-trivial amount of work:
#Fastlane xcode cloud for mac#
Docker runs in a lightweight virtual machine called xhyve - at least if you install docker via the Docker for Mac package - that runs Linux on your mac.Įssentially what this means is that your docker container is going to be limited to non-Xcode functionality. The problem with using Docker is that even if you use Docker for mac, you won't have access to macOS-based images.
0 kommentar(er)
