> > Read more about configuring [additional conditions to run or skip](https://docs.codemagic.io/yaml-running-builds/starting-builds-automatically/#using-when-to-run-or-skip-builds) builds or build steps. > ### Scripts Scripts specify what kind of application is built. This is where you can specify the commands to [test](../testing-yaml/testing/), build and code sign your project (see our documentation for [iOS code signing](../code-signing-yaml/signing-ios) and [Android code signing](../code-signing-yaml/signing-android)). You can also run shell (`sh`) scripts directly in your `.yaml` file, or run scripts in other languages by defining the language with a shebang line or by launching a script file present in your repository. When you set `ignore_failure` to `true`, the workflow will continue to run even if the script fails. ```yaml scripts: - echo "single line script" - name: Flutter test script: flutter test ignore_failure: true - | #!/usr/bin/env python3 print('Multiline python script') - name: Build for iOS script: flutter build ios ``` There are example scripts available for building a [Flutter application](./building-a-flutter-app/), [React Native application](./building-a-react-native-app/), [native Android application](./building-a-native-android-app/) or a [native iOS application](./building-a-native-ios-app/). By default, scripts are run after your app sources are fetched and the repository is cloned. To run scripts before the repository cloning step, use the pre_clone_scripts step: ```yaml workflows: default-workflow: name: Default Workflow pre_clone_scripts: - name: Scripts to run before cloning the repository script: ... scripts: - name: Scripts to run after cloning the repository script: ... ``` ### Artifacts Configure the paths and names of the artifacts you would like to use in the following steps, e.g. for publishing, or have available for download on the build page. All paths are relative to the clone directory, but absolute paths are supported as well. You can also use [environment variables](../building/environment-variables) in artifact patterns. ```yaml artifacts: - build/**/outputs/apk/**/*.apk # relative path for a project in root directory - subfolder_name/build/**/outputs/apk/**/*.apk # relative path for a project in subfolder - build/**/outputs/**/*.aab - build/**/outputs/**/mapping.txt - build/ios/ipa/*.ipa - build/macos/**/*.pkg - /tmp/xcodebuild_logs/*.log - flutter_drive.log ``` There are several things to keep in mind about patterns: * The pattern can match several files or folders. If it picks up files or folders with the same name, the top level file or folder name will be suffixed with `_{number}`. * If one of the patterns includes another pattern, duplicate artifacts are not created. * `apk`, `aab`, `aar`, `ipa`, `app`, `pkg`, proguard mapping (`mapping.txt`), `flutter_drive.log`, `jar`, `zip`, `xarchive` and `dSYM.zip` files will be available as separate items in the Artifacts section on the build page. The rest of the artifacts will be included in an archive with the following name pattern: `{project-name}_{version}_artifacts.zip`. ### Publishing Codemagic has a number of integrations for publishing but you can also publish elsewhere with custom scripts. See the options under the [Publishing section](../publishing-yaml/distribution/). Note that by default the publishing scripts are run regardless of the build status. You can specify additional conditions with if statements. ```yaml publishing: email: recipients: - name@example.com scripts: name: Check for apk script: | apkPath=$(find build -name "*.apk" | head -1) if [[ -z ${apkPath} ]] then echo "No .apk were found" else echo "Publishing .apk artifacts" fi ``` You can also use the publishing scripts to report build status. ```yaml scripts: - name: Report build start script: # build started . . . - name: Build finished successfully script: touch ~/SUCCESS publishing: scripts: - name: Report build status script: | if [ -a "~/SUCCESS" ] ; then # build successful else # build failed fi ``` ### Labels You may use `codemagic.yaml` to define labels for your apps. Labels serve as additional information about the workflow you are building and are helpful when you have multiple versions of a workflow. The labels are visible on the `/builds` and `/app//build/` pages. As shown in the snippet below, labels also support environment variables. ```yaml workflows: sample_workflow: name: My Workflow labels: - QA - ${TENANT_NAME} ``` If you are building white label apps and use the Codemagic REST API to initiate your builds, labels should be passed as described [here](https://docs.codemagic.io/rest-api/builds/) because it is not possible to override environment variables that will be used as labels. ## Working directory You may select a working directory globally for the entire workflow or individual scripts only. If not specified, the global working directory defaults to the directory where the repository is cloned (`/Users/builder/clone`). You can override the global working directory by specifying the working directory in the individual steps. Consider the example below: ```yaml workflows: build-apps: name: Build iOS and Android working_directory: mobile scripts: - name: Prepare script: pwd # current working directory is /Users/builder/clone/mobile - name: Build iOS working_directory: mobile/ios script: pwd # current working directory is /Users/builder/clone/mobile/ios - name: Build Android working_directory: mobile/android script: pwd # current working directory is /Users/builder/clone/mobile/android - name: Process Logs working_directory: /Users/builder/Library/Logs script: pwd # current working directory is /Users/builder/Library/Logs ``` Working directory paths are relative to the repository clone directory, e.g. if `mobile` is the working directory, then the script will be executed in `/Users/builder/clone/mobile`. Note that you can specify an absolute path as a working directory as well. ## Validating codemagic.yaml locally Using the Codemagic JSON schema, you can validate your `codemagic.yaml` for structure and syntax errors right in your IDE. The same level of validation is carried out on the frontend in the YAML editor in your project settings. The JSON schema does not validate the maximum build duration value, software version values, credentials, environment variable values, or whether you have access to any paid features. Codemagic JSON schema is available out of the box in the IDEs integrated with [schemastore.org](http://schemastore.org/), e.g. Android Studio and Visual Studio Code. If your IDE does not have the Codemagic JSON schema available by default, you can set up validation manually. To do so: * make sure you have YAML language support in the IDE * configure the IDE to use the Codemagic JSON schema for validation available at [https://codemagic.io/codemagic-schema.json](https://codemagic.io/codemagic-schema.json)