diff --git a/docs/bitrise-ci/code-signing/ios-code-signing/creating-a-signed-ipa-for-xcode-projects.mdx b/docs/bitrise-ci/code-signing/ios-code-signing/creating-a-signed-ipa-for-xcode-projects.mdx index 0eebe69..6293384 100644 --- a/docs/bitrise-ci/code-signing/ios-code-signing/creating-a-signed-ipa-for-xcode-projects.mdx +++ b/docs/bitrise-ci/code-signing/ios-code-signing/creating-a-signed-ipa-for-xcode-projects.mdx @@ -20,7 +20,7 @@ You can easily create a signed IPA file for your Xcode project with Bitrise. - You have set up [Apple service connection](/en/bitrise-platform/integrations/apple-services-connection/about-connecting-to-apple-services) on Bitrise. - Your [code signing files are managed correctly](/en/bitrise-ci/code-signing/ios-code-signing/creating-a-signed-ipa-for-xcode-projects). -- You set the relevant inputs of our **Xcode Archive and Export for iOS** Step. +- You set the relevant inputs of our **Xcode Archive & Export for iOS** Step. diff --git a/docs/bitrise-ci/code-signing/ios-code-signing/managing-ios-code-signing-files-automatic-provisioning.mdx b/docs/bitrise-ci/code-signing/ios-code-signing/managing-ios-code-signing-files-automatic-provisioning.mdx index 62e106f..3545a5b 100644 --- a/docs/bitrise-ci/code-signing/ios-code-signing/managing-ios-code-signing-files-automatic-provisioning.mdx +++ b/docs/bitrise-ci/code-signing/ios-code-signing/managing-ios-code-signing-files-automatic-provisioning.mdx @@ -92,7 +92,7 @@ If you use automatic provisioning, you never need to use the **Certificate and p | Steps | How they work | When to use | | --- | --- | --- | -| Xcode Steps: - **Xcode Archive and Export for iOS** - **Export iOS and tvOS Xcode Archive** - **Xcode build for testing for iOS** | These Steps set up code signing in your Xcode project automatically with nearly zero configuration. | We recommend using these Steps in most scenarios. | +| Xcode Steps: - **Xcode Archive & Export for iOS** - **Export iOS and tvOS Xcode Archive** - **Xcode build for testing for iOS** | These Steps set up code signing in your Xcode project automatically with nearly zero configuration. | We recommend using these Steps in most scenarios. | | **Manage iOS Code Signing** Step | This Step will set up code signing in your Xcode project before running a build. | You can use this dedicated Step if: - You are building the app from script or fastlane. - You have a cross-platform project. For example, React Native, Flutter, Ionic or Cordova. - You are building a macOS app. | ### Using the Xcode Steps @@ -104,7 +104,7 @@ You can use any of the Xcode Steps with built-in automatic management of code si You can choose between [API key authentication](/en/bitrise-platform/integrations/apple-services-connection/connecting-to-an-apple-service-with-api-key) or [Apple ID authentication](/en/bitrise-platform/integrations/apple-services-connection/connecting-to-an-apple-service-with-apple-id). We generally recommend API key authentication. 1. Add any of the following Steps to your Workflow, depending on what you need: - - **Xcode Archive and Export for iOS**: Builds your Xcode app and exports an IPA of the type you choose. + - **Xcode Archive & Export for iOS**: Builds your Xcode app and exports an IPA of the type you choose. - **Export iOS and tvOS Xcode Archive**: Exports an IPA from an already existing archive. - **Xcode build for testing for iOS**: Builds your Xcode app with the `build-for-testing` action. 1. Set the **Automatic code signing method** input to the Apple service authentication type you set up. @@ -113,7 +113,7 @@ You can use any of the Xcode Steps with built-in automatic management of code si **YAML example for setting code signing method** -In this example, the **Xcode Archive and Export for iOS** Step is set to use API key authentication. +In this example, the **Xcode Archive & Export for iOS** Step is set to use API key authentication. ```yaml - xcode-archive@4: @@ -142,13 +142,13 @@ Use our dedicated Step for automatically managing code signing assets if you do ## Generating export options plists -The `ExportOptions.plist` file is automatically generated based on the [Xcode Archive for iOS](https://bitrise.io/integrations/steps/xcode-archive) Step inputs. You can, however, override these inputs and use it in the **Xcode Archive and Export for iOS** Step. +The `ExportOptions.plist` file is automatically generated based on the [Xcode Archive for iOS](https://bitrise.io/integrations/steps/xcode-archive) Step inputs. You can, however, override these inputs and use it in the **Xcode Archive & Export for iOS** Step. 1. Open your project on a local development machine Xcode. 1. Archive the project. 1. In the Organizer, select the newly created `.xcarchive` file. Click **Distribute App** to export it into an IPA file. Xcode will copy the used `ExportOptions.plist` file next to the generated IPA file. 1. Open this `ExportOptions.plist` file in your favorite text editor and copy its content. -1. Paste its content to the **Xcode Archive and Export for iOS** Step's **Export options plist** content input. +1. Paste its content to the **Xcode Archive & Export for iOS** Step's **Export options plist** content input. **An example plist file:** diff --git a/docs/bitrise-ci/code-signing/ios-code-signing/signing-an-ipa-with-multiple-code-signing-identities.mdx b/docs/bitrise-ci/code-signing/ios-code-signing/signing-an-ipa-with-multiple-code-signing-identities.mdx index a0e45b7..b2abf6c 100644 --- a/docs/bitrise-ci/code-signing/ios-code-signing/signing-an-ipa-with-multiple-code-signing-identities.mdx +++ b/docs/bitrise-ci/code-signing/ios-code-signing/signing-an-ipa-with-multiple-code-signing-identities.mdx @@ -41,7 +41,7 @@ The procedure lists the bare minimum requirements to configure these Steps to ex - `off` if you don't do automatic code signing. - `api-key` [if you use API key authorization](/en/bitrise-platform/integrations/apple-services-connection/about-connecting-to-apple-services). - `apple-id` [if you use Apple ID authorization](/en/bitrise-platform/integrations/apple-services-connection/about-connecting-to-apple-services). -1. Add the **[Export iOS and tvOS Xcode archive](https://www.bitrise.io/integrations/steps/export-xcarchive)** Step to your Workflow. This Step reuses the archive generated by the **Xcode Archive and Export for iOS** Step and does a second export from the archive. +1. Add the **[Export iOS and tvOS Xcode archive](https://www.bitrise.io/integrations/steps/export-xcarchive)** Step to your Workflow. This Step reuses the archive generated by the **Xcode Archive & Export for iOS** Step and does a second export from the archive. 1. Set the **Automatic code signing method** input to the Apple service connection you want to use for code signing. The available options are: - `off` if you don't do automatic code signing. diff --git a/docs/bitrise-ci/code-signing/ios-code-signing/troubleshooting-ios-code-signing.mdx b/docs/bitrise-ci/code-signing/ios-code-signing/troubleshooting-ios-code-signing.mdx index fe9780e..ad86822 100644 --- a/docs/bitrise-ci/code-signing/ios-code-signing/troubleshooting-ios-code-signing.mdx +++ b/docs/bitrise-ci/code-signing/ios-code-signing/troubleshooting-ios-code-signing.mdx @@ -41,7 +41,7 @@ Our [iOS code signing Steps](/en/bitrise-ci/code-signing/ios-code-signing/creati The maximum number of provisioning profiles and .p12 certificates you can upload to the **Code Signing** tab on Bitrise is 30. If you’ve already reached this limit and wish to use even more, then here are a few tips on how to use even more provisioning profiles: -- Use a Step with automatic provisioning, such as **Xcode Archive and Export for iOS**, **Export iOS and tvOS Xcode Archive**, **Xcode build for testing for iOS** , or **Manage iOS Code Signing**. These Steps only require the code signing identities (certificates with .p12 extension) to be uploaded to Bitrise. You can download the provisioning profiles from the Apple Developer portal on-the-fly during the build if you have [connected your Apple Developer account to Bitrise](/en/bitrise-platform/integrations/apple-services-connection/connecting-to-an-apple-service-with-api-key). +- Use a Step with automatic provisioning, such as **Xcode Archive & Export for iOS**, **Export iOS and tvOS Xcode Archive**, **Xcode build for testing for iOS** , or **Manage iOS Code Signing**. These Steps only require the code signing identities (certificates with .p12 extension) to be uploaded to Bitrise. You can download the provisioning profiles from the Apple Developer portal on-the-fly during the build if you have [connected your Apple Developer account to Bitrise](/en/bitrise-platform/integrations/apple-services-connection/connecting-to-an-apple-service-with-api-key). - You can create a .zip file containing the required certificates/profiles. In this case, you don’t need to upload any certificates/profiles on Bitrise. During the build you can download the .zip file and update the certificate/profile related inputs of the **Certificate and Profile Installer** Step to match the path to the certificate/profile on the build machine. Note that the **Certificate and Profile Installer** Step supports local paths and URLs for certificates and profiles. - You can host the profiles and certificates yourself, and only add an URL that is pointing to a given certificate/profile to the workflow. diff --git a/docs/bitrise-ci/deploying/ios-deployment/deploying-an-ios-app-to-bitriseio.mdx b/docs/bitrise-ci/deploying/ios-deployment/deploying-an-ios-app-to-bitriseio.mdx index 3809e24..81614a6 100644 --- a/docs/bitrise-ci/deploying/ios-deployment/deploying-an-ios-app-to-bitriseio.mdx +++ b/docs/bitrise-ci/deploying/ios-deployment/deploying-an-ios-app-to-bitriseio.mdx @@ -26,7 +26,7 @@ To deploy an iOS app to [bitrise.io](https://www.bitrise.io/), you will always n 1. Generate an IPA file on your own machine at least once. 1. [Upload all necessary code signing files](/en/bitrise-ci/code-signing/ios-code-signing/creating-a-signed-ipa-for-xcode-projects) to Bitrise. 1. If you want your internal testers to test the app, [register test devices](/en/bitrise-ci/testing/testing-ios-apps/registering-a-test-device). -1. Make sure the **Xcode Archive and Export for iOS** Step is in your Workflow. +1. Make sure the **Xcode Archive & Export for iOS** Step is in your Workflow. 1. Set the **Automatic code signing** input to the Apple service connection you want to use for code signing. The available options are: - `off`if you don’t do automatic code signing. diff --git a/docs/bitrise-ci/getting-started/adding-a-new-project.mdx b/docs/bitrise-ci/getting-started/adding-a-new-project.mdx index 01b8f3a..38aa72c 100644 --- a/docs/bitrise-ci/getting-started/adding-a-new-project.mdx +++ b/docs/bitrise-ci/getting-started/adding-a-new-project.mdx @@ -111,7 +111,7 @@ Bitrise scans your repository and generates a starter CI configuration automatic Once scanning completes: - If a project type is detected, it appears under the **Detected options** tab. -- If no project type is detected, switch to the **Manual setup** tab and select your project type from the **Project type** dropdown. Supported types include Android, Cordova, Fastlane, Flutter, Ionic, iOS, and others. +- If no project type is detected, switch to the **Manual setup** tab and select your project type from the **Project type** dropdown. ![CI configuration — manual project type selection](/img/getting-started/2026-06-27-add-ci-config-project-type-picker.png) diff --git a/docs/bitrise-ci/getting-started/getting-started.mdx b/docs/bitrise-ci/getting-started/getting-started.mdx index 0a92d4d..82bd114 100644 --- a/docs/bitrise-ci/getting-started/getting-started.mdx +++ b/docs/bitrise-ci/getting-started/getting-started.mdx @@ -36,6 +36,12 @@ Bitrise automatically creates your first [workspace](/en/bitrise-platform/worksp On the **Dashboard**, click **New project** and select **Configure Bitrise CI**. The **Add CI config** wizard walks you through three stages: +:::note[Release Management] + +If you want to add an app to [Release Management](/en/release-management) instead, select **Add your app** in the same dialog. + +::: + 1. **Repository**: connect to your Git provider, select a repository, authorize Bitrise to access it, and select a default branch. 1. **CI configuration**: Bitrise scans your repository and generates a starter configuration. If it can’t detect your project type automatically, select it manually from the **Project type** dropdown. 1. **Build settings**: review the pre-selected build machine and stack, choose whether builds are private or public, and optionally register a webhook so builds trigger on code changes automatically. diff --git a/docs/bitrise-ci/getting-started/migrating-to-bitrise/migrating-from-app-center-to-bitrise.mdx b/docs/bitrise-ci/getting-started/migrating-to-bitrise/migrating-from-app-center-to-bitrise.mdx index 8411d81..2c16d0a 100644 --- a/docs/bitrise-ci/getting-started/migrating-to-bitrise/migrating-from-app-center-to-bitrise.mdx +++ b/docs/bitrise-ci/getting-started/migrating-to-bitrise/migrating-from-app-center-to-bitrise.mdx @@ -26,8 +26,8 @@ A Bitrise Workspace has four main roles: - **Owner**: The owner of the Workspace. Full administrative control over the Workspace without restrictions. A Workspace can have multiple Owners. The default Owner is the account that created the Workspace. - **Manager**: The user can access and modify Workspace settings such as connected service accounts, can manage members but can't access billing details and can't delete the Workspace. -- **Contributor**: The user can't access Workspace settings and can't add new members or manage existing members. -- **Viewer**: The user can't add new projects or Release Management apps to the Workspace. +- **Contributor**: Can create new CI projects and add Release Management apps. +- **Viewer**: Can only view selected Workspace settings (Projects and Integrations). On App Center, you can create teams within organizations. On Bitrise, Workspace members can be added to Workspace groups: this makes it easier to assign multiple people to projects at the same time. diff --git a/docs/bitrise-ci/getting-started/migrating-to-bitrise/migrating-from-jenkins-to-bitrise.mdx b/docs/bitrise-ci/getting-started/migrating-to-bitrise/migrating-from-jenkins-to-bitrise.mdx index 1c122f1..2aac8e4 100644 --- a/docs/bitrise-ci/getting-started/migrating-to-bitrise/migrating-from-jenkins-to-bitrise.mdx +++ b/docs/bitrise-ci/getting-started/migrating-to-bitrise/migrating-from-jenkins-to-bitrise.mdx @@ -57,7 +57,7 @@ A build on Bitrise is the process specified by the app’s [Workflow](/en/bitris In this section we describe how you can trigger builds on Bitrise: - The **Build Now** function on Jenkins corresponds with [starting a build manually](/en/bitrise-ci/run-and-analyze-builds/starting-builds/starting-builds-manually): click the button on your builds page and either simply start a new build or tinker away with the [Advanced configuration options](/en/bitrise-ci/run-and-analyze-builds/starting-builds/scheduling-builds#advanced-configuration-options-for-startingscheduling-builds). -- The **Build periodically** function of Jenkins is the [Scheduling builds](/en/bitrise-ci/run-and-analyze-builds/starting-builds/scheduling-builds) function on Bitrise. A big advantage of Bitrise is that you don’t have to set up a `cron` job, like you would on Jenkins, to schedule a specific time. Instead, select a day/s from the timeline and type an hour and a month. No confusion over `cron` expressions any more! +- The **Build periodically** function of Jenkins is the [Scheduling builds](/en/bitrise-ci/run-and-analyze-builds/starting-builds/scheduling-builds) function on Bitrise. A big advantage of Bitrise is that you don’t have to set up a `cron` job, like you would on Jenkins, to schedule a specific time. Instead, you can use a visual scheduler to pick the days and time, or enter a `cron` expression directly if you prefer. - For any Git related events, such as code push, pull requests, and Git tags, you can [configure triggers](/en/bitrise-ci/run-and-analyze-builds/build-triggers/configuring-build-triggers) that automatically start a build on Bitrise. - The **Build after other projects** function of Jenkins is equivalent to the [chaining Workflows together](/en/bitrise-ci/workflows-and-pipelines/workflows/managing-workflows) on Bitrise where the Workflows run in succession. It’s surprisingly easy to chain Workflows together on Bitrise. - You can trigger builds by any other remote system: use [Webhooks overview](/en/bitrise-platform/integrations/webhooks/webhooks-overview). We’re integrated with GitHub, Gitlab, Bitbucket, Gogs, Slack, Visual Studio, Assembla, and Deveo. @@ -186,7 +186,7 @@ Check out our [blogpost](https://blog.bitrise.io/post/migrate-your-android-app-f A stack is the type of virtual machine we use to run your build. For example, for a native iOS app, the best stack is one of our Xcode stacks. Stacks come with all of the necessary tools pre-installed, and are regularly updated to make sure they will serve all of your needs. This way you don’t have to bother with maintaining master and agent instances or adding a node machine to your groovy code to run a build on a certain platform. -When you add your app to Bitrise, our project selector automatically detects the type of your project and based on its platform type, adds a default stack to it. Your first build will run on this stack, which is a virtual machine with all the required tools pre-installed on it. Should you wish to use another stack, you can simply select it from the **Default Stack** dropdown menu on the **Stacks and Machines** tab. If you click the **More information** link, you can see the preinstalled tools with their versions. +When you add your app to Bitrise, our project selector automatically detects the type of your project and based on its platform type, adds a default stack to it. Your first build will run on this stack, which is a virtual machine with all the required tools pre-installed on it. Should you wish to use another stack, you can simply select it from the **Default Stack** dropdown menu on the **Stacks & Machines** tab. If you click the **More information** link, you can see the preinstalled tools with their versions. We support the latest Xcode version shortly after its official release. diff --git a/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-android-projects.mdx b/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-android-projects.mdx index c35a3e1..c0859e2 100644 --- a/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-android-projects.mdx +++ b/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-android-projects.mdx @@ -40,7 +40,7 @@ You can read more about adding dependencies to your Android project: [https://de 1. 1. Make sure your Workflow includes the **Android Build** Step. - If the project scanner generated a Workflow called **deploy** when first adding your app, that Workflow includes the Step. It installs all dependencies listed in the `build.gradle` file without any additional configuration. + If the project scanner generated a Workflow called **build_apk** when first adding your app, that Workflow includes the Step. It installs all dependencies listed in the `build.gradle` file without any additional configuration. 1. Make sure your Workflow includes the **Install missing Android SDK components** Step. The Step must be BEFORE the **Android Build** Step in the Workflow. It will install all Android SDK tool that your project might need. @@ -76,7 +76,7 @@ In this section, we'll go through how to sign an Android app with the Android Si ![keystore-alias.png](/img/_paligo/uuid-0b79fc48-3861-0744-0f53-53a6c65ffc2c.png) 1. Open the Workflow Editor. -1. Add the **Android Sign****Generate cordova build configuration** Step to your Workflow. +1. Add the **Android Sign** Step to your Workflow. And that's it. The next time you'll run a build, the **Android Sign** Step will sign the generated binary. diff --git a/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-flutter-projects.mdx b/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-flutter-projects.mdx index 5f3771f..6bb2966 100644 --- a/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-flutter-projects.mdx +++ b/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-flutter-projects.mdx @@ -34,7 +34,7 @@ The **Deploy to Bitrise.io** Step exports the results of the **Flutter Test** St To run tests on a Flutter app: 1. Open your app’s Workflow Editor and open the **primary** Workflow, or any of your Workflows that you want to use to run tests. -1. In the **Flutter Install** Step, fill in the **Flutter SDK Version** input. +1. In the **Flutter Install** Step, fill in the **Flutter SDK version or bundle URL** input. You can specify either tags or branches of the Flutter SDK’s git repository. The default value is `stable`. This will use the latest stable branch of Flutter. @@ -188,7 +188,7 @@ The scope of this guide is the second option: signing your AAB/APK file with the 1. In the **Output (.apk, .aab) pattern** input, set the path where the **Deploy to Google Play** Step will be able to access the generated binary. The path should be relative to the project source directory, stored in the BITRISE_SOURCE_DIR Environment Variable. -1. Make sure you have the **Deploy to Google Play** Step after the **Android Sign****Cordova Archive** or **Ionic Archive** Step in your Workflow. +1. Make sure you have the **Deploy to Google Play** Step after the **Android Sign** Step in your Workflow. 1. Fill out the required input fields as follows: - **Service Account JSON key file path**: This field can accept a remote URL so you have to provide the Env Var which contains your uploaded service account JSON key. For example: `$BITRISEIO_SERVICE_ACCOUNT_JSON_KEY_URL`. diff --git a/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-ioniccordova-projects.mdx b/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-ioniccordova-projects.mdx index 0db4ec6..b93c839 100644 --- a/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-ioniccordova-projects.mdx +++ b/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-ioniccordova-projects.mdx @@ -27,7 +27,7 @@ You can use Cordova and Ionic frameworks to develop cross-platform apps. Bitrise You can run unit tests for Ionic/Cordova apps on Bitrise by using our **Karma Jasmine Test Runner** or **Jasmine Test Runner** Steps. -If your Cordova/Ionic project has a Karma Jasmine dependency in its **package.json** file, our scanner will detect it when you're adding your app and automatically insert the respective testing Step into your Workflow. If this dependency is missing from your project, you can manually insert one of our testing steps to your Workflow using our Workflow Editor. +If your Cordova/Ionic project has a Karma Jasmine dependency in its **package.json** file and a `karma.conf.js` file in the project root, our scanner will detect it when you're adding your app and automatically insert the respective testing Step into your Workflow. If this dependency is missing from your project, you can manually insert one of our testing steps to your Workflow using our Workflow Editor. 1. 1. Make sure you have a testing Step in your Workflow. @@ -225,7 +225,8 @@ You can use the **Deploy to Google Play** Step in your Workflow to upload your d Note that if you’re building for both iOS and Android in one project, and either of your apps fails, the whole **Cordova archive/Ionic archive** Step will fail. 1. Fill in the required inputs. - - The **Platform** input needs to be set to **device**. + - Set **Platform to use in cordova-cli commands** (Cordova) or **Platform to use in ionic-cli commands** (Ionic) to **android** (or **ios,android** if building for both platforms). + - Set **Build command target** to **device**. - The **Build command configuration** input must match the **Build configuration** input of the **Generate cordova build configuration** Step. The archive Step must come after the **Generate cordova build configuration** Step in the Workflow. @@ -233,11 +234,6 @@ You can use the **Deploy to Google Play** Step in your Workflow to upload your d 1. [Configure Google Play access.](/en/bitrise-ci/deploying/android-deployment/generating-and-deploying-android-app-bundles#setting-up-google-play-deployment-for-the-first-time) You only need to do this for your very first Google Play deployment of the app. -1. In the **Flutter Build** Step, find the **Android Platform Configs** input group and make sure the **Additional parameters** input has the value `--release`. -1. In the **Android output artifact type** input field, select either **APK** or **appbundle** depending on your deployment requirements. -1. In the **Output (.apk, .aab) pattern** input, set the path where the **Deploy to Google Play** Step will be able to access the generated binary. - - The path should be relative to the project source directory, stored in the BITRISE_SOURCE_DIR Environment Variable. 1. Make sure you have the **Deploy to Google Play** Step after the **Android Sign** and **Cordova Archive** or **Ionic Archive** Step in your Workflow. 1. Fill out the required input fields as follows: diff --git a/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-ios-projects.mdx b/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-ios-projects.mdx index f8c49be..d6ae703 100644 --- a/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-ios-projects.mdx +++ b/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-ios-projects.mdx @@ -60,7 +60,7 @@ You can easily create a signed IPA file for your Xcode project with Bitrise. - You have set up [Apple service connection](/en/bitrise-platform/integrations/apple-services-connection/about-connecting-to-apple-services) on Bitrise. - Your [code signing files are managed correctly](/en/bitrise-ci/code-signing/ios-code-signing/creating-a-signed-ipa-for-xcode-projects). -- You set the relevant inputs of our **Xcode Archive and Export for iOS** Step. +- You set the relevant inputs of our **Xcode Archive & Export for iOS** Step. :::important[Upload the distribution AND the development signing certificates] diff --git a/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-macos-projects.mdx b/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-macos-projects.mdx index f40a075..a50a05a 100644 --- a/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-macos-projects.mdx +++ b/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-macos-projects.mdx @@ -46,7 +46,7 @@ You can view the results in one place: [Deploying and viewing test results](/en/ To install and test the app on other physical devices, you will need to create and export an .app or .pkg file. This requires setting up code signing. In the example, we’ll be exporting an app with the **development** export method: you cannot upload such an app to Testflight but you can test it, for example, on the devices of your internal testers. -:::note[Automatic Provisioining] +:::note[Automatic Provisioning] The example procedure described here uses manual provisioning, with the **Certificate and profile installer** Step. However, Bitrise also supports [automatic provisioning](/en/bitrise-ci/code-signing/ios-code-signing/managing-ios-code-signing-files---automatic-provisioning) but it is not in the scope of this guide. @@ -68,6 +68,13 @@ You will need: If you selected **development** when you added the app to Bitrise, you don’t need to change the input. Otherwise, manually set it to **development**. + The available options are: + + - **development**: Signs the app with your Development identity for internal testing. + - **app-store**: Signs and packages the app for distribution in the Mac App Store. + - **developer-id**: Signs the app with your Developer ID for distribution outside the App Store. + - **none**: Exports the app without re-signing. + ![macOS_export_method.png](/img/_paligo/uuid-0edf6398-0b97-f558-978e-f7d8bae394e0.png) 1. Start a build. diff --git a/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-react-native-projects.mdx b/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-react-native-projects.mdx index 3325bb9..18c8b39 100644 --- a/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-react-native-projects.mdx +++ b/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-react-native-projects.mdx @@ -47,7 +47,7 @@ All Android apps must be digitally signed with a certificate before they can be ![keystore-alias.png](/img/_paligo/uuid-0b79fc48-3861-0744-0f53-53a6c65ffc2c.png) 1. Open the Workflow Editor. -1. Add the **Android Sign****Generate cordova build configuration** Step to your Workflow. +1. Add the **Android Sign** Step to your Workflow. If you uploaded your keystore file and filled out the metadata, the required inputs of the Step are already filled and require no more configuration from you. @@ -69,7 +69,7 @@ You can easily create a signed IPA file for your Xcode project with Bitrise. - You have set up [Apple service connection](/en/bitrise-platform/integrations/apple-services-connection/about-connecting-to-apple-services) on Bitrise. - Your [code signing files are managed correctly](/en/bitrise-ci/code-signing/ios-code-signing/creating-a-signed-ipa-for-xcode-projects). -- You set the relevant inputs of our **Xcode Archive and Export for iOS** Step. +- You set the relevant inputs of our **Xcode Archive & Export for iOS** Step. :::important[Upload the distribution AND the development signing certificates] @@ -233,25 +233,12 @@ If all goes well, your app will be submitted to App Store and you can distribute You can use the **Deploy to Google Play** Step in your Workflow to upload your digitally signed AAB/APK to the Google Play Store. -1. Add the **Cordova archive** or the **Ionic archive** Step to your Workflow. - - Note that if you’re building for both iOS and Android in one project, and either of your apps fails, the whole **Cordova archive/Ionic archive** Step will fail. -1. Fill in the required inputs. - - - The **Platform** input needs to be set to **device**. - - The **Build command configuration** input must match the **Build configuration** input of the **Generate cordova build configuration** Step. - - The archive Step must come after the **Generate cordova build configuration** Step in the Workflow. +1. Make sure your Workflow includes the **Android Build** Step and that it runs before the **Android Sign** Step. 1. [Configure code signing](/en/bitrise-ci/getting-started/quick-start-guides/getting-started-with-react-native-projects#signing-your-android-project) for your app. 1. [Configure Google Play access.](/en/bitrise-ci/deploying/android-deployment/generating-and-deploying-android-app-bundles#setting-up-google-play-deployment-for-the-first-time) You only need to do this for your very first Google Play deployment of the app. -1. In the **Flutter Build** Step, find the **Android Platform Configs** input group and make sure the **Additional parameters** input has the value `--release`. -1. In the **Android output artifact type** input field, select either **APK** or **appbundle** depending on your deployment requirements. -1. In the **Output (.apk, .aab) pattern** input, set the path where the **Deploy to Google Play** Step will be able to access the generated binary. - - The path should be relative to the project source directory, stored in the BITRISE_SOURCE_DIR Environment Variable. -1. Make sure you have the **Deploy to Google Play** Step after the **Android Sign****Cordova Archive** or **Ionic Archive** Step in your Workflow. +1. Make sure you have the **Deploy to Google Play** Step after the **Android Sign** Step in your Workflow. 1. Fill out the required input fields as follows: - **Service Account JSON key file path**: This field can accept a remote URL so you have to provide the Env Var which contains your uploaded service account JSON key. For example: `$BITRISEIO_SERVICE_ACCOUNT_JSON_KEY_URL`. diff --git a/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-web-ci.mdx b/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-web-ci.mdx index 903f4be..8aed8e2 100644 --- a/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-web-ci.mdx +++ b/docs/bitrise-ci/getting-started/quick-start-guides/getting-started-with-web-ci.mdx @@ -103,9 +103,9 @@ For Java projects built with Maven, your tests are run using a Script Step which Script Steps are fully customizable: you can create whatever Maven configuration you need. You can freely modify the default configuration at any time to suit your purposes. For more information about running tests with Maven, check out [Surefire](https://maven.apache.org/surefire/index.html). -### Testing Node.js projects +### Linting and testing Node.js projects -For Node.js projects, a Bitrise default Workflow does two things: +For Node.js projects, the default `run_tests` Workflow does two things by default — it installs Node.js and runs lint, not a test suite: - Installs Node.js via a **Script** Step: As it's a Script Step, you can fully modify and customize the configuration to suit your own needs. The default solution simply installs Node.js with `asdf`: diff --git a/docs/bitrise-ci/getting-started/the-bitrise-dashboard.mdx b/docs/bitrise-ci/getting-started/the-bitrise-dashboard.mdx index dbf5d7d..4b655e0 100644 --- a/docs/bitrise-ci/getting-started/the-bitrise-dashboard.mdx +++ b/docs/bitrise-ci/getting-started/the-bitrise-dashboard.mdx @@ -26,7 +26,7 @@ Your projects are listed on the left side of the dashboard. To see more data abo The details display basic information about all Bitrise products associated with the project: -- The last Bitrise CI build and its status on either the `main` or the `master` branch. The dashboard doesn't show build information from other branches. +- The last Bitrise CI build and its status on the project's default branch. The dashboard doesn't show build information from other branches. - The last time the Build Cache was used. - The number of connected apps the project has in Release Management. diff --git a/docs/bitrise-ci/getting-started/unity-on-bitrise.mdx b/docs/bitrise-ci/getting-started/unity-on-bitrise.mdx index c926a6f..76e0d3f 100644 --- a/docs/bitrise-ci/getting-started/unity-on-bitrise.mdx +++ b/docs/bitrise-ci/getting-started/unity-on-bitrise.mdx @@ -85,7 +85,7 @@ To run multiple builds concurrently, you need separate license keys for each bui 1. 1. On the left, select **Integrations**. -1. Select the **License pools** tab. +1. Click the **License pools** card. 1. Click **Add license pool**. ![license_pools.png](/img/_paligo/uuid-260b6d8c-c6ae-d008-a72a-8b0552a1e348.png)