Translation batch 1617205196 (#18517)

Author: rachmari

translations/de-DE/content/actions/guides/index.md

@@ -42,6 +42,7 @@ includeGuides:
   - /actions/guides/building-and-testing-java-with-maven
   - /actions/guides/building-and-testing-java-with-gradle
   - /actions/guides/building-and-testing-java-with-ant
+  - /actions/guides/installing-an-apple-certificate-on-macos-runners-for-xcode-development
   - /actions/guides/publishing-nodejs-packages
   - /actions/guides/publishing-java-packages-with-maven
   - /actions/guides/publishing-java-packages-with-gradle
@@ -81,6 +82,7 @@ includeGuides:
 <!-- {% link_in_list /building-and-testing-java-with-maven %} -->
 <!-- {% link_in_list /building-and-testing-java-with-gradle %} -->
 <!-- {% link_in_list /building-and-testing-java-with-ant %} -->
+<!-- {% link_in_list /installing-an-apple-certificate-on-macos-runners-for-xcode-development %} -->
 <!-- {% link_in_list /about-packaging-with-github-actions %} -->
 <!-- {% link_in_list /publishing-nodejs-packages %} -->
 <!-- {% link_in_list /publishing-java-packages-with-maven %} -->

translations/de-DE/content/actions/guides/installing-an-apple-certificate-on-macos-runners-for-xcode-development.md

@@ -0,0 +1,135 @@
+---
+title: Installing an Apple certificate on macOS runners for Xcode development
+intro: 'You can sign Xcode apps within your continuous integration (CI) workflow by installing an Apple code signing certificate on {% data variables.product.prodname_actions %} runners.'
+product: '{% data reusables.gated-features.actions %}'
+versions:
+  free-pro-team: '*'
+  enterprise-server: '>=2.22'
+  github-ae: '*'
+type: 'tutorial'
+topics:
+  - 'CI'
+  - 'Xcode'
+---
+
+{% data reusables.actions.enterprise-beta %}
+{% data reusables.actions.enterprise-github-hosted-runners %}
+{% data reusables.actions.ae-beta %}
+
+### Einführung
+
+This guide shows you how to add a step to your continuous integration (CI) workflow that installs an Apple code signing certificate and provisioning profile on {% data variables.product.prodname_actions %} runners. This will allow you to sign your Xcode apps for publishing to the Apple App Store, or distributing it to test groups.
+
+### Vorrausetzungen
+
+Du solltest mit YAML und der Syntax für {% data variables.product.prodname_actions %} vertraut sein. Weitere Informationen findest Du unter:
+
+- "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)"
+- „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions)“
+
+You should have an understanding of Xcode app building and signing. For more information, see the [Apple developer documentation](https://developer.apple.com/documentation/).
+
+### Creating secrets for your certificate and provisioning profile
+
+The signing process involves storing certificates and provisioning profiles, transferring them to the runner, importing them to the runner's keychain, and using them in your build.
+
+To use your certificate and provisioning profile on a runner, we strongly recommend that you use {% data variables.product.prodname_dotcom %} secrets. For more information on creating secrets and using them in a workflow, see "[Encrypted secrets](/actions/reference/encrypted-secrets)."
+
+Create secrets in your repository or organization for the following items:
+
+* Your Apple signing certificate.
+
+  - This is your `p12` certificate file. For more information on exporting your signing certificate from Xcode, see the [Xcode documentation](https://help.apple.com/xcode/mac/current/#/dev154b28f09).
+
+  - You should convert your certificate to Base64 when saving it as a secret. In this example, the secret is named `BUILD_CERTIFICATE_BASE64`.
+
+  - Use the following command to convert your certificate to Base64 and copy it to your clipboard:
+
+    ```shell
+    base64 <em>build_certificate</em>.p12 | pbcopy
+    ```
+* The password for your Apple signing certificate.
+  - In this example, the secret is named `P12_PASSWORD`.
+
+* Your Apple provisioning profile.
+
+  - For more information on exporting your provisioning profile from Xcode, see the [Xcode documentation](https://help.apple.com/xcode/mac/current/#/deva899b4fe5).
+
+  - You should convert your provisioning profile to Base64 when saving it as a secret. In this example, the secret is named `BUILD_PROVISION_PROFILE_BASE64`.
+
+  - Use the following command to convert your provisioning profile to Base64 and copy it to your clipboard:
+
+    ```shell
+    base64 <em>provisioning_profile.mobileprovision</em> | pbcopy
+    ```
+
+* A keychain password.
+
+  - A new keychain will be created on the runner, so the password for the new keychain can be any new random string. In this example, the secret is named `KEYCHAIN_PASSWORD`.
+
+### Add a step to your workflow
+
+This example workflow includes a step that imports the Apple certificate and provisioning profile from the {% data variables.product.prodname_dotcom %} secrets, and installs them on the runner.
+
+{% raw %}
+```yaml{:copy}
+name: App build
+on: push
+
+jobs:
+  build_with_signing:
+    runs-on: macos-latest
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v2
+      - name: Install the Apple certificate and provisioning profile
+        env:
+          BUILD_CERTIFICATE_BASE64: ${{ secrets.BUILD_CERTIFICATE_BASE64 }}
+          P12_PASSWORD: ${{ secrets.P12_PASSWORD }}
+          BUILD_PROVISION_PROFILE_BASE64: ${{ secrets.BUILD_PROVISION_PROFILE_BASE64 }}
+          KEYCHAIN_PASSWORD: ${{ secrets.KEYCHAIN_PASSWORD }}
+        run: |
+          # create variables
+          CERTIFICATE_PATH=$RUNNER_TEMP/build_certificate.p12
+          PP_PATH=$RUNNER_TEMP/build_pp.mobileprovision
+          KEYCHAIN_PATH=$RUNNER_TEMP/app-signing.keychain-db
+
+          # import certificate and provisioning profile from secrets
+          echo -n "$BUILD_CERTIFICATE_BASE64" | base64 --decode --output $CERTIFICATE_PATH
+          echo -n "$BUILD_PROVISION_PROFILE_BASE64" | base64 --decode --output $PP_PATH
+
+          # create temporary keychain
+          security create-keychain -p $KEYCHAIN_PASSWORD $KEYCHAIN_PATH
+          security set-keychain-settings -lut 21600 $KEYCHAIN_PATH
+          security unlock-keychain -p $KEYCHAIN_PASSWORD $KEYCHAIN_PATH
+
+          # import certificate to keychain
+          security import $CERTIFICATE_PATH -P $P12_PASSWORD -A -t cert -f pkcs12 -k $KEYCHAIN_PATH
+          security list-keychain -d user -s $KEYCHAIN_PATH
+
+          # apply provisioning profile
+          mkdir -p ~/Library/MobileDevice/Provisioning\ Profiles
+          cp $PP_PATH ~/Library/MobileDevice/Provisioning\ Profiles
+      - name: Build app
+        ...
+```
+{% endraw %}
+
+### Required clean-up on self-hosted runners
+
+{% data variables.product.prodname_dotcom %}-hosted runners are isolated virtual machines that are automatically destroyed at the end of the job execution. This means that the certificates and provisioning profile used on the runner during the job will be destroyed with the runner when the job is completed.
+
+On self-hosted runners, the `$RUNNER_TEMP` directory is cleaned up at the end of the job execution, but the keychain and provisioning profile might still exist on the runner.
+
+If you use self-hosted runners, you should add a final step to your workflow to help ensure that these sensitive files are deleted at the end of the job. The workflow step shown below is an example of how to do this.
+
+{% raw %}
+```yaml
+- name: Clean up keychain and provisioning profile
+  if: ${{ always() }}
+  run: |
+    security delete-keychain $RUNNER_TEMP/app-signing.keychain-db
+    rm ~/Library/MobileDevice/Provisioning\ Profiles/build_pp.mobileprovision
+```
+{% endraw %}

translations/de-DE/content/actions/reference/environment-variables.md

@@ -54,6 +54,7 @@ Es wird dringend empfohlen, dass Aktionen Umgebungsvariablen verwenden, um auf d
 | `GITHUB_WORKFLOW`    | Der Name des Workflows.                                                                                                                                                                                                                                                                                                                                                                |
 | `GITHUB_RUN_ID`      | {% data reusables.github-actions.run_id_description %}
 | `GITHUB_RUN_NUMBER`  | {% data reusables.github-actions.run_number_description %}
+| `GITHUB_JOB`         | The [job_id](/actions/reference/workflow-syntax-for-github-actions#jobsjob_id) of the current job.                                                                                                                                                                                                                                                                                     |
 | `GITHUB_ACTION`      | Die eindeutige Kennung (`id`) der Aktion.                                                                                                                                                                                                                                                                                                                                              |
 | `GITHUB_ACTIONS`     | Immer auf `true` gesetzt, wenn {% data variables.product.prodname_actions %} den Workflow ausführt. Du kannst diese Variable verwenden, um zu differenzieren, wann Tests lokal oder von {% data variables.product.prodname_actions %} durchgeführt werden.                                                                                                                           |
 | `GITHUB_ACTOR`       | Name der Person oder App, die den Workflow initiiert hat. Beispiel: `octocat`.                                                                                                                                                                                                                                                                                                         |

translations/de-DE/content/actions/reference/environments.md

@@ -16,7 +16,7 @@ versions:
 You can configure environments with protection rules and secrets. When a workflow job references an environment, the job won't start until all of the environment's protection rules pass. A job also cannot access secrets that are defined in an environment until all the environment protection rules pass.
 
 {% if currentVersion == "free-pro-team@latest" %}
-Environment protection rules and environment secrets are only available on public repositories. If you convert a repository from public to private, any configured protection rules or environment secrets will be ignored, and you will not be able to configure any environments. If you convert your repository back to public, you will have access to any previously configured protection rules and environment secrets.
+Environment protection rules and environment secrets are only available on public repositories and private repositories on an enterprise plan. If you convert a repository from public to private on a non-enterprise plan, any configured protection rules or environment secrets will be ignored, and you will not be able to configure any environments. If you convert your repository back to public, you will have access to any previously configured protection rules and environment secrets.
 {% endif %}
 
 #### Environment protection rules

translations/de-DE/content/actions/reference/workflow-syntax-for-github-actions.md

@@ -122,7 +122,7 @@ Unter den Schlüsselwörtern `paths-ignore` und `paths` kannst Du Glob-Muster nu
 
 #### Beispiel zum Ignorieren von Pfaden
 
-Immer wenn ein Pfadname zu einem Muster in `paths-ignore` passt, wird der Workflow nicht ausgeführt. {% data variables.product.prodname_dotcom %} wertet die in `paths-ignore` definierten Muster anhand des Pfadnamens aus. Ein Workflow mit dem nachfolgenden Pfadfilter wird nur bei `push`-Ereignissen ausgeführt, bei denen sich mindestens eine Datei außerhalb des Verzeichnisses `docs` im Root des Repositorys befindet.
+When all the path names match patterns in `paths-ignore`, the workflow will not run. {% data variables.product.prodname_dotcom %} wertet die in `paths-ignore` definierten Muster anhand des Pfadnamens aus. Ein Workflow mit dem nachfolgenden Pfadfilter wird nur bei `push`-Ereignissen ausgeführt, bei denen sich mindestens eine Datei außerhalb des Verzeichnisses `docs` im Root des Repositorys befindet.
 
 ```yaml
 on:

translations/de-DE/content/admin/enterprise-management/about-geo-replication.md

@@ -22,6 +22,8 @@ Damit die Geo-Replikation ordnungsgemäß funktioniert, ist Geo DNS, beispielswe
 
 Zum Senden von Anforderungen an das Replikat müssen die Daten an die primäre Instanz und an alle Replikate gesendet werden. This means that the performance of all writes are limited by the slowest replica, although new geo-replicas can seed the majority of their data from existing co-located geo-replicas, rather than from the primary. Von der Geo-Replikation werden einer {% data variables.product.prodname_ghe_server %}-Instanz weder Kapazitäten hinzugefügt noch werden Leistungsprobleme in Bezug auf unzureichende CPU- oder Arbeitsspeicherressourcen behoben. Wenn die primäre Appliance offline ist, können aktive Replikate keine Lese- oder Schreibanforderungen verarbeiten.
 
+{% data reusables.enterprise_installation.replica-limit %}
+
 ### Geo-Replikationskonfiguration überwachen
 
 {% data reusables.enterprise_installation.monitoring-replicas %}

translations/de-DE/content/admin/enterprise-management/about-high-availability-configuration.md

@@ -14,6 +14,8 @@ Beim Konfigurieren der Hochverfügbarkeit gibt es eine automatisierte Einrichtun
 
 {% data variables.product.prodname_ghe_server %} unterstützt eine aktive/passive Konfiguration, bei der die Replikations-Appliance als Standby-Instanz mit Datenbankdiensten im Replikationsmodus ausgeführt wird, aber die Anwendungsdienste gestoppt werden.
 
+{% data reusables.enterprise_installation.replica-limit %}
+
 ### Anvisierte Fehlerszenarien
 
 Verwenden Sie eine Hochverfügbarkeitskonfiguration zum Schutz vor:

translations/de-DE/content/admin/enterprise-management/creating-a-high-availability-replica.md

@@ -10,6 +10,8 @@ topics:
   - Unternehmen
 ---
 
+{% data reusables.enterprise_installation.replica-limit %}
+
 ### Hochverfügbarkeitsreplikat erstellen
 
 1. Richten Sie eine neue {% data variables.product.prodname_ghe_server %}-Appliance auf Ihrer gewünschten Plattform ein. Die Replikat-Appliance sollte die CPU-, RAM- und Speichereinstellungen der primären Appliance spiegeln. Sie sollten die Replikat-Appliance in einer unabhängigen Umgebung installieren. Die zugrunde liegenden Hardware-, Software und Netzwerkkomponenten sollten von denen der primären Appliance isoliert sein. Wenn Sie einen Cloud-Anbieter verwenden, sollten Sie eine separate Region oder Zone verwenden. Weitere Informationen finden Sie unter „[{% data variables.product.prodname_ghe_server %}-Instanz einrichten](/enterprise/{{ currentVersion }}/admin/guides/installation/setting-up-a-github-enterprise-server-instance)“.

translations/de-DE/content/admin/policies/enforcing-policies-for-advanced-security-in-your-enterprise.md

@@ -4,10 +4,10 @@ intro: 'Enterprise owners can enforce policies to manage {% data variables.produ
 product: '{% data reusables.gated-features.ghas %}'
 versions:
   enterprise-server: '>=3.1'
-  github-ae: 'next'
+  github-ae: '*'
 ---
 
-### About {% data variables.product.prodname_GH_advanced_security %}
+### Informationen zu {% data variables.product.prodname_GH_advanced_security %}
 
 {% data reusables.advanced-security.ghas-helps-developers %}
 

translations/de-DE/content/admin/user-management/customizing-user-messages-for-your-enterprise.md

@@ -58,12 +58,21 @@ Mittels Markdown können Sie Ihre Meldung formatieren. Weitere Informationen fin
 {% if currentVersion ver_gt "enterprise-server@2.22" or currentVersion == "github-ae@latest" %}
 ### Creating a mandatory message
 
-You can create a mandatory message that {% data variables.product.product_name %} will show to all users the first time they sign in after you save the message. The message appears in a pop-up window that the user must dismiss before the user can use {% data variables.product.product_location %}. Mandatory messages have a variety of uses.
+You can create a mandatory message that {% data variables.product.product_name %} will show to all users the first time they sign in after you save the message. The message appears in a pop-up window that the user must dismiss before the user can use {% data variables.product.product_location %}.
+
+Mandatory messages have a variety of uses.
 
 - Providing onboarding information for new employees
 - Telling users how to get help with {% data variables.product.product_location %}
 - Ensuring that all users read your terms of service for using {% data variables.product.product_location %}
 
+{% note %}
+
+**Note:** After you configure a mandatory message for {% data variables.product.product_location %}, you cannot change or remove the message.
+
+{% endnote %}
+
+
 If you include Markdown checkboxes in the message, all checkboxes must be selected before the user can dismiss the message. For example, if you include your terms of service in the mandatory message, you can require that each user selects a checkbox to confirm the user has read the terms.
 
 Each time a user sees a mandatory message, an audit log event is created. The event includes the version of the message that the user saw. For more information see "[Audited actions](/admin/user-management/audited-actions)."