Actionsįor actions, by default it’ll just archive… but we want a test too. you can schedule a start of the workflow (good for nightly builds) or whenever a tag or Pull Request has changes.įor this article, we’re going to use the default setting, being whenever something is pushed to main. We would like to keep it like that for this article, but there are other triggers available for it too: E.g. Any push to said branch will trigger this workflow to be started. This is by default set to the current branch you’re working on… in this case main. This is the actual trigger for the workflow. The last thing you can select here is whether you would like some environment variables to be set.įor this article, we’re just going to put it on the latest beta and be let the rest on this page be. If you have a lot of developers on a large project, this might increase the build time per build with a few minutes… resulting in an overall increase per day of a possible few hours (depending on the amount of developers and the amount of builds). This can be useful for some project, but it will also increase the overall build time on Xcode. For instance, do you want Xcode cloud to build on the beta version, as well as do you want to use caching (default) or would you like Xcode Cloud not to restore the derrived data. In the next page, under Environment, you can select which environment you want Xcode cloud to build upon. You can also restrict the workflow if you like. Here you can set some default settings for the workflow, like name and description. The first one selected is the general flow. In the left you’ll find a menu with the different steps for the workflow. The next view will show you the different steps that will be preformed. So lets select that “Edit workflow” button and edit the workflow. We’re going to edit the suggested workflow … after which it will show you a predefined selection of what to do. A modal view will popup which will let you select the team: Select the Create workflow option of your choice and start adding a workflow.
#Xcode cloud archive#
In the picture below you’ll see both options.įor this article, we’re going to focus on adding a workflow which will archive and upload to AppStore Connect so the app will be available in TestFlight.
If you don’t have any workflows yet, it’ll instruct you to create a workflow after analyzing your project. There are two ways of doing this, either by going via the menu Product > Xcode Cloud > Create Workflow, or via the Report Navigator ( CMD + 9) and select the cloud tab. Lets create the first workflow for the project. For instance, when a push is done towards a branch you might want the tests to be run but when a push is done towards the main branch, you want the tests to be run as well as the app to be uploaded to TestFlight Workflows are sets of actions for Xcode Cloud to perform when running your app. Now you should be ready to add your first workflow. Open AppStore Connect and go to your apps, select the (+) in the top left corner just next to “Apps” and add your app. When this is done, you can add the app to AppStore Connect too. Of course you can use automated signing in Xcode too, but I like to be explicit here. You will have to change this to something that suits you, and needs to be added to the developer console as well. In the example app mentioned above, I’ve setup the bundleId. Being an admin for the repository does help here. You will also have to be able to grand Xcode Cloud access to your GitHub (or GitLab, or bitbucket cloud) repository. The latest agreement needs to be accepted by the team agent as well, which is done in the developer console. In order to get going, you need to have the appropriate access in the Apple Developer Console, preferably admin or Team Agent. The project is located on GitHub and can be found here. It is a simple app with a Hello, world! view and a manager with some tests. For this article, I’ve setup a quick app which you can fork on GitHub.
0 kommentar(er)
