1
0
mirror of synced 2026-01-08 21:02:10 -05:00

Branch was updated using the 'autoupdate branch' Actions workflow.

This commit is contained in:
Octomerger Bot
2021-11-02 21:12:08 -04:00
committed by GitHub
16863 changed files with 0 additions and 789536 deletions

View File

@@ -1,44 +0,0 @@
---
title: Your account and profile on GitHub
shortTitle: Account and profile
intro: 'Make {% data variables.product.product_name %} work best for you by adjusting the settings for your user account, personalizing your profile page, and managing the notifications you receive for activity on {% data variables.product.prodname_dotcom %}.'
introLinks:
quickstart: /get-started/onboarding/getting-started-with-your-github-account
featuredLinks:
guides:
- /account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/changing-your-github-username
- '{% ifversion ghae %}/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/about-your-personal-dashboard{% endif %}'
- /account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/managing-your-profile-readme
- '{% ifversion ghae %}/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile{% endif %}'
- /account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/about-notifications
popular:
- /account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/managing-your-theme-settings
- /account-and-profile/setting-up-and-managing-your-github-user-account/managing-email-preferences/setting-your-commit-email-address
- /account-and-profile/setting-up-and-managing-your-github-user-account/managing-access-to-your-personal-repositories/inviting-collaborators-to-a-personal-repository
- /account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications
guideCards:
- /account-and-profile/setting-up-and-managing-your-github-profile/managing-contribution-graphs-on-your-profile/why-are-my-contributions-not-showing-up-on-my-profile
- /account-and-profile/managing-subscriptions-and-notifications-on-github/viewing-and-triaging-notifications/managing-notifications-from-your-inbox
- /account-and-profile/setting-up-and-managing-your-github-user-account/managing-email-preferences/blocking-command-line-pushes-that-expose-your-personal-email-address
- '{% ifversion ghes or ghae %}/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/managing-the-default-branch-name-for-your-repositories{% endif %}'
changelog:
label: 'profiles, github-themes, notifications'
versions:
fpt: '*'
ghec: '*'
layout: product-landing
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Accounts
- Profiles
- Notifications
children:
- /setting-up-and-managing-your-github-user-account
- /setting-up-and-managing-your-github-profile
- /managing-subscriptions-and-notifications-on-github
---

View File

@@ -1,22 +0,0 @@
---
title: Abonnements und Benachrichtigungen auf GitHub verwalten
intro: 'You can specify how to receive notifications, the repositories you are interested in, and the types of activity you want to hear about.'
redirect_from:
- /categories/76/articles/
- /categories/notifications/
- /categories/receiving-notifications-about-activity-on-github
- /github/managing-subscriptions-and-notifications-on-github
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Notifications
children:
- /setting-up-notifications
- /viewing-and-triaging-notifications
- /managing-subscriptions-for-activity-on-github
shortTitle: Subscriptions & notifications
---

View File

@@ -1,18 +0,0 @@
---
title: Verwaltung von Abonnements für Aktivitäten auf GitHub
intro: 'Um nachhaltige Workflows für Benachrichtigungen zu unterhalten, verstehe und überprüfe regelmäßig Deine Abonnements.'
redirect_from:
- /github/managing-subscriptions-and-notifications-on-github/managing-subscriptions-for-activity-on-github
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Notifications
children:
- /viewing-your-subscriptions
- /managing-your-subscriptions
shortTitle: Manage subscriptions
---

View File

@@ -1,73 +0,0 @@
---
title: Verwaltung Deiner Abonnements
intro: 'Um Dir zu helfen, Deine Benachrichtigungen effizient zu verwalten, gibt es mehrere Möglichkeiten, Dich abzumelden.'
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Notifications
redirect_from:
- /github/managing-subscriptions-and-notifications-on-github/managing-your-subscriptions
- /github/managing-subscriptions-and-notifications-on-github/managing-subscriptions-for-activity-on-github/managing-your-subscriptions
shortTitle: Manage your subscriptions
---
Um Dir zu helfen, Deine Abonnements zu verstehen und zu entscheiden, ob du Dich abmelden sollst, findest Du weitere Informationen auf „[Deine Abonnements ansehen](/github/managing-subscriptions-and-notifications-on-github/viewing-your-subscriptions)."
{% note %}
**Hinweis:** Anstatt Dich abzumelden, hast Du die Möglichkeit, ein Repository zu ignorieren. Wenn Du ein Repository ignorierst, erhältst du keine Benachrichtigungen. Es wird nicht empfohlen, Repositorys zu ignorieren, da Du in diesem Fall auch keine Benachrichtigung erhältst, wenn Du @erwähnt wirst. {% ifversion fpt or ghec %}If you're experiencing abuse and want to ignore a repository, please contact {% data variables.contact.contact_support %} so we can help. {% data reusables.policies.abuse %}{% endif %}
{% endnote %}
## Wähle die Art der Abmeldung
Um die Beobachtung von Repositorys schnell zu beenden oder Dich abzumelden, gehe auf die Seite „Watched repositories" (Beobachtete Repositorys), auf der Du alle von Dir beobachteten Repositorys siehst. Weitere Informationen findest Du unter „[Ein Repository nicht mehr beobachten](#unwatch-a-repository)."
Um mehrere Benachrichtigungen gleichzeitig abzumelden, kannst Du Dich über Deinen Posteingang oder über die Abonnementseite abmelden. Beide Optionen bieten mehr Kontext über Deine Abonnements als die Seite „Watched repositories" (beobachtete Repositorys).
### Vorteile der Abmeldung über Deinen Posteingang
Wenn du Benachrichtigungen in Deinem Posteingang abmeldest, hast Du mehrere weitere Selektionsoptionen und kannst Deine Benachrichtigungen nach benutzerdefinierten Filtern und Diskussionstypen auswählen. Weitere Informationen findest du unter „[Benachrichtigungen über Deinen Posteingang verwalten](/github/managing-subscriptions-and-notifications-on-github/managing-notifications-from-your-inbox)."
### Vorteile der Abmeldung von der Abonnementseite
Wenn Du Benachrichtigungen auf der Abonnementseite abmeldest, kannst Du mehr Details der von Dir abonnierten Benachrichtigungen sehen und sie nach „Most recently subscribed" (neueste Abonnements) oder „Least recently subscribed" (älteste Abonnements) sortieren.
Die Abonnements-Seite zeigt Dir alle Benachrichtigungen, die Du gerade abonniert hast, einschließlich Benachrichtigungen, die Du in Deinem Posteingang als **Done** (Erledigt) markiert hast.
Du kannst Deine Abonnements nur nach Repository und dem Grund filtern, warum Du die Benachrichtigung erhältst.
## Abmelden von Benachrichtigungen in Deinem Posteingang
Wenn Du Benachrichtigungen in Deinem Posteingang abmeldest, werden diese automatisch aus Deinem Posteingang verschwinden.
{% data reusables.notifications.access_notifications %}
1. Wähle im Posteingang für Benachrichtigungen diejenige Benachrichtigungen aus, die Du abmelden möchtest.
2. Click **Unsubscribe.** ![Unsubscribe option from main inbox](/assets/images/help/notifications-v2/unsubscribe-from-main-inbox.png)
## Abmeldung von Benachrichtigungen auf der Abonnementseite
{% data reusables.notifications.access_notifications %}
1. Verwende in der linken Seitenleiste, unterhalb der Liste der Repositorys, das Dropdownmenü „Manage Notifications" (Benachrichtigungen verwalten) und klicke auf **Subscriptions** (Abonnements). ![Dropdownmenü-Optionen „Manage Notifications" (Benachrichtigungen verwalten)](/assets/images/help/notifications-v2/manage-notifications-options.png)
2. Wähle die Benachrichtigungen, die Du abmelden möchtest. Klicke oben rechts auf **Unsubscribe** (Abmelden). ![Abonnementseite](/assets/images/help/notifications-v2/unsubscribe-from-subscriptions-page.png)
## Ein Repository nicht mehr beobachten
Wenn Du ein Repository nicht mehr beobachtest, meldest Du Dich von zukünftigen Aktualisierungen dieses Repositorys ab, außer wenn du an einer Unterhaltung teilnimmst oder @erwähnt wirst.
{% data reusables.notifications.access_notifications %}
1. Verwende in der linken Seitenleiste, unterhalb der Liste der Repositorys, das Dropdownmenü „Manage Notifications" (Benachrichtigungen verwalten) und klicke auf **Watched repositories** (beobachtete Repositorys). ![Dropdownmenü-Optionen „Manage Notifications" (Benachrichtigungen verwalten)](/assets/images/help/notifications-v2/manage-notifications-options.png)
2. Nimm auf der Seite der beobachteten Repositorys eine Bewertung dieser Repositorys vor und wähle dann aus:
{% ifversion fpt or ghes > 3.0 or ghae-next or ghec %}
- Ein Repository nicht mehr beobachten
- Ignore all notifications for a repository
- Customize the types of event you receive notifications for ({% data reusables.notifications-v2.custom-notification-types %}, if enabled)
{% else %}
- Ein Repository nicht mehr beobachten
- Only watch releases for a repository
- Ignore all notifications for a repository
{% endif %}

View File

@@ -1,86 +0,0 @@
---
title: Deine Abonnements anzeigen
intro: 'Um zu verstehen, woher und wie viele Benachrichtigungen Du erhältst, empfehlen wir Dir, Deine Abonnements und Deine beobachteten Repositorys regelmäßig zu überprüfen.'
redirect_from:
- /articles/subscribing-to-conversations/
- /articles/unsubscribing-from-conversations/
- /articles/subscribing-to-and-unsubscribing-from-notifications
- /articles/listing-the-issues-and-pull-requests-youre-subscribed-to
- /articles/watching-repositories/
- /articles/unwatching-repositories/
- /articles/watching-and-unwatching-repositories
- /articles/watching-and-unwatching-releases-for-a-repository
- /articles/watching-and-unwatching-team-discussions
- /articles/listing-watched-repositories/
- /articles/listing-the-repositories-you-re-watching
- /articles/listing-the-repositories-youre-watching
- /github/managing-subscriptions-and-notifications-on-github/viewing-your-subscriptions
- /github/managing-subscriptions-and-notifications-on-github/managing-subscriptions-for-activity-on-github/viewing-your-subscriptions
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Notifications
shortTitle: View subscriptions
---
Du erhältst Benachrichtigungen zu Deinen Abonnements über laufende Aktivitäten auf {% data variables.product.product_name %}. Es gibt mehrere Gründe, warum Du eine Unterhaltung abonniert haben kannst. Weitere Informationen findest Du unter „[Über Benachrichtigungen](/github/managing-subscriptions-and-notifications-on-github/about-notifications#notifications-and-subscriptions)."
Wir empfehlen Dir, Deine Abonnements als Teil eines effizienten Workflows für Benachrichtigungen zu überprüfen und allenfalls abzubestellen. Weitere Informationen über Deine Abmeldeoptionen findest Du unter „[Abonnements verwalten](/github/managing-subscriptions-and-notifications-on-github/managing-your-subscriptions)."
## Feststellen, warum Du zu viele Benachrichtigungen erhältst
Wenn Dein Posteingang zu viele Benachrichtigungen zum Verwalten hat, überlege Dir, ob du zu viele Abonnements hast oder wie Du Deine Benachrichtigungseinstellungen ändern kannst, um Deine Abonnements zu reduzieren und die Art von Benachrichtigungen, die Du erhältst. Beispielsweise kannst Du erwägen, die Einstellungen zum automatischen Beobachten aller Repositorys und Teamdiskussionen zu deaktivieren, wenn Du einem Team oder Repository beitrittst.
![Automatisches Beobachten](/assets/images/help/notifications-v2/automatic-watching-example.png)
Weitere Informationen findest Du unter „[Benachrichtigungen konfigurieren](/github/managing-subscriptions-and-notifications-on-github/configuring-notifications#automatic-watching)."
Eine Übersicht Deiner Repository-Abonnements findest Du unter „[Repositorys überprüfen, die Du beobachtest](#reviewing-repositories-that-youre-watching).
{% ifversion fpt or ghes > 3.0 or ghae-next or ghec %}
{% tip %}
**Tip:** You can select the types of event to be notified of by using the **Custom** option of the **Watch/Unwatch** dropdown list in your [watching page](https://github.com/watching) or on any repository page on {% data variables.product.product_name %}. Weitere Informationen findest Du unter „[Benachrichtigungen konfigurieren](/github/managing-subscriptions-and-notifications-on-github/configuring-notifications#configuring-your-watch-settings-for-an-individual-repository)."
{% endtip %}
{% endif %}
Viele Personen vergessen Repositorys, die sie in der Vergangenheit beobachtet haben. Über die Seite „Watched repositories" (beobachtete Repositorys) kannst Du die Beobachtung von Repositorys schnell deaktivieren. For more information on ways to unsubscribe, see "[Unwatch recommendations](https://github.blog/changelog/2020-11-10-unwatch-recommendations/)" on {% data variables.product.prodname_blog %} and "[Managing your subscriptions](/github/managing-subscriptions-and-notifications-on-github/managing-your-subscriptions)." You can also create a triage workflow to help with the notifications you receive. For guidance on triage workflows, see "[Customizing a workflow for triaging your notifications](/github/managing-subscriptions-and-notifications-on-github/customizing-a-workflow-for-triaging-your-notifications)."
## Alle Deine Abonnements überprüfen
{% data reusables.notifications.access_notifications %}
1. Verwende in der linken Seitenleiste, unterhalb der Liste der Repositorys, von denen Du Benachrichtigungen erhältst, das Dropdownmenü „Manage notifications" (Benachrichtigungen verwalten) und klicke auf **Subscriptions** (Abonnements). ![Dropdownmenü-Optionen „Manage Notifications" (Benachrichtigungen verwalten)](/assets/images/help/notifications-v2/manage-notifications-options.png)
2. Verwende Filter und Sortierung, um die Liste der Abonnements einzuschränken, und beginne Dich von Unterhaltungen abzumelden, von denen Du keine Benachrichtigungen mehr erhalten willst.
![Abonnementseite](/assets/images/help/notifications-v2/all-subscriptions.png)
{% tip %}
**Tipps:**
- Um Abonnements zu überprüfen, die du vergessen hast, sortiere nach „least recently subscribed" (älteste Abonnements).
- Um eine Liste von Repositories zu überprüfen, für die Du noch Benachrichtigungen erhalten kannst, erstelle die Repository-Liste im Dropdownmenü „filter by repository" (nach Repository filtern).
{% endtip %}
## Repositorys überprüfen, die Du beobachtest
1. Verwende in der linken Seitenleiste, unterhalb der Liste der Repositorys, das Dropdownmenü „Manage Notifications" (Benachrichtigungen verwalten) und klicke auf **Watched repositories** (beobachtete Repositorys). ![Dropdownmenü-Optionen „Manage Notifications" (Benachrichtigungen verwalten)](/assets/images/help/notifications-v2/manage-notifications-options.png)
2. Evaluiere die von Dir beobachteten Repositorys und entscheide, ob deren Aktualisierungen für Dich immer noch relevant und hilfreich sind. Wenn Du ein Repository beobachtest, wirst Du über alle Unterhaltungen für dieses Repository benachrichtigt.
{% ifversion fpt or ghes > 3.0 or ghae-next or ghec %}
![Seite der beobachteten Benachrichtigungen](/assets/images/help/notifications-v2/watched-notifications-custom.png)
{% else %}
![Seite der beobachteten Benachrichtigungen](/assets/images/help/notifications-v2/watched-notifications.png)
{% endif %}
{% tip %}
**Tip:** Instead of watching a repository, consider only receiving notifications {% ifversion fpt or ghes > 3.0 or ghae-next or ghec %}when there are updates to {% data reusables.notifications-v2.custom-notification-types %} (if enabled for the repository), or any combination of these options,{% else %}for releases in a repository,{% endif %} or completely unwatching a repository.
Wenn Du ein Repository nicht mehr beobachtest, kannst du immer noch benachrichtigt werden, wenn Du @erwähnt wirst oder in einem Thread teilnimmst. When you configure to receive notifications for certain event types, you're only notified when there are updates to these event types in the repository, you're participating in a thread, or you or a team you're on is @mentioned.
{% endtip %}

View File

@@ -1,104 +0,0 @@
---
title: Informationen zu Benachrichtigungen
intro: 'Benachrichtigungen bieten Aktualisierungen über die Aktivitäten auf {% data variables.product.product_location %} , die Du abonniert hast. Du kannst den Posteingang für Benachrichtigungen verwenden, um deine Updates anzupassen, zu selektieren und zu verwalten.'
redirect_from:
- /articles/notifications/
- /articles/about-notifications
- /github/managing-subscriptions-and-notifications-on-github/about-notifications-beta
- /github/managing-subscriptions-and-notifications-on-github/about-notifications
- /github/managing-subscriptions-and-notifications-on-github/setting-up-notifications/about-notifications
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Notifications
---
{% ifversion ghes %}
{% data reusables.mobile.ghes-release-phase %}
{% endif %}
## Benachrichtigungen und Abonnements
Über ein Abonnement kannst Du festlegen, dass Du Aktualisierungen zu bestimmten Aktivitäten auf {% data variables.product.product_location %} erhalten willst. Benachrichtigungen sind Aktualisierungen, die Du für bestimmte Aktivitäten erhältst, die Du abonniert hast.
### Abonnement-Optionen
Du kannst Benachrichtigungen abonnieren für:
- Eine Unterhaltung in einem spezifischen Issue, Pull Request oder Gist.
- Alle Aktivitäten in einem Repository oder in einer Team-Diskussion.
- CI-Aktivität wie beispielsweise der Status von Workflows in Repositorys, die mit {% data variables.product.prodname_actions %} aufgesetzt wurden. {% ifversion fpt or ghes > 3.0 or ghae-next or ghec %}
- Repository {% data reusables.notifications-v2.custom-notification-types %} (if enabled).{% else %}
- Releases in a repository.{% endif %}
Du kannst auch automatisch alle Repositorys überwachen, auf die Du Push-Zugriff hast, mit Ausnahme von Forks. Du kannst jedes andere Repository, auf das Du Zugriff hast, manuell verfolgen durch klicken auf **Watch** (Beobachten).
Wenn Du kein Interesse mehr an einer Unterhaltung hast, kannst Du das Abonnement abmelden oder die Art der Benachrichtigungen anpassen, die Du in der Zukunft erhalten willst. Wenn Du beispielsweise keine Benachrichtigungen mehr von einem bestimmten Repository erhalten möchtest, kannst Du **Unsubscribe** (Abmelden) klicken. Weitere Informationen findest Du unter „[Deine Abonnements verwalten](/github/managing-subscriptions-and-notifications-on-github/managing-your-subscriptions)."
### Standardabonnements
Im Allgemeinen wirst Du automatisch Unterhaltungen abonniert erhalten, wenn folgendes gilt:
- Du hast automatische Beobachtungen auf Repositories oder Teams, denen Du beigetreten bist, in Deinen Benachrichtigungseinstellungen nicht deaktiviert. Diese Einstellung ist standardmäßig aktiviert.
- Du bist einem Issue oder Pull Request zugewiesen worden.
- Du hast einen Pull Request oder einen Issue eröffnet oder Du hast einen Beitrag in einer Teamdiskussion erstellt.
- Du hast einen Thread kommentiert.
- Du hast manuell einen Thread abonniert, indem Du auf **Watch** (Beobachten) or **Subscribe** (Abonnieren) geklickt hast.
- Du wurdest mit Deinem Benutzernahmen @erwähnt.
- Du hast den Status eine Thread geändert, zum Beispiel durch Schließen eines Issues oder Zusammenführen eines Pull Request.
- Ein Team, dem Du angehörst, wurde @erwähnt.
Standardmäßig überwachst Du auch automatisch alle Repositorys, die Du erstellst und die im Besitz Deines Benutzerkonto sind.
Um für Unterhaltungen, die Du automatisch abonniert hast, keine Benachrichtigungen mehr zu erhalten, kannst Du Deine Benachrichtigungseinstellungen ändern oder die Abonnements und Beobachtungen für Aktivitäten auf {% data variables.product.product_location %} direkt abmelden. Weitere Informationen findest Du unter „[Deine Abonnements verwalten](/github/managing-subscriptions-and-notifications-on-github/managing-your-subscriptions)."
## Benachrichtigungen und Abonnements anpassen
You can choose to view your notifications through the notifications inbox at [https://github.com/notifications](https://github.com/notifications){% ifversion fpt or ghes or ghec %} and in the {% data variables.product.prodname_mobile %} app{% endif %}, through your email, or some combination of these options.
Konfiguriere Deine Benachrichtigungseinstellungen, um die Art von Aktualisierungen anzupassen, die Du erhalten möchtest, und wohin sie gesendet werden sollen. Weitere Informationen findest Du unter „[Benachrichtigungen konfigurieren](/github/managing-subscriptions-and-notifications-on-github/configuring-notifications)."
Um Deine Abonnements übersichtlich zu halten, überprüfe Deine Abonnements und Deine verfolgten Repositorys regelmäßig und melde sie bei Bedarf ab. Weitere Informationen findest Du unter „[Abonnements für Aktivitäten auf GitHub verwalten](/github/managing-subscriptions-and-notifications-on-github/managing-subscriptions-for-activity-on-github)."
Um anzupassen, wie Du Aktualisierungen für bestimmte Pull Requests oder Issues erhalten möchtest, kannst Du Deine Einstellungen innerhalb des Issues oder Pull Requests konfigurieren. Weitere Informationen findest Du unter „[Eine einzelne Benachrichtigung auswählen](/github/managing-subscriptions-and-notifications-on-github/triaging-a-single-notification#customizing-when-to-receive-future-updates-for-an-issue-or-pull-request)."
{% ifversion fpt or ghes or ghec %}
You can customize and schedule push notifications in the {% data variables.product.prodname_mobile %} app. Weitere Informationen findest Du unter „[Benachrichtigungen konfigurieren](/github/managing-subscriptions-and-notifications-on-github/configuring-notifications#managing-your-notification-settings-with-github-for-mobile)."
{% endif %}
## Gründe für den Erhalt von Benachrichtigungen
Dein Posteingang ist mit Standardfiltern konfiguriert, die die häufigsten Gründe dafür darstellen, warum Personen ihre Benachrichtigungen nachverfolgen müssen. Weitere Informationen über Posteingang-Filter findest Du unter „[Benachrichtigungen über Deinen Posteingang verwalten](/github/managing-subscriptions-and-notifications-on-github/managing-notifications-from-your-inbox#default-notification-filters)."
Dein Posteingang zeigt eine Kennzeichnung für die `Gründe`, weshalb Du eine Benachrichtigungen erhältst.
![Begründungskennzeichnungen im Posteingang](/assets/images/help/notifications-v2/reasons-as-labels-in-inbox.png)
Du kannst Deinen Posteingang nach dem Grund filtern, warum Du Benachrichtigungen abonniert hast. Um beispielsweise nur Pull Requests zu sehen, für die jemand Deinen Review angefordert hast, kannst Du `review-requested` als Abfragefilter verwenden.
![Filtere Benachrichtigungen nach "Review Requested" (Review angefordert)](/assets/images/help/notifications-v2/review-requested-reason.png)
Wenn du Benachrichtigungen so konfiguriert hast, dass sie per E-Mail gesendet werden und Du glaubst, dass Du Benachrichtigungen erhältst, die nicht zu Dir gehören, versuche die Fehlerbehebung über E-Mail-Kopfzeilen, die den beabsichtigten Empfänger anzeigen. Weitere Informationen findest Du unter „[Benachrichtigungen konfigurieren](/github/managing-subscriptions-and-notifications-on-github/configuring-notifications#filtering-email-notifications)."
## Benachrichtigungen in Deinem Posteingang selektieren
Um Deine Benachrichtigungen effektiv zu verwalten, kannst Du sie in Deinem Posteingang mit folgenden Optionen selektieren:
- Entferne eine Benachrichtigung aus dem Posteingang mit **Done** (Erledigt). Du kannst Benachrichtigungen mit Kennzeichnung **Done** (Erledigt) alle an einem Ort überprüfen, indem Du in der Seitenleiste auf **Done** (Erledigt) klickst oder indem Du die Abfrage `is:done` benutzt.
- Markiere eine Benachrichtigung als gelesen oder ungelesen.
- **Save** (Sichere) eine Benachrichtigung für eine spätere Überprüfung. **Saved** (Gesicherte) Benachrichtigungen sind in Deinem Posteingang markiert. Du kannst Benachrichtigungen mit Kennzeichnung **Saved** (Gesichert) alle an einem Ort überprüfen, indem Du in der Seitenleiste auf **Saved** (Gesichert) klickst oder indem Du die Abfrage `is:saved` benutzt.
- Melde eine Benachrichtigung automatisch ab und auch künftige Aktualisierungen dieser Unterhaltung. Das Abmelden entfernt die Benachrichtigung auch aus Deinem Posteingang. Wenn Du Dich aus einer Unterhaltung abmeldest und später jemandem Deinen Benutzernamen oder ein Team erwähnt, von dem Du Aktualisierungen erhältst, dann wirst Du wieder Benachrichtigungen von dieser Unterhaltung erhalten.
Aus Deinem Posteingang heraus kannst Du auch mehrere Benachrichtigungen auf einmal selektieren. Weitere Informationen findest Du unter „[Benachrichtigungen über Deinen Posteingang verwalten](/github/managing-subscriptions-and-notifications-on-github/managing-notifications-from-your-inbox#triaging-multiple-notifications-at-the-same-time)."
## Deinen Posteingang für Benachrichtigungen anpassen
To focus on a group of notifications in your inbox on {% data variables.product.product_location %}{% ifversion fpt or ghes or ghec %} or {% data variables.product.prodname_mobile %}{% endif %}, you can create custom filters. Zum Beispiel kannst Du einen benutzerdefinierten Filter für ein Open-Source-Projekt erstellen, zu dem Du beiträgst, und nur Benachrichtigungen für das Repository sehen, in dem Du erwähnt bist. Weitere Informationen findest du unter „[Benachrichtigungen über Deinen Posteingang verwalten](/github/managing-subscriptions-and-notifications-on-github/managing-notifications-from-your-inbox)." Weitere Beispiele für die Anpassung Deines Selektions-Workflows findest Du unter „[Einen Workflow für das Selektieren Deiner Benachrichtigungen anpassen](/github/managing-subscriptions-and-notifications-on-github/customizing-a-workflow-for-triaging-your-notifications)."
## Richtlinie zur Aufbewahrung von Benachrichtigungen
Benachrichtigungen, die nicht als **Saved** (Gesichert) markiert sind, werden für 5 Monate aufbewahrt. Benachrichtigungen, die als **Saved** (Gesichert) markiert sind, werden unbegrenzt aufbewahrt. Wenn Deine gesicherte Benachrichtigung älter als 5 Monate ist und Du die „gesichert" Markierung entfernst, wird die Benachrichtigung innerhalb eines Tages aus Deinem Posteingang entfernt.
## Feedback und Support
Wenn Du Feedback oder Funktionsanfragen für Benachrichtigungen hast, benutze das [Feedback Formular für Benachrichtigungen](https://support.github.com/contact/feedback?contact%5Bcategory%5D=notifications&contact%5Bsubject%5D=Product+feedback).

View File

@@ -1,256 +0,0 @@
---
title: Benachrichtigungen konfigurieren
intro: 'Wähle die Art der Aktivitäten auf {% data variables.product.prodname_dotcom %} , für die Du Benachrichtigungen erhalten möchtest und wie Du diese Aktualisierungen erhalten möchtest.'
redirect_from:
- /articles/about-web-notifications
- /format-of-notification-emails/
- /articles/configuring-notification-emails/
- /articles/about-notification-emails/
- /articles/about-email-notifications
- /articles/accessing-your-notifications
- /articles/configuring-notification-delivery-methods/
- /articles/managing-notification-delivery-methods/
- /articles/managing-notification-emails-for-organizations/
- /articles/choosing-the-delivery-method-for-your-notifications
- /articles/choosing-the-types-of-notifications-you-receive/
- /github/managing-subscriptions-and-notifications-on-github/configuring-notifications
- /github/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Notifications
---
{% ifversion ghes %}
{% data reusables.mobile.ghes-release-phase %}
{% endif %}
## Zustellungsoptionen für Benachrichtigungen
You can receive notifications for activity on {% data variables.product.product_location %} in the following locations.
- The notifications inbox in the {% data variables.product.product_location %} web interface{% ifversion fpt or ghes or ghec %}
- The notifications inbox on {% data variables.product.prodname_mobile %}, which syncs with the inbox on {% data variables.product.product_location %}{% endif %}
- An email client that uses a verified email address, which can also sync with the notifications inbox on {% data variables.product.product_location %}{% ifversion fpt or ghes or ghec %} and {% data variables.product.prodname_mobile %}{% endif %}
{% ifversion fpt or ghes or ghec %}
{% data reusables.notifications-v2.notifications-inbox-required-setting %} Weitere Informationen findest Du auf „[Deine Benachrichtigungseinstellungen wählen](#choosing-your-notification-settings)."
{% endif %}
{% data reusables.notifications.shared_state %}
### Benefits of the notifications inbox
The notifications inbox on {% data variables.product.product_location %}{% ifversion fpt or ghes or ghec %} and {% data variables.product.prodname_mobile %}{% endif %} includes triaging options designed specifically for your {% data variables.product.prodname_dotcom %} notifications flow, including options to:
- Selektieren mehrerer Benachrichtigungen auf einmal.
- Erledigte Benachrichtigungen als **Done** (Erledigt) markieren und aus dem Posteingang entfernen. Um alle Deine Benachrichtigungen anzuzeigen, die als **Done** markiert sind, verwende die Abfrage mit `is:done`.
- Sichere eine Benachrichtigung für späteren Review. Gesicherte Benachrichtigungen sind in Deinem Posteingang markiert und werden auf unbestimmte Zeit gehalten. Um alle Deine gesicherten Benachrichtigungen zu sehen, benutze die Abfrage mit `is:saved`.
- Melde eine Benachrichtigung ab und entferne sie aus dem Posteingang.
- Vorschau des Issue, Pull Request oder der Team-Diskussion, aus der die Benachrichtigung auf {% data variables.product.product_location %} erstellt wurde, direkt aus dem Posteingang der Benachrichtigungen.
- Siehe einen der neuesten Gründe, weshalb Du eine Benachrichtigung erhältst, über die Kennzeichnung `reasons` (Grund) in Deinem Posteingang.
- Erstelle benutzerdefinierte Filter, um auf Wunsch auf verschiedene Benachrichtigungen fokussieren zu können.
- Gruppiere Benachrichtigungen in Deinem Posteingang nach Repository oder Datum, um einen schnellen Überblick mit weniger Kontextwechseln zu erhalten
{% ifversion fpt or ghes or ghec %}
In addition, you can receive and triage notifications on your mobile device with {% data variables.product.prodname_mobile %}. For more information, see "[Managing your notification settings with GitHub for mobile](#managing-your-notification-settings-with-github-for-mobile)" or "[GitHub for mobile](/github/getting-started-with-github/github-for-mobile)."
{% endif %}
### Vorteile beim Benutzen eines E-Mail-Client für Benachrichtigungen
Ein Vorteil der Verwendung eines E-Mail-Clients ist, dass alle Deine Benachrichtigungen unbegrenzt aufbewahrt werden können, abhängig von der Speicherkapazität Deines E-Mail-Clients. Your inbox notifications are only kept for 5 months on {% data variables.product.prodname_dotcom %} unless you've marked them as **Saved**. Mit **Saved** (Gesichert) markierte Benachrichtigungen werden unbegrenzt gespeichert. Weitere Informationen zur Aufbewahrungsrichtlinie Deines Posteingangs findest Du unter „[Über Benachrichtigungen](/github/managing-subscriptions-and-notifications-on-github/about-notifications#notification-retention-policy)."
Benachrichtigungen an Deinen E-Mail-Client zu senden erlaubt Dir auch, Deinen Posteingang mit allen Einstellungen deines E-Mail-Clients anzupassen, welche allenfalls benutzerdefinierte oder farbcodierte Kennzeichnungen beinhalten.
E-Mail-Benachrichtigungen ermöglichen auch Flexibilität bei der Art von Benachrichtigungen, die Du erhältst und erlauben Dir die Auswahl verschiedener E-Mail-Adressen für Aktualisierungen. Beispielsweise kannst Du bestimmte Benachrichtigungen für ein Repository an die verifizierte persönliche E-Mail-Adresse senden. Weitere Informationen über E-Mail-Anpassungsoptionen findest Du unter „[Deine E-Mail-Benachrichtigungen anpassen](#customizing-your-email-notifications)."
## Über die Teilnahme und das Beobachten von Benachrichtigungen
Wenn Du ein Repository beobachtest, abonnierst Du Aktualisierungen für Aktivitäten in diesem Repository. Ebenfalls, wenn Du die Diskussionen eines bestimmten Teams verfolgst, abonnierst Du alle Aktualisierungen der Unterhaltung auf der Seite dieses Teams. Weitere Informationen finden Sie unter „[Informationen zu Teamdiskussionen](/organizations/collaborating-with-your-team/about-team-discussions)“.
To see repositories that you're watching, go to your [watching page](https://github.com/watching). Weitere Informationen findest Du unter „[Abonnements und Benachrichtigungen auf GitHub verwalten](/github/managing-subscriptions-and-notifications-on-github/managing-subscriptions-for-activity-on-github)."
{% ifversion ghae or ghes < 3.1 %}
### Benachrichtigungen konfigurieren
{% endif %}
You can configure notifications for a repository on the repository page, or on your watching page.{% ifversion ghes < 3.1 %} You can choose to only receive notifications for releases in a repository, or ignore all notifications for a repository.{% endif %}
{% ifversion fpt or ghes > 3.0 or ghae-next or ghec %}
### About custom notifications
You can customize notifications for a repository. For example, you can choose to only be notified when updates to one or more types of events ({% data reusables.notifications-v2.custom-notification-types %}) happen within a repository, or ignore all notifications for a repository.
{% endif %} For more information, see "[Configuring your watch settings for an individual repository](#configuring-your-watch-settings-for-an-individual-repository)" below.
### Participating in conversations
Jedes Mal, wenn Du in einer Unterhaltung kommentierst oder wenn jemand Deinen Benutzernamen @erwähnt, bist Du _Teilnehmer_ in einer Unterhaltung. Standardmäßig abonnierst Du automatisch eine Unterhaltung, wenn Du daran teilnimmst. Du kannst Dich manuell von einer Unterhaltung abmelden, an der Du teilgenommen hast, indem Du auf dem Issue oder Pull Request auf **Unsubscribe** (Abmelden) klickst oder durch die Option **Unsubscribe** (Abmelden) im Posteingang für Benachrichtigungen.
For conversations you're watching or participating in, you can choose whether you want to receive notifications by email or through the notifications inbox on {% data variables.product.product_location %}{% ifversion fpt or ghes or ghec %} and {% data variables.product.prodname_mobile %}{% endif %}.
![Optionen für Teilnahme- und Beobachtungs-Benachrichtigungen](/assets/images/help/notifications-v2/participating-and-watching-options.png)
Ein Beispiel:
- Wenn Du nicht möchtest, dass Benachrichtigungen an Deine E-Mail gesendet werden, deaktiviere **email** (E-Mail) für die Teilnahme und das Beobachten von Benachrichtigungen.
- Wenn Du Benachrichtigungen per E-Mail erhalten möchtest, wenn Du an einer Unterhaltung teilgenommen hast, kannst du **email** (E-Mail) unter „Participating" (Teilnehmen) auswählen.
If you do not enable watching or participating notifications for web{% ifversion fpt or ghes or ghec %} and mobile{% endif %}, then your notifications inbox will not have any updates.
## E-Mail-Benachrichtigungen anpassen
Nach der Aktivierung von E-Mail-Benachrichtigungen sendet Ihnen {% data variables.product.product_location %} Benachrichtigungen als mehrteilige E-Mails, die sowohl HTML als auch reine Textkopien des Inhalts enthalten. Der Inhalt der E-Mail-Benachrichtigung umfasst alle Markdowns, @Erwähnungen, Emojis, Hash-Links usw., die im ursprünglichen Inhalt auf {% data variables.product.product_location %} erscheinen. Wenn Du nur den Text in der E-Mail sehen möchtest, kannst Du Deinen E-Mail-Client so konfigurieren, dass er nur die reine Textkopie anzeigt.
{% data reusables.notifications.outbound_email_tip %}
{% data reusables.notifications.shared_state %}
{% ifversion fpt or ghec %}
Wenn Sie Gmail verwenden, können Sie auf eine Schaltfläche neben der Benachrichtigungs-E-Mail klicken, um den ursprünglichen Issue bzw. Pull Request anzuzeigen, der die Benachrichtigung generiert hat.
![Schaltflächen in Gmail](/assets/images/help/notifications/gmail-buttons.png)
{% endif %}
Wähle eine Standard-E-Mail-Adresse, an die Du Aktualisierungen für Unterhaltungen senden willst, an denen Du teilnimmst oder die Du beobachtest. Du kannst auch definieren, für welche Aktivitäten auf {% data variables.product.product_location %} Du Aktualisierungen über Deine Standard-E-Mail-Adresse erhalten willst. Wähle zum Beispiel aus, ob Du Aktualisierungen an Deine Standard-E-Mail senden möchtest für:
- Kommentare für Issues und Pull Requests.
- Pull-Request-Reviews.
- Pull-Request-Pushes.
- Deine eigenen Aktualisierungen, wie wenn Du beispielsweise einen Issue oder Pull Request öffnest, kommentierst oder schließt.
Depending on the organization that owns the repository, you can also send notifications to different email addresses. Deine Organisation verlangt möglicherweise, dass E-Mail-Adressen für bestimmte Domänen verifiziert sein müssen. For more information, see "[Choosing where your organizations email notifications are sent](/github/managing-subscriptions-and-notifications-on-github/configuring-notifications#choosing-where-your-organizations-email-notifications-are-sent)."
You can also send notifications for a specific repository to an email address. Weitere Informationen findest Du unter "[Informationen zu E-Mail-Benachrichtigungen für Pushes in Dein Repository](/github/administering-a-repository/about-email-notifications-for-pushes-to-your-repository)."
{% data reusables.notifications-v2.email-notification-caveats %}
## E-Mail-Benachrichtigungen filtern
Jede E-Mail-Benachrichtigung, die {% data variables.product.product_location %} sendet, enthält Headerinformationen. Die Headerinformationen in jeder E-Mail sind einheitlich, sodass Sie sie in Ihrem E-Mail-Client verwenden können, um alle {% data variables.product.prodname_dotcom %}-Benachrichtigungen oder bestimmte Arten von {% data variables.product.prodname_dotcom %}-Benachrichtigungen zu filtern oder weiterzuleiten.
Wenn Du glaubst, dass Du Benachrichtigungen erhältst, die nicht zu Dir gehören, überprüfe die Header für `X-GitHub-Recipient` (Empfänger) und `X-GitHub-Recipient-Address` (Empfänger-Adresse). Diese Header zeigen an, wer der beabsichtigte Empfänger ist. Abhängig von Deiner E-Mail-Einrichtung erhältst Du möglicherweise Benachrichtigungen für einen anderen Benutzer.
E-Mail-Benachrichtigungen von {% data variables.product.product_location %} enthalten die folgenden Headerinformationen:
| Header | Informationen |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `From`-Adresse | Diese Adresse entspricht immer {% ifversion fpt or ghec %}'`notifications@github.com`'{% else %}'der von Deinem Websiteadministrator konfigurierten no-reply-E-Mail-Adresse'{% endif %}. |
| `To`-Feld | This field connects directly to the thread.{% ifversion not ghae %} If you reply to the email, you'll add a new comment to the conversation.{% endif %}
| `Cc`-Adresse | {% data variables.product.product_name %} fügt Sie zu `Cc` hinzu, wenn Sie eine Unterhaltung abonniert haben. Die zweite E-Mail-Adresse in `Cc` entspricht dem Benachrichtigungsgrund. Das Suffix für diese Benachrichtigungsgründe lautet {% data variables.notifications.cc_address %}. Zu den möglichen Benachrichtigungsgründen gehören folgende: <ul><li>`assign`: Dir wurde ein Issue oder Pull Request zugewiesen.</li><li>`author`: Du hast einen Issue oder Pull Request erstellt.</li><li>`ci_activity`: A {% data variables.product.prodname_actions %} workflow run that you triggered was completed.</li><li>`comment`: Du hast einen Issue oder Pull Request kommentiert.</li><li>`manual`: Ein Issue oder Pull Request, den Du manuell abonniert hast, wurde aktualisiert.</li><li>`mention`: Du wurdest in einem Issue oder Pull Request erwähnt.</li><li>`push`: Jemand hat einen Commit für einen Pull Request erstellt, den Du abonniert hast.</li><li>`review_requested`: Du oder ein Team, dem Du angehörst, wurdest/wurde gebeten, einen Review für einen Pull Request durchzuführen.</li>{% ifversion fpt or ghes or ghae-issue-4864 or ghec %}<li>`security_alert`: {% data variables.product.prodname_dotcom %} hat eine Schwachstelle in einem Repository erkannt, für das Du Sicherheitswarnungen erhältst.</li>{% endif %}<li>`state_change`: Ein Issue oder Pull Request, den Du abonniert hast, wurde entweder geschlossen oder geöffnet.</li><li>`subscribed`: Es gab eine Aktualisierung in einem Repository, das Du beobachtest.</li><li>`team_mention`: Ein Team, dem Du angehörst, wurde in einem Issue oder Pull Request erwähnt.</li><li>`your_activity`: Du hast einen Issue oder Pull Request geöffnet, kommentiert oder geschlossen.</li></ul> |
| `mailing list`-Feld | In diesem Feld werden der Name des Repositorys und sein Inhaber identifiziert. Das Format dieser Adresse lautet immer `<repository name>.<repository owner>.{% data variables.command_line.backticks %}`. |{% ifversion fpt or ghes or ghae-issue-4864 or ghec %}
| `X-GitHub-Severity`-Feld | {% data reusables.repositories.security-alerts-x-github-severity %} Die möglichen Schweregrade sind:<ul><li>`low`</li><li>`moderate`</li><li>`high`</li><li>`critical`</li></ul>For more information, see "[About alerts for vulnerable dependencies](/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies)." |
{% endif %}
## Wähle Deine Benachrichtigungseinstellungen
{% data reusables.notifications.access_notifications %}
{% data reusables.notifications-v2.manage-notifications %}
3. Auf der Seite für Benachrichtigungseinstellungen wählst Du, wie Du Benachrichtigungen erhalten willst, wenn:
- Es Aktualisierungen in Repositories oder Teamdiskussionen gibt, die Du beobachtest, oder in einer Unterhaltung, an der Du teilnimmst. Weitere Informationen findest Du unter „[Über die Teilnahme an und das Beobachten von Benachrichtigungen](#about-participating-and-watching-notifications)."
- Du Zugriff erhältst auf ein neues Repository oder wenn Du einem neuen Team beigetreten bist. For more information, see "[Automatic watching](#automatic-watching)."{% ifversion fpt or ghes or ghae-issue-4864 or ghec %}
- There are new {% if page.version == 'dotcom' %} {% data variables.product.prodname_dependabot_alerts %} {% else %} security alerts {% endif %} in your repository. Weitere Informationen findest Du unter „[{% data variables.product.prodname_dependabot_alerts %} Benachrichtigungsoptionen](#dependabot-alerts-notification-options)." {% endif %} {% ifversion fpt or ghec %}
- Es Aktualisierungen zu Workflow-Ausführungen auf Repositorys gibt, die mit {% data variables.product.prodname_actions %} aufgesetzt wurden. For more information, see "[{% data variables.product.prodname_actions %} notification options](#github-actions-notification-options)."{% endif %}
## Automatisches Beobachten
Standardmäßig wirst Du jedes Mal, wenn Du Zugriff auf ein neues Repository erhältst, automatisch mit der Beobachtung dieses Repository beginnen. Jedes mal, wenn Du einem neuen Team beitrittst, abonnierst Du automatisch Aktualisierungen und erhältst Benachrichtigungen, wenn dieses Team @erwähnt ist. Wenn Du keine automatischen Abonnements möchtest, kannst Du die automatischen Beobachtungsoptionen deaktivieren.
![Optionen für automatisches Beobachten](/assets/images/help/notifications-v2/automatic-watching-options.png)
Wenn "Automatisch Repositories beobachten" deaktiviert ist, wirst Du auch nicht automatisch Deine eigenen Repositorys beobachten. Du musst dann zu Deiner Repository-Seite navigieren und die Beobachtungsoption wählen.
## Konfiguration der Beobachtungseinstellungen für ein einzelnes Repository
Du kannst wählen, ob Du ein einzelnes Repository ansehen möchtest oder nicht mehr. You can also choose to only be notified of {% ifversion fpt or ghes > 3.0 or ghae-next or ghec %}certain event types such as {% data reusables.notifications-v2.custom-notification-types %} (if enabled for the repository) {% else %}new releases{% endif %}, or completely ignore an individual repository.
{% data reusables.repositories.navigate-to-repo %}
2. In the upper-right corner, select the "Watch" drop-down menu to click a watch option.
{% ifversion fpt or ghes > 3.0 or ghae-issue-4910 or ghec %}
![Beobachtungsoptionen in einem Dropdownmenü für ein Repository](/assets/images/help/notifications-v2/watch-repository-options-custom.png)
The **Custom** option allows you to further customize notifications so that you're only notified when specific events happen in the repository, in addition to participating and @mentions.
{% else %}
![Beobachtungsoptionen in einem Dropdownmenü für ein Repository](/assets/images/help/notifications-v2/watch-repository-options.png){% endif %}
{% ifversion fpt or ghes > 3.0 or ghae-issue-4910 or ghec %}
![Custom watch options in a drop-down menu for a repository](/assets/images/help/notifications-v2/watch-repository-options-custom2-dotcom.png) If you select "Issues", you will be notified about, and subscribed to, updates on every issue (including those that existed prior to you selecting this option) in the repository. If you're @mentioned in a pull request in this repository, you'll receive notifications for that too, and you'll be subscribed to updates on that specific pull request, in addition to being notified about issues.
{% endif %}
## Wähle, wohin die E-Mail-Benachrichtigungen Deiner Organisation gesendet werden
Wenn Sie einer Organisation angehören, können Sie das E-Mail-Konto auswählen, an das die Benachrichtigungen für Aktivitäten in der Organisation gesendet werden sollen. Wenn Sie z. B. einer Organisation für die Arbeit angehören, könnten Sie sich die Benachrichtigungen an Ihre berufliche E-Mail-Adresse senden lassen statt an Ihre private.
{% data reusables.notifications-v2.email-notification-caveats %}
{% data reusables.notifications.access_notifications %}
{% data reusables.notifications-v2.manage-notifications %}
3. Wählen Sie unter „Default notification email“ (Standardmäßige Benachrichtigungs-E-Mail-Adresse) die E-Mail-Adresse aus, an die Benachrichtigungen gesendet werden sollen.
![Dropdownmenü mit standardmäßiger Benachrichtigungs-E-Mail-Adresse](/assets/images/help/notifications/notifications_primary_email_for_orgs.png)
4. Klicke auf **Save** (Speichern).
### E-Mail-Routen pro Organisation anpassen
If you are a member of more than one organization, you can configure each one to send notifications to any of{% ifversion fpt or ghec %} your verified email addresses{% else %} the email addresses for your account{% endif %}. {% ifversion fpt or ghec %} For more information, see "[Verifying your email address](/articles/verifying-your-email-address)."{% endif %}
{% data reusables.notifications.access_notifications %}
{% data reusables.notifications-v2.manage-notifications %}
3. Suchen Sie in der Liste unter „Custom routing“ (Benutzerdefiniertes Routing) den Namen Ihrer Organisation.
![Liste der Organisationen und E-Mail-Adressen](/assets/images/help/notifications/notifications_org_emails.png)
4. Klicke neben der E-Mail-Adresse, die Du ändern möchtest, auf **Edit** (Bearbeiten). ![E-Mail-Adressen einer Organisation bearbeiten](/assets/images/help/notifications/notifications_edit_org_emails.png)
5. Wähle eine Deiner verifizierten E-Mail-Adressen aus, und klicke dann auf **Save** (Speichern).
![Eigene E-Mail-Adressen pro Organisation ändern](/assets/images/help/notifications/notifications_switching_org_email.gif)
{% ifversion fpt or ghes or ghae-issue-4864 or ghec %}
## {% data variables.product.prodname_dependabot_alerts %} Benachrichtigungsoptionen
{% data reusables.notifications.vulnerable-dependency-notification-enable %}
{% data reusables.notifications.vulnerable-dependency-notification-delivery-method-customization2 %}
{% data reusables.notifications.vulnerable-dependency-notification-options %}
For more information about the notification delivery methods available to you, and advice on optimizing your notifications for {% ifversion fpt or ghes or ghec %}{% data variables.product.prodname_dependabot_alerts %}{% else %}security alerts{% endif %}, see "[Configuring notifications for vulnerable dependencies](/github/managing-security-vulnerabilities/configuring-notifications-for-vulnerable-dependencies)."
{% endif %}
{% ifversion fpt or ghes or ghec %}
## {% data variables.product.prodname_actions %} Benachrichtigungsoptionen
Wähle, wie Du Aktualisierungen für Workflow-Ausführungen erhalten willst für Repositorys, die Du beobachtest und die mit {% data variables.product.prodname_actions %} aufgesetzt sind. Du kannst auch wählen, nur Benachrichtigungen für fehlgeschlagene Workflow-Ausführungen zu erhalten.
![Notification options for {% data variables.product.prodname_actions %}](/assets/images/help/notifications-v2/github-actions-notification-options.png)
{% endif %}
{% ifversion fpt or ghes or ghec %}
## Managing your notification settings with {% data variables.product.prodname_mobile %}
Wenn Du {% data variables.product.prodname_mobile %} installierst, bist Du automatisch für Web-Benachrichtigungen abonniert. Within the app, you can enable push notifications for the following events.
- Direct mentions
- Assignments to issues or pull requests
- Requests to review a pull request
- Requests to approve a deployment
You can also schedule when {% data variables.product.prodname_mobile %} will send push notifications to your mobile device.
{% data reusables.mobile.push-notifications-on-ghes %}
### Managing your notification settings with {% data variables.product.prodname_ios %}
1. In the bottom menu, tap **Profile**.
2. Um deine Einstellungen zu sehen, tippe auf {% octicon "gear" aria-label="The Gear icon" %}.
3. To update your notification settings, tap **Notifications** and then use the toggles to enable or disable your preferred types of push notifications.
4. Optionally, to schedule when {% data variables.product.prodname_mobile %} will send push notifications to your mobile device, tap **Working Hours**, use the **Custom working hours** toggle, and then choose when you would like to receive push notifications.
### Managing your notification settings with {% data variables.product.prodname_android %}
1. In the bottom menu, tap **Profile**.
2. Um deine Einstellungen zu sehen, tippe auf {% octicon "gear" aria-label="The Gear icon" %}.
3. To update your notification settings, tap **Configure Notifications** and then use the toggles to enable or disable your preferred types of push notifications.
4. Optionally, to schedule when {% data variables.product.prodname_mobile %} will send push notifications to your mobile device, tap **Working Hours**, use the **Custom working hours** toggle, and then choose when you would like to receive push notifications.
## Configuring your watch settings for an individual repository with {% data variables.product.prodname_mobile %}
Du kannst wählen, ob Du ein einzelnes Repository ansehen möchtest oder nicht mehr. You can also choose to only be notified of {% ifversion fpt or ghec %}certain event types such as issues, pull requests, discussions (if enabled for the repository) and {% endif %}new releases, or completely ignore an individual repository.
1. Navigieren Sie in {% data variables.product.prodname_mobile %} zur Repository-Hauptseite.
2. Tap **Watch**. ![The watch button on {% data variables.product.prodname_mobile %}](/assets/images/help/notifications-v2/mobile-watch-button.png)
3. To choose what activities you receive notifications for, tap your preferred watch settings. ![Watch settings dropdown menu in {% data variables.product.prodname_mobile %}](/assets/images/help/notifications-v2/mobile-watch-settings.png)
{% endif %}

View File

@@ -1,18 +0,0 @@
---
title: Benachrichtigungen einrichten
intro: 'Um die Relevanz Deiner Benachrichtigungen zu verbessern und den Selektions-Workflow zu vereinfachen, richte Deine Benachrichtigungen entsprechend Deinen Prioritäten ein.'
redirect_from:
- /articles/getting-started-with-notifications
- /github/managing-subscriptions-and-notifications-on-github/setting-up-notifications
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Notifications
children:
- /about-notifications
- /configuring-notifications
---

View File

@@ -1,73 +0,0 @@
---
title: Anpassen eines Workflows zum Selektieren Deiner Benachrichtigungen
intro: 'Um einen idealen Workflow für das Selektieren Deiner Benachrichtigungen zu erstellen, kannst Du diese Workflow-Beispiele übernehmen und anpassen.'
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Notifications
redirect_from:
- /github/managing-subscriptions-and-notifications-on-github/customizing-a-workflow-for-triaging-your-notifications
- /github/managing-subscriptions-and-notifications-on-github/viewing-and-triaging-notifications/customizing-a-workflow-for-triaging-your-notifications
shortTitle: Triage your notifications
---
## Beginne Deine Posteingang-Selektion
Bevor Du mit der Selektion in Deinem Posteingang beginnst, überlege Dir, ob Du zuerst die wichtigsten Aktualisierungen finden und beantworten möchtest, oder ob Du zuerst Deinen Posteingang von störenden Benachrichtigungen leeren möchtest, die einfach zu finden und zu entfernen sind.
Ja nach Anzahl Deiner Benachrichtigungen kannst Du zu verschiedenen Zeiten auch eine Kombination der beiden Ansätze wählen.
Ein Workflow-Beispiel zum Finden und Beantworten der wichtigsten Benachrichtigungen findest Du unter „[Deine Benachrichtigungen mit höchster Priorität prüfen](#checking-your-highest-notification-priorities)."
Ein Workflow-Beispiel zum Entfernen von Benachrichtigungen, die einfach zu selektieren und löschen sind, findest Du unter „[Deine am wenigsten wichtigen Benachrichtigungen löschen](#clearing-your-least-important-notifications)."
## Deine Benachrichtigungen mit höchster Priorität prüfen
Entscheide, welche Art von Benachrichtigungen am dringendsten überprüft werden müssen und wähle einen Zeitpunkt für den Review, der für Dich am besten ist. Du solltest Dir überlegen „Wen blockiere ich?"
Du kannst Dich beispielsweise dazu entscheiden, Deine Benachrichtigungen am Morgen während Deiner Tages-Planungszeit in folgender Reihenfolge zu prüfen:
- Pull Requests, bei denen Dein Review angefordert ist. (gefiltert nach `reason:review-requested` (Grund: Review angefordert))
- Ereignisse, in denen Deine Benutzername @erwähnt ist, auch direkte Erwähnungen genannt. (gefiltert nach `reason:mention` (Grund: erwähnt))
- Ereignisse, in denen ein Team @erwähnt ist, in dem Du Mitglied bist, auch Team-Erwähnungen genannt. (gefiltert nach `reason:team-mention` (Grund: Team-Erwähnung))
- CI-Workflow-Fehler für ein bestimmtest Repository. (filtere nach `reason:ci-activity` (Grund: CI-Aktivität) und `repo:owner/repo-name` (Grund: Inhaber/Repository-Name) und stelle sicher, dass Du CI-Aktivitätsbenachrichtigungen für Workflow-Fehler in Deinen Benachrichtigungseinstellungen aktiviert hast)
{% tip %}
**Tipp:** Um Deine höchsten Prioritäten schnell zu überprüfen, richte benutzerdefinierte Filter in der Reihenfolge ihrer Überprüfungspriorität ein. Weitere Informationen findest Du unter „[Benachrichtigungen über Deinen Posteingang verwalten](/github/managing-subscriptions-and-notifications-on-github/managing-notifications-from-your-inbox#customizing-your-inbox-with-custom-filters)."
{% endtip %}
## Nachverfolgung laufender Benachrichtigungsaktualisierungen
Um Benachrichtigungen nachzuverfolgen, überlege Dir auch „Über was wurde ich blockiert und bin es nicht mehr?" Wähle dann Die Prioritäten der Nachverfolgung Deiner Benachrichtigungen.
Beispielsweise kannst Du folgende Reihenfolge für die Nachverfolgung wählen:
- Issues und Pull Requests, denen Du zugeordnet bist. Schließe sofort alle möglichen Issues und Pull Requests und füge Aktualisierungen hinzu. Bei Bedarf sicherer Benachrichtigungen für eine spätere Überprüfung.
- Überprüfe Benachrichtigungen, die Du in Deinem Posteingang gesichert hast, vor allem ungelesene Aktualisierungen. Wenn der Thread nicht mehr relevant ist, deaktiviere {% octicon "bookmark" aria-label="The bookmark icon" %} um die Benachrichtigung aus Deinem Posteingang gesicherter Benachrichtigungen zu entfernen.
## Benachrichtigungen mit niedriger Priorität verwalten
Nach der Prüfung der Benachrichtigungen mit höherer Priorität überprüfe nun die verbleibenden Benachrichtigungen, wie beispielsweise Teilnahmebenachrichtigungen. Betrachte dazu diese Fragen:
- Kann ich diese Benachrichtigung abmelden? Ist diese Benachrichtigung abgeschlossen und kann als **Done** (Erledigt) markiert werden?
{% tip %}
**Tipp:** Wenn Du Dich von einer Benachrichtigung abmeldest, erhältst Du keine neuen Updates, es sei denn, Du beginnst am Thread teilzunehmen oder Du wirst @erwähnt oder ein Team, dem Du angehörst wird @erwähnt. Wenn Du einen Benachrichtigung als **Done**(Erledigt) markierst, wird die Benachrichtigung aus der Hauptansicht Deines Posteingangs entfernt und kann mit der Abfrage `is:read` (ist gelesen) gefunden werden. Weitere Informationen findest du unter „[Benachrichtigungen über Deinen Posteingang verwalten](/github/managing-subscriptions-and-notifications-on-github/managing-notifications-from-your-inbox#triaging-options)."
{% endtip %}
- Möchtest Du zukünftige Aktualisierungen erhalten, wenn dieser Issue oder Pull Request geschlossen oder wieder geöffnet wird oder wenn ein Pull Request zusammengeführt wird? Weitere Informationen zu diesen Möglichkeiten findest Du unter „[Eine einzelne Benachrichtigung selektieren](/github/managing-subscriptions-and-notifications-on-github/triaging-a-single-notification#customizing-when-to-receive-future-updates-for-an-issue-or-pull-request)."
- Möchtest Du in Zukunft keine solchen Benachrichtigungen mehr erhalten? Falls ja, erwäge Dich abzumelden. Weitere Informationen findest Du unter „[Abonnements für Aktivitäten auf GitHub verwalten](/github/managing-subscriptions-and-notifications-on-github/managing-subscriptions-for-activity-on-github)."
## Deine am wenigsten wichtigen Benachrichtigungen löschen
Wähle aus, welche Art von Benachrichtigungen für Dich am schnellsten und am einfachsten zu selektieren und aus Deinem Posteingang zu entfernen sind, wobei Du idealerweise mehrere Benachrichtigungen gleichzeitig selektieren kannst.
For example, you may decide to clear notifications in this order:
- Teilnahmebenachrichtigungen, von denen Du Dich abmelden kannst.
- Aktualisierungen von Repositorys, die nicht relevant sind um aufbewahrt oder nachverfolgt zu werden.
Weitere Informationen zum gleichzeitigen Verwalten von mehreren Benachrichtigungen in Deinem Posteingang findest Du unter „[ Benachrichtigungen über Deinen Posteingang verwalten](/github/managing-subscriptions-and-notifications-on-github/managing-notifications-from-your-inbox#triaging-multiple-notifications-at-the-same-time)."
Du kannst auch erwägen, Deine Benachrichtigungseinstellungen zu ändern oder Dich wenn möglich von diesen Aktualisierungen abzumelden. Weitere Informationen findest Du unter „[Benachrichtigungen konfigurieren](/github/managing-subscriptions-and-notifications-on-github/configuring-notifications)" oder „[Abonnements für Aktivitäten auf GitHub verwalten](/github/managing-subscriptions-and-notifications-on-github/managing-subscriptions-for-activity-on-github)."

View File

@@ -1,21 +0,0 @@
---
title: Benachrichtigungen anschauen und selektieren
intro: 'Um Deinen Workflow für Benachrichtigungen zu optimieren, kannst Du anpassen, wie Du Benachrichtigungen ansehen und selektieren willst.'
redirect_from:
- /articles/managing-notifications/
- /articles/managing-your-notifications
- /github/managing-subscriptions-and-notifications-on-github/viewing-and-triaging-notifications
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Notifications
children:
- /managing-notifications-from-your-inbox
- /triaging-a-single-notification
- /customizing-a-workflow-for-triaging-your-notifications
shortTitle: Customize a workflow
---

View File

@@ -1,189 +0,0 @@
---
title: Benachrichtigungen über Deinen Posteingang verwalten
intro: 'Use your inbox to quickly triage and sync your notifications across email{% ifversion fpt or ghes or ghec %} and mobile{% endif %}.'
redirect_from:
- /articles/marking-notifications-as-read
- /articles/saving-notifications-for-later
- /github/managing-subscriptions-and-notifications-on-github/managing-notifications-from-your-inbox
- /github/managing-subscriptions-and-notifications-on-github/viewing-and-triaging-notifications/managing-notifications-from-your-inbox
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Notifications
shortTitle: Manage from your inbox
---
{% ifversion ghes %}
{% data reusables.mobile.ghes-release-phase %}
{% endif %}
## Über Deinen Posteingang
{% ifversion fpt or ghes or ghec %}
{% data reusables.notifications-v2.notifications-inbox-required-setting %} Weitere Informationen findest Du unter „[Benachrichtigungen konfigurieren](/github/managing-subscriptions-and-notifications-on-github/configuring-notifications#choosing-your-notification-settings).“
{% endif %}
Um auf Deinen Posteingang für Benachrichtigungen zuzugreifen, klicke in der rechten oberen Ecke einer beliebigen Seite auf {% octicon "bell" aria-label="The notifications bell" %}.
![Benachrichtigung, die auf eine ungelesene Mitteilung hinweist](/assets/images/help/notifications/notifications_general_existence_indicator.png)
Dein Posteingang zeigt alle Benachrichtigungen, die Du nicht abgemeldet oder als **Done** (Erledigt) markiert hast. Du kannst Deinen Posteingang so anpassen, dass er Deinem Workflow am besten entspricht, indem Du Filter verwendest, alle oder nur ungelesene Benachrichtigungen anzeigst und Deine Benachrichtigungen gruppierst, um eine schnelle Übersicht zu erhalten.
![Posteingangsansicht](/assets/images/help/notifications-v2/inbox-view.png)
Standardmäßig werden in Deinem Posteingang gelesene und ungelesene Benachrichtigungen angezeigt. Um nur ungelesene Benachrichtigungen zu sehen, klicke auf **Unread** (Ungelesen) oder verwende die Abfrage `is:unread` (ist ungelesen).
![Posteingangsansicht ungelesene Benachrichtigungen](/assets/images/help/notifications-v2/unread-inbox-view.png)
## Selektionsoptionen
Du hast mehrere Optionen, um Benachrichtigungen in Deinem Posteingang zu selektieren.
| Selektionsoptionen | Beschreibung |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Save (Gesichert) | Sichert Deine Benachrichtigung für spätere Überprüfung. Um eine Benachrichtigung zu sichern, klicke rechts neben der Benachrichtigung auf {% octicon "bookmark" aria-label="The bookmark icon" %}. <br> <br> Gesicherte Benachrichtigungen werden unbegrenzt gespeichert und können durch klicken auf **Saved** (Gesichert) in der Seitenleiste angezeigt werden oder mit der Abfrage `is:saved` (ist gesichert). Wenn Deine gesicherte Benachrichtigung älter als 5 Monate ist und Du sie nicht mehr sicherst, wird die Benachrichtigung innerhalb eines Tages aus Deinem Posteingang entfernt. |
| Done (Erledigt) | Markiert eine Benachrichtigung als erledigt und entfernt die Benachrichtigung aus Deinem Posteingang. Du kannst alle abgeschlossenen Benachrichtigungen sehen, indem Du in der Seitenleiste auf **Done** (erledigt) klickst oder die Abfrage `is:done` (ist erledigt) verwendest. Benachrichtigungen mit Markierung **Done** (erledigt) werden für 5 Monate gespeichert. |
| Kündigen | Löscht automatisch die Benachrichtigung aus Deinem Posteingang und meldet Dich von der Unterhaltung ab, bis Du @erwähnt wirst, ein Team, dem Du angehörst, wird @erwähnt, oder Du wirst zur Überprüfung angefordert. |
| Read (Gelesen) | Markiert eine Benachrichtigung als gelesen. Um nur gelesene Benachrichtigungen in Deinem Posteingang anzuzeigen, verwende die Abfrage `is:read` (ist gelesen). Diese Abfrage enthält keine Benachrichtigungen mit Markierung **Done** (erledigt). |
| Unread (Ungelesen) | Markiert Benachrichtigungen als ungelesen. Um nur ungelesene Benachrichtigungen in Deinem Posteingang anzuzeigen, verwende die Abfrage `is:unread` (ist ungelesen). |
Um die verfügbaren Tastaturkürzel zu sehen, lies bitte „[Tastaturkürzel](/github/getting-started-with-github/keyboard-shortcuts#notifications)."
Bevor Du eine Selektionsoption wählst, kannst Du die Details Deiner Benachrichtigung zuerst anzeigen und untersuchen. Weitere Informationen findest Du unter „[Eine einzelne Benachrichtigung auswählen](/github/managing-subscriptions-and-notifications-on-github/triaging-a-single-notification)."
## Mehrere Benachrichtigungen gleichzeitig selektieren
Um mehrere Benachrichtigungen gleichzeitig zu selektieren, wähle die entsprechenden Benachrichtigungen aus und verwende das {% octicon "kebab-horizontal" aria-label="The edit icon" %}-Dropdownmenü, um eine Selektionsoption auszuwählen.
![Dropdownmenü mit Selektionsoptionen und ausgewählten Benachrichtigungen](/assets/images/help/notifications-v2/triage-multiple-notifications-together.png)
## Standard-Benachrichtigungsfilter
Standardmäßig hat Dein Posteingang Filter für Fälle, wenn Du zugewiesen bist, an einem Thread teilnimmst, für einen Pull-Request-Review angefordert bist, wenn Deine Benutzername direkt @erwähnt wird oder wenn ein Team, in dem Du Mitglied bist, @erwähnt wird.
![Standardmäßige benutzerdefinierte Filter](/assets/images/help/notifications-v2/default-filters.png)
## Deinen Posteingang mit benutzerdefinierten Filtern anpassen
Du kannst bis zu 15 eigene, benutzerdefinierte Filter hinzufügen.
{% data reusables.notifications.access_notifications %}
2. Um die Filtereinstellungen zu öffnen, klicke in der linken Seitenleiste neben „Filters" (Filter) auf {% octicon "gear" aria-label="The Gear icon" %}.
{% tip %}
**Tipp:** Du kannst schnell eine Vorschau des Resultats Deines Posteingang-Filters erstellen, indem Du eine Abfrage in der Ansicht Deines Posteingangs erstellst und **Save** klickst, was die Einstellungen für benutzerdefinierte Filter öffnet.
{% endtip %}
3. Füge Deinem Filter einen Namen und eine Filterabfrage hinzu. Um beispielsweise nur Benachrichtigungen für ein bestimmtes Repository zu sehen, kannst du einen Filter mit der Abfrage `repo:octocat/open-source-project-name reason:participating` erstellen. Du kannst auch Emojis mit einer lokalen Emoji-Tastatur hinzufügen. Eine Liste der unterstützten Suchanfragen findest Du unter "[Unterstützte Suchanfragen für benutzerdefinierte Filter](#supported-queries-for-custom-filters)."
![Beispiel für benutzerdefinierte Filter](/assets/images/help/notifications-v2/custom-filter-example.png)
4. Klicke auf **Create** (Erstellen).
## Beschränkungen für benutzerdefinierte Filter
Benutzerdefinierte Filter unterstützen im Moment nicht:
- Volltextsuche in Deinem Posteingang, einschließlich die Suche nach Pull-Request- oder Issue-Titeln.
- Die Unterscheidung zwischen `is:issue`-, `is:pr`-, und `is:pull-request`-Abfragefiltern. Diese Abfragen werden sowohl Issues wie Pull Request zurückgeben.
- Das Erstellen von mehr als 15 benutzerdefinierten Filtern.
- Das Ändern der Standardfilter oder deren Reihenfolge.
- Search [exclusion](/github/searching-for-information-on-github/understanding-the-search-syntax#exclude-certain-results) using `NOT` or `-QUALIFIER`.
## Unterstützte Abfragen für benutzerdefinierte Filter
These are the types of filters that you can use:
- Nach Repository filtern mit `Repo:`
- Nach Diskussionstyp filtern mit `is:`
- Filter by notification reason with `reason:`{% ifversion fpt or ghec %}
- Filter by notification author with `author:`
- Filter by organization with `org:`{% endif %}
### Supported `repo:` queries
To add a `repo:` filter, you must include the owner of the repository in the query: `repo:owner/repository`. An owner is the organization or the user who owns the {% data variables.product.prodname_dotcom %} asset that triggers the notification. For example, `repo:octo-org/octo-repo` will show notifications triggered in the octo-repo repository within the octo-org organization.
### Unterstützte `is:`-Abfragen
Um Benachrichtigungen nach bestimmten Aktivitäten auf {% data variables.product.product_location %} zu filtern, kannst du die Abfrage `is` verwenden. For example, to only see repository invitation updates, use `is:repository-invitation`{% ifversion not ghae %}, and to only see {% ifversion fpt or ghes or ghec %}{% data variables.product.prodname_dependabot %}{% else %} security{% endif %} alerts, use `is:repository-vulnerability-alert`.{% endif %}
- `is:check-suite`
- `is:commit`
- `is:gist`
- `is:issue-or-pull-request`
- `is:release`
- `is:repository-invitation`{% ifversion fpt or ghes or ghae-issue-4864 or ghec %}
- `is:repository-vulnerability-alert`{% endif %}{% ifversion fpt or ghec %}
- `is:repository-advisory`{% endif %}
- `is:team-discussion`{% ifversion fpt or ghec %}
- `is:discussion`{% endif %}
{% ifversion fpt or ghes or ghae-issue-4864 or ghec %}
For information about reducing noise from notifications for {% data variables.product.prodname_dependabot_alerts %}, see "[Configuring notifications for vulnerable dependencies](/github/managing-security-vulnerabilities/configuring-notifications-for-vulnerable-dependencies)."
{% endif %}
Du kannst die Abfrage `is:` auch verwenden, um zu beschreiben, wie die Benachrichtigung selektiert wurde.
- `is:saved`
- `is:done`
- `is:unread`
- `is:read`
### Unterstützte `reason:`-Abfragen
Um Benachrichtigungen nach dem Grund zu filtern, weshalb Du eine Aktualisierung erhalten hast, kannst Du die Abfrage `reason:` (Grund) verwenden. Um beispielsweise Benachrichtigungen zu sehen, in denen Du (oder ein Team, dem Du angehörst) zu einem Pull-Request-Review aufgefordert bist, benutze die Abfrage `reason:review-requested`. Weitere Informationen findest Du unter „[Informationen zu Benachrichtigungen](/github/managing-subscriptions-and-notifications-on-github/about-notifications#reasons-for-receiving-notifications).“
| Abfrage | Beschreibung |
| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| `reason:assign` | Wenn es eine Aktualisierung zu einem Issue oder Pull Request gibt, denen Du zugewiesen bist. |
| `reason:author` | Wenn es eine Aktualisierung oder einen neuen Kommentar zu einem Pull Request oder Issue gibt, die Du eröffnet hast. |
| `reason:comment` | Wenn Du einen Issue, einen Pull Request oder eine Teamdiskussion kommentiert hast. |
| `reason:participating` | Wenn Du einen Issue, einen Pull Request oder eine Teamdiskussion kommentiert hast, oder wenn Du @erwähnt wurdest. |
| `reason:invitation` | Wenn Du in ein Team, eine Organisation oder ein Repository eingeladen wirst. |
| `reason:manual` | Wenn Du auf einem Issue oder Pull Request **Subscribe** (Abonnieren) klickst, die Du noch nicht abonniert hattest. |
| `reason:mention` | Du wurdest direkt @erwähnt. |
| `reason:review-requested` | You or a team you're on have been requested to review a pull request.{% ifversion fpt or ghes or ghae-issue-4864 or ghec %}
| `reason:security-alert` | When a security alert is issued for a repository.{% endif %}
| `reason:state-change` | Wenn der Status eines Pull Request oder Issue geändert wird. Beispielsweise wird ein Issue geschlossen oder ein Pull Request zusammengeführt. |
| `reason:team-mention` | Wenn ein Team, dem Du angehörst, @erwähnt wird. |
| `reason:ci-activity` | Wenn ein Repository CI-Aktualisierungen hat, wie beispielsweise einen neuen Status für eine Workflow-Ausführung. |
{% ifversion fpt or ghec %}
### Supported `author:` queries
To filter notifications by user, you can use the `author:` query. An author is the original author of the thread (issue, pull request, gist, discussions, and so on) for which you are being notified. For example, to see notifications for threads created by the Octocat user, use `author:octocat`.
### Supported `org:` queries
To filter notifications by organization, you can use the `org` query. The organization you need to specify in the query is the organization of the repository for which you are being notified on {% data variables.product.prodname_dotcom %}. This query is useful if you belong to several organizations, and want to see notifications for a specific organization.
For example, to see notifications from the octo-org organization, use `org:octo-org`.
{% endif %}
{% ifversion fpt or ghes or ghae-issue-4864 or ghec %}
## {% data variables.product.prodname_dependabot %} custom filters
{% ifversion fpt or ghec %}
If you use {% data variables.product.prodname_dependabot %} to keep your dependencies up-to-date, you can use and save these custom filters:
- `is:repository_vulnerability_alert` to show notifications for {% data variables.product.prodname_dependabot_alerts %}.
- `reason:security_alert` to show notifications for {% data variables.product.prodname_dependabot_alerts %} and security update pull requests.
- `author:app/dependabot` to show notifications generated by {% data variables.product.prodname_dependabot %}. This includes {% data variables.product.prodname_dependabot_alerts %}, security update pull requests, and version update pull requests.
For more information about {% data variables.product.prodname_dependabot %}, see "[About managing vulnerable dependencies](/github/managing-security-vulnerabilities/about-managing-vulnerable-dependencies)."
{% endif %}
{% ifversion ghes or ghae-issue-4864 %}
If you use {% data variables.product.prodname_dependabot %} to keep your dependencies-up-to-date, you can use and save these custom filters to show notifications for {% data variables.product.prodname_dependabot_alerts %}:
- `is:repository_vulnerability_alert`
- `reason:security_alert`
For more information about {% data variables.product.prodname_dependabot %}, see "[About alerts for vulnerable dependencies](/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies)."
{% endif %}
{% endif %}

View File

@@ -1,48 +0,0 @@
---
title: Eine einzige Benachrichtigung selektieren
intro: 'Wenn du eine einzelne Benachrichtigung überprüfen und untersuchen willst, hast Du verschiedene Auswahlmöglichkeiten, die für die detaillierte Benachrichtigungs-Ansicht optimiert sind.'
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Notifications
redirect_from:
- /github/managing-subscriptions-and-notifications-on-github/triaging-a-single-notification
- /github/managing-subscriptions-and-notifications-on-github/viewing-and-triaging-notifications/triaging-a-single-notification
shortTitle: Triage a notification
---
## Sichern einer einzelnen Benachrichtigung
Um eine einzelne Benachrichtigung zu für einen späteren Review zu sichern, klicke rechts neben der Benachrichtigung auf {% octicon "bookmark" aria-label="The bookmark icon" %}. Du kannst nur eine Benachrichtigung nach der Anderen sichern.
Gesicherte Benachrichtigungen werden unbegrenzt gespeichert und können durch klicken auf **Saved** (Gesichert) in der Seitenleiste angezeigt werden oder mit der Abfrage `is:saved` (ist gesichert). Wenn Deine gesicherte Benachrichtigung älter als 5 Monate ist und Du sie nicht mehr sicherst, wird die Benachrichtigung innerhalb eines Tages aus Deinem Posteingang entfernt.
![Selektions-Option speichern](/assets/images/help/notifications-v2/save-triaging-option.png)
## Eine Benachrichtigung untersuchen
Wenn Du eine individuelle Benachrichtigung aus Deinem Posteingang anklickst, wirst Du an die Unterhaltung weitergeleitet, die die Benachrichtigung ausgelöst hat. Oben auf der Seite kannst Du:
- Die einzelne Benachrichtigung als erledigt markieren
- Künftige Benachrichtigungen abmelden
- Die Benachrichtigung als gelesen markieren
- Die Benachrichtigung für später sichern
- Zu Deinem Postfach für Benachrichtigungen zurück gehen
Weitere Informationen über Selektionsoptionen findest Du unter „[Benachrichtigungen aus Deinem Postfach verwalten](/github/managing-subscriptions-and-notifications-on-github/managing-notifications-from-your-inbox#triaging-options)."
## Anpassen, wann künftige Aktualisierungen für einen Issue oder Pull Request erhalten werden sollen
Du kannst wählen, wie Du zukünftige Benachrichtigungen für einen spezifischen Issue oder einen Pull Request erhalten willst.
1. In der rechten Spalte des Issue oder Pull Requests, klicke neben „Notifications" (Benachrichtigungen) auf **Customize** (Anpassen).
![Anpassungs-Option under "Notifications" (Benachrichtigungen)](/assets/images/help/notifications-v2/customize-notifications-for-specific-thread.png)
2. Wähle **Custom** (Benutzerdefiniert) und entscheide, wann du Aktualisierungen für Benachrichtigungen dieses Thread erhalten willst. Du kannst zum Beispiel wählen, ob Du eine Aktualisierung erhältst, wenn der Pull Request zusammengeführt, geschlossen oder wieder geöffnet wurde. Du wirst wieder abonniert, wenn Du am Thread teilnimmst, Dein Benutzername oder ein Team, in dem Du Mitglied bist, @erwähnt wird.
![Optionen zum Anpassen von Benachrichtigungen](/assets/images/help/notifications-v2/custom-options-for-customizing-notification-thread-updates.png)
3. Klicke auf **Save** (Speichern).

View File

@@ -1,31 +0,0 @@
---
title: Informationen zum Profil Deiner Organisation
intro: Auf der Profilseite Deiner Organisation werden grundlegende Informationen zu Deiner Organisation angezeigt.
redirect_from:
- /articles/about-your-organization-s-profile
- /articles/about-your-organizations-profile
- /github/setting-up-and-managing-your-github-profile/about-your-organizations-profile
- /github/setting-up-and-managing-your-github-profile/customizing-your-profile/about-your-organizations-profile
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Profiles
shortTitle: Organization's profile
---
You can optionally choose to add a description, location, website, and email address for your organization, and pin important repositories.{% ifversion not ghes and not ghae %} You can customize your organization's profile by adding a README.md file. For more information, see "[Customizing your organization's profile](/organizations/collaborating-with-groups-in-organizations/customizing-your-organizations-profile)."{% endif %}
{% ifversion fpt or ghec %}Um die Identität Ihrer Organisation zu bestätigen und einen „Verifiziert“-Badge auf der Profilseite Ihrer Organisation anzuzeigen, müssen Sie die Domains Ihrer Organisation mit {% data variables.product.product_name %} verifizieren. For more information, see "[Verifying or approving a domain for your organization](/organizations/managing-organization-settings/verifying-or-approving-a-domain-for-your-organization)."{% endif %}
{% ifversion fpt or ghes > 3.2 or ghec %}
![Beispiel einer Profilseite einer Organisation](/assets/images/help/organizations/org_profile_with_overview.png)
{% else %}
![Beispiel einer Profilseite einer Organisation](/assets/images/help/profile/org_profile.png)
{% endif %}
## Weiterführende Informationen
- „[Informationen zu Organisationen](/organizations/collaborating-with-groups-in-organizations/about-organizations)“

View File

@@ -1,44 +0,0 @@
---
title: Informationen zu Deinem Profil
intro: 'Deine Profilseite erzählt anderen die Geschichte Deiner Arbeit anhand der Repositorys, an denen Du interessiert bist, der Beiträge, die Du geleistet hast, und der Unterhaltungen, die Du geführt hast.'
redirect_from:
- /articles/viewing-your-feeds/
- /articles/profile-pages/
- /articles/about-your-profile
- /github/setting-up-and-managing-your-github-profile/about-your-profile
- /github/setting-up-and-managing-your-github-profile/customizing-your-profile/about-your-profile
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Profiles
---
Du kannst persönliche Informationen über Dich selbst in Deiner Bio hinzufügen, beispielsweise über frühere Orte, an denen Du gearbeitet hast, Projekte, an denen Du mitgewirkt hast, oder Interessen, die Du hast, von denen andere Personen möglicherweise wissen möchten. Weitere Informationen findest Du unter „[Bio zu Deinem Profil hinzufügen](/articles/personalizing-your-profile/#adding-a-bio-to-your-profile).“
{% ifversion fpt or ghes or ghec %}
{% data reusables.profile.profile-readme %}
![Profile README file displayed on profile](/assets/images/help/repository/profile-with-readme.png)
{% endif %}
Personen, die Dein Profil aufrufen, sehen eine Zeitleiste Deiner Beitragsaktivitäten, wie Issues und Pull Requests, die Du geöffnet hast, Commits, die Du durchgeführt hast, und Pull Requests, deren Review Du durchgeführt hast. Du kannst wählen, ob Du nur öffentliche Beiträge anzeigen oder auch private, anonymisierte Beiträge einbeziehen möchtest. Weitere Informationen findest Du unter „[Beiträge auf Deiner Profilseite anzeigen](/articles/viewing-contributions-on-your-profile-page)“ oder „[Private Beiträge in Deinem Profil veröffentlichen oder verbergen](/articles/publicizing-or-hiding-your-private-contributions-on-your-profile).“
People who visit your profile can also see the following information.
- Repositories and gists you own or contribute to. {% ifversion fpt or ghes or ghec %}You can showcase your best work by pinning repositories and gists to your profile. For more information, see "[Pinning items to your profile](/github/setting-up-and-managing-your-github-profile/pinning-items-to-your-profile)."{% endif %}
- Repositorys, die Sie mit einem Stern versehen haben. For more information, see "[Saving repositories with stars](/articles/saving-repositories-with-stars/)."
- Eine Übersicht über Deine Aktivitäten in den Organisationen, Repositorys und Teams, in denen Du am meisten aktiv bist. Weitere Informationen findest Du unter „[Übersicht über Deine Aktivitäten in Deinem Profil anzeigen](/articles/showing-an-overview-of-your-activity-on-your-profile)“.{% ifversion fpt or ghec %}
- Badges that show if you use {% data variables.product.prodname_pro %} or participate in programs like the {% data variables.product.prodname_arctic_vault %}, {% data variables.product.prodname_sponsors %}, or the {% data variables.product.company_short %} Developer Program. Weitere Informationen findest Du unter „[Dein Profil personalisieren](/github/setting-up-and-managing-your-github-profile/personalizing-your-profile#displaying-badges-on-your-profile)“.{% endif %}
Sie können auch einen Status auf Ihrem Profil einstellen, um Angaben zu Ihrer Verfügbarkeit zu machen. Weitere Informationen findest Du unter „[Status festlegen](/articles/personalizing-your-profile/#setting-a-status).“
## Weiterführende Informationen
- „[Wie lege ich mein Profilbild fest?](/articles/how-do-i-set-up-my-profile-picture)“
- „[Private Beiträge in Deinem Profil veröffentlichen oder verbergen](/articles/publicizing-or-hiding-your-private-contributions-on-your-profile)“
- „"[Beiträge auf Deinem Profil anzeigen](/articles/viewing-contributions-on-your-profile)“

View File

@@ -1,21 +0,0 @@
---
title: Dein Profil anpassen
intro: 'Du kannst Dein Profil anpassen, damit andere Benutzer sich ein besseres Bild von Deiner Person und Deiner Arbeit machen können.'
redirect_from:
- /articles/customizing-your-profile
- /github/setting-up-and-managing-your-github-profile/customizing-your-profile
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Profiles
children:
- /about-your-profile
- /about-your-organizations-profile
- /personalizing-your-profile
- /managing-your-profile-readme
- /pinning-items-to-your-profile
---

View File

@@ -1,73 +0,0 @@
---
title: Managing your profile README
intro: 'You can add a README to your {% data variables.product.prodname_dotcom %} profile to tell other people about yourself.'
versions:
fpt: '*'
ghes: '*'
ghec: '*'
topics:
- Profiles
redirect_from:
- /github/setting-up-and-managing-your-github-profile/managing-your-profile-readme
- /github/setting-up-and-managing-your-github-profile/customizing-your-profile/managing-your-profile-readme
shortTitle: Your profile README
---
## About your profile README
You can share information about yourself with the community on {% data variables.product.product_location %} by creating a profile README. {% data variables.product.prodname_dotcom %} shows your profile README at the top of your profile page.
You decide what information to include in your profile README, so you have full control over how you present yourself on {% data variables.product.prodname_dotcom %}. Here are some examples of information that visitors may find interesting, fun, or useful in your profile README.
- An "About me" section that describes your work and interests
- Contributions you're proud of, and context about those contributions
- Guidance for getting help in communities where you're involved
![Profile README file displayed on profile](/assets/images/help/repository/profile-with-readme.png)
You can format text and include emoji, images, and GIFs in your profile README by using {% data variables.product.company_short %} Flavored Markdown. Weitere Informationen findest Du unter „[Erste Schritte zum Schreiben und Formatieren auf {% data variables.product.prodname_dotcom %}](/github/writing-on-github/getting-started-with-writing-and-formatting-on-github)“.
## Vorrausetzungen
GitHub will display your profile README on your profile page if all of the following are true.
- You've created a repository with a name that matches your {% data variables.product.prodname_dotcom %} username.
- The repository is public.
- The repository contains a file named README.md in its root.
- The README.md file contains any content.
{% note %}
**Note**: If you created a public repository with the same name as your username before July 2020, {% data variables.product.prodname_dotcom %} won't automatically show the repository's README on your profile. You can manually share the repository's README to your profile by going to the repository on {% data variables.product.prodname_dotcom_the_website %} and clicking **Share to profile**.
![Button to share README to profile](/assets/images/help/repository/share-to-profile.png)
{% endnote %}
## Adding a profile README
{% data reusables.repositories.create_new %}
2. Under "Repository name", type a repository name that matches your {% data variables.product.prodname_dotcom %} username. For example, if your username is "octocat", the repository name must be "octocat". ![Repository name field which matches username](/assets/images/help/repository/repo-username-match.png)
3. Optional kannst Du auch eine Beschreibung des Repositorys hinzufügen. For example, "My personal repository." ![Feld zum Eingeben einer Repository-Beschreibung](/assets/images/help/repository/create-personal-repository-desc.png)
4. Select **Public**. ![Radio button to select visibility with public selected](/assets/images/help/repository/create-personal-repository-visibility.png)
{% data reusables.repositories.initialize-with-readme %}
{% data reusables.repositories.create-repo %}
7. Above the right sidebar, click **Edit README**. ![Button to edit README file](/assets/images/help/repository/personal-repository-edit-readme.png)
The generated README file is pre-populated with a template to give you some inspiration for your profile README. ![README file with pre-populated template](/assets/images/help/repository/personal-repository-readme-template.png)
For a summary of all the available emojis and their codes, see "[Emoji cheat sheet](http://www.emoji-cheat-sheet.com/)."
## Removing a profile README
The profile README is removed from your {% data variables.product.prodname_dotcom %} profile if any of the following apply:
- The README file is empty or doesn't exist.
- The repository is private.
- The repository name no longer matches your username.
The method you choose is dependant upon your needs, but if you're unsure, we recommend making your repository private. For steps on how to make your repository private, see ["Changing a repository's visibility."](/github/administering-a-repository/setting-repository-visibility#changing-a-repositorys-visibility)
## Weiterführende Informationen
- [Informationen zu README-Dateien](/github/creating-cloning-and-archiving-repositories/about-readmes)

View File

@@ -1,216 +0,0 @@
---
title: Dein Profil personalisieren
intro: 'Sie können Informationen zu Ihrer Person für andere {% data variables.product.product_name %}-Benutzer bereitstellen, indem Sie ein Profilbild einrichten und eine Biografie zum Profil hinzufügen.'
redirect_from:
- /articles/adding-a-bio-to-your-profile/
- /articles/setting-your-profile-picture/
- /articles/how-do-i-set-up-my-profile-picture/
- /articles/gravatar-problems/
- /articles/how-do-i-set-up-my-avatar/
- /articles/personalizing-your-profile
- /github/setting-up-and-managing-your-github-profile/personalizing-your-profile
- /github/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Profiles
shortTitle: Personalize
---
## Dein Profilbild ändern
Mit Ihrem Profilbild können Sie überall auf {% data variables.product.product_name %} in Pull Requests, Kommentaren, Beiträge-Seiten und Diagrammen leichter identifiziert werden.
Wenn Sie ein Konto anlegen, stellt {% data variables.product.product_name %} Ihnen ein zufällig generiertes „Identicon“ bereit. [Dein Identicon](https://github.com/blog/1586-identicons) wird aus einem Hash Deiner Benutzer-ID erzeugt. Seine Farbe und sein Muster lassen sich daher nicht steuern. Du kannst das Identicon durch ein Bild ersetzen, das Dich repräsentiert.
{% tip %}
**Tipp:** Dein Profilbild sollte eine PNG-, JPG- oder GIF-Datei mit weniger als 1 MB sein. Für eine optimale Darstellung empfehlen wir eine Bildgröße von etwa 500 x 500 Pixeln.
{% endtip %}
### Ein Profilbild einrichten
{% data reusables.user_settings.access_settings %}
2. Klicke unter **Profile Picture** (Profilbild) auf {% octicon "pencil" aria-label="The edit icon" %} **Edit** (Bearbeiten). ![Profilbild bearbeiten](/assets/images/help/profile/edit-profile-photo.png)
3. Klicke auf **Upload a photo...** (Foto hochladen). ![Profilbild aktualisieren](/assets/images/help/profile/edit-profile-picture-options.png)
3. Schneiden Sie das Bild zu. Wenn Du fertig bist, klicke auf **Set new profile picture** (Neues Profilbild festlegen). ![Hochgeladenes Foto zuschneiden](/assets/images/help/profile/avatar_crop_and_save.png)
### Dein Profilbild auf das Identicon zurücksetzen
{% data reusables.user_settings.access_settings %}
2. Klicke unter **Profile Picture** (Profilbild) auf {% octicon "pencil" aria-label="The edit icon" %} **Edit** (Bearbeiten). ![Profilbild bearbeiten](/assets/images/help/profile/edit-profile-photo.png)
3. Um das Identicon wieder zu verwenden, klicke auf **Remove photo** (Foto entfernen). Wenn Deine E-Mail-Adresse mit einem [Gravatar](https://en.gravatar.com/) verknüpft ist, kannst Du das Profilbild nicht auf das Identicon zurücksetzen. Klicke stattdessen auf **Revert to Gravatar** (Auf Gravatar zurücksetzen). ![Profilbild aktualisieren](/assets/images/help/profile/edit-profile-picture-options.png)
## Deinen Profilnamen ändern
Du kannst den Namen, der in Deinem Profil angezeigt wird, ändern. This name may also be displayed next to comments you make on private repositories owned by an organization. Weitere Informationen findest Du unter „[Anzeige der Mitgliedsnamen in Deiner Organisation verwalten](/articles/managing-the-display-of-member-names-in-your-organization)“.
{% ifversion fpt or ghec %}
{% note %}
**Note:** If you're a member of an {% data variables.product.prodname_emu_enterprise %}, any changes to your profile name must be made through your identity provider instead of {% data variables.product.prodname_dotcom_the_website %}. {% data reusables.enterprise-accounts.emu-more-info-account %}
{% endnote %}
{% endif %}
{% data reusables.user_settings.access_settings %}
2. Gib unter „Name“ den Namen ein, der in Deinem Profil angezeigt werden soll. ![Feld „Name“ (Name) in den Profileinstellungen](/assets/images/help/profile/name-field.png)
## Eine Biografie zu Deinem Profil hinzufügen
Fügen Sie eine Biografie zu Ihrem Profil hinzu, um anderen {% data variables.product.product_name %}-Benutzern Informationen zu Ihrer Person bereitzustellen. Mit [@Erwähnungen](/articles/basic-writing-and-formatting-syntax) und Emojis kannst Du Informationen dazu angeben, wo Du gerade arbeitest oder früher gearbeitet hast, welche Tätigkeit Du ausübst oder welche Kaffeesorte Du trinkst.
{% ifversion fpt or ghes or ghec %}
For a longer-form and more prominent way of displaying customized information about yourself, you can also use a profile README. For more information, see "[Managing your profile README](/github/setting-up-and-managing-your-github-profile/managing-your-profile-readme)."
{% endif %}
{% note %}
**Note:** If you have the activity overview section enabled for your profile and you @mention an organization you're a member of in your profile bio, then that organization will be featured first in your activity overview. Weitere Informationen findest Du unter „[Übersicht über Deine Aktivitäten in Deinem Profil anzeigen](/articles/showing-an-overview-of-your-activity-on-your-profile).“
{% endnote %}
{% data reusables.user_settings.access_settings %}
2. Füge unter **Bio** (Biografie) den Inhalt ein, der in Deinem Profil angezeigt werden soll. Das Feld für die Biografie ist auf 160 Zeichen begrenzt. ![Biografie im Profil aktualisieren](/assets/images/help/profile/bio-field.png)
{% tip %}
**Tipp:** Wenn Du eine Organisation @erwähnst, funktioniert die automatische Vervollständigung nur bei Organisationen, bei denen Du Mitglied bist. Du kannst dennoch Organisationen @erwähnen, bei denen Du kein Mitglied sind, z. B. einen ehemaligen Auftraggeber, aber die automatische Vervollständigung funktioniert in diesem Fall nicht.
{% endtip %}
3. Klicke auf **Update profile** (Profil aktualisieren). ![Schaltfläche „Update profile" (Aktualisieren des Profils)](/assets/images/help/profile/update-profile-button.png)
## Einen Status festlegen
Sie können einen Status festlegen, um Informationen zu Ihrer aktuellen Verfügbarkeit auf {% data variables.product.product_name %} anzuzeigen. An folgenden Stellen wird Ihr Status angezeigt:
- auf Deiner {% data variables.product.product_name %}-Profilseite.
- wenn Benutzer auf {% data variables.product.product_name %} mit dem Mauszeiger über Deinen Benutzernamen oder Deinen Avatar fahren.
- auf der Teamseite eines Teams, bei dem Du Mitglied bist. Weitere Informationen findest Du unter „[Informationen zu Teams](/articles/about-teams#nested-teams).“
- auf dem Organisations-Dashboard einer Organisation, bei der Du Mitglied bist. Weitere Informationen findest Du unter „[Informationen zum persönlichen Dashboard](/articles/about-your-personal-dashboard/).“
Wenn Sie Ihren Status festlegen, können Sie andere Benutzer auch darüber informieren, dass Sie auf {% data variables.product.product_name %} nur begrenzt verfügbar sind.
![Neben @erwähntem Benutzernamen wird „busy“ (Beschäftigt) angezeigt](/assets/images/help/profile/username-with-limited-availability-text.png)
![Neben angefordertem Reviewer wird „busy“ (Beschäftigt) angezeigt](/assets/images/help/profile/request-a-review-limited-availability-status.png)
Wenn Sie die Option „Busy“ (Beschäftigt) auswählen, wird ein entsprechender Hinweis neben Ihrem Benutzernamen angezeigt, wenn andere Benutzer Sie @erwähnen, Ihnen einen Issue oder Pull Request zuweisen oder einen Pull-Request-Review von Ihnen anfordern. You will also be excluded from automatic review assignment for pull requests assigned to any teams you belong to. Weitere Informationen findest Du unter „[Code Review-Zuweisung für Dein Team verwalten](/organizations/organizing-members-into-teams/managing-code-review-assignment-for-your-team)."
1. In the top right corner of {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom_the_website %}{% else %}{% data variables.product.product_name %}{% endif %}, click your profile photo, then click **Set your status** or, if you already have a status set, click your current status. ![Schaltfläche im Profil zum Festlegen des Status](/assets/images/help/profile/set-status-on-profile.png)
2. Um benutzerdefinierten Text zu Deinem Status hinzuzufügen, klicke in das Textfeld und gib dort eine Statusmeldung ein. ![Feld zum Eingeben einer Statusmeldung](/assets/images/help/profile/type-a-status-message.png)
3. Um einen Emoji-Status festzulegen, klicke optional auf das Smiley-Symbol und wähle einen Emoji aus der Liste aus. ![Schaltfläche zum Auswählen eines Emoji-Status](/assets/images/help/profile/select-emoji-status.png)
4. Wenn Du angeben möchtest, dass Du nur eingeschränkt verfügbar bist, wähle optional „Busy“ (Beschäftigt) aus. ![In den Optionen zum Bearbeiten des Status ausgewählte Option „busy“ (Beschäftigt)](/assets/images/help/profile/limited-availability-status.png)
5. Wähle im Dropdownmenü **Clear status** (Status löschen) aus, wann Dein Status ablaufen soll. Wenn Du kein Ablaufdatum für den Status auswählst, bleibt Dein Status bestehen, bis Du ihn löschst oder bearbeitest. ![Dropdownmenü zum Auswählen des Ablaufdatums für den Status](/assets/images/help/profile/status-expiration.png)
6. Klicke im Dropdownmenü auf die Organisation, für die Dein Status sichtbar sein soll. Wenn Du keine Organisation auswählst, ist Dein Status öffentlich sichtbar. ![Dropdownmenü zum Auswählen, für wen Dein Status sichtbar sein soll](/assets/images/help/profile/status-visibility.png)
7. Klicke auf **Set status** (Status festlegen). ![Schaltfläche zum Festlegen des Status](/assets/images/help/profile/set-status-button.png)
{% ifversion fpt or ghec %}
## Displaying badges on your profile
When you participate in certain programs, {% data variables.product.prodname_dotcom %} automatically displays a badge on your profile.
| Badge | Program | Beschreibung |
| ------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ![Mars 2020 Helicopter Contributor badge icon](/assets/images/help/profile/badge-mars-2020-small.png) | **Mars 2020 Helicopter Contributor** | If you authored any commit(s) present in the commit history for the relevant tag of an open source library used in the Mars 2020 Helicopter Mission, you'll get a Mars 2020 Helicopter Contributor badge on your profile. Hovering over the badge shows you several of the repositories you contributed to that were used in the mission. For the full list of repositories that will qualify you for the badge, see "[List of qualifying repositories for Mars 2020 Helicopter Contributor badge](/github/setting-up-and-managing-your-github-profile/personalizing-your-profile#list-of-qualifying-repositories-for-mars-2020-helicopter-contributor-badge)." |
| ![Arctic Code Vault Contributor badge icon](/assets/images/help/profile/badge-arctic-code-vault-small.png) | **{% data variables.product.prodname_arctic_vault %} Contributor** | If you authored any commit(s) on the default branch of a repository that was archived in the 2020 Arctic Vault program, you'll get an {% data variables.product.prodname_arctic_vault %} Contributor badge on your profile. Hovering over the badge shows you several of the repositories you contributed to that were part of the program. For more information on the program, see [{% data variables.product.prodname_archive %}](https://archiveprogram.github.com). |
| ![{% data variables.product.prodname_dotcom %} Sponsor badge icon](/assets/images/help/profile/badge-sponsors-small.png) | **{% data variables.product.prodname_dotcom %} Sponsor** | If you sponsored an open source contributor through {% data variables.product.prodname_sponsors %} you'll get a {% data variables.product.prodname_dotcom %} Sponsor badge on your profile. Clicking the badge takes you to the **Sponsoring** tab of your profile. For more information, see "[Sponsoring open source contributors](/github/supporting-the-open-source-community-with-github-sponsors/sponsoring-open-source-contributors)." |
| {% octicon "cpu" aria-label="The Developer Program icon" %} | **Developer Program Member** | If you're a registered member of the {% data variables.product.prodname_dotcom %} Developer Program, building an app with the {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API, you'll get a Developer Program Member badge on your profile. For more information on the {% data variables.product.prodname_dotcom %} Developer Program, see [GitHub Developer](/program/). |
| {% octicon "star-fill" aria-label="The star icon" %} | **Pro** | If you use {% data variables.product.prodname_pro %} you'll get a PRO badge on your profile. Weitere Informationen zu {% data variables.product.prodname_pro %} findest Du unter „[Produkte von {% data variables.product.prodname_dotcom %}](/github/getting-started-with-github/githubs-products#github-pro).“ |
| {% octicon "lock" aria-label="The lock icon" %} | **Security Bug Bounty Hunter** | If you helped out hunting down security vulnerabilities, you'll get a Security Bug Bounty Hunter badge on your profile. For more information about the {% data variables.product.prodname_dotcom %} Security program, see [{% data variables.product.prodname_dotcom %} Security](https://bounty.github.com/). |
| {% octicon "mortar-board" aria-label="The mortar-board icon" %} | **Github Campus Expert** | If you participate in the {% data variables.product.prodname_dotcom %} Campus Program you'll get a {% data variables.product.prodname_dotcom %} Campus Expert badge on your profile. For more information about the Campus Experts program, see [Campus Experts](https://education.github.com/experts). |
## Disabling badges on your profile
You can disable some of the badges for {% data variables.product.prodname_dotcom %} programs you're participating in, including the PRO, {% data variables.product.prodname_arctic_vault %} and Mars 2020 Helicopter Contributor badges.
{% data reusables.user_settings.access_settings %}
2. Under "Profile settings", deselect the badge you want you disable. ![Checkbox to no longer display a badge on your profile](/assets/images/help/profile/profile-badge-settings.png)
3. Klicke auf **Update preferences** (Voreinstellungen aktualisieren).
{% endif %}
## List of qualifying repositories for Mars 2020 Helicopter Contributor badge
If you authored any commit(s) present in the commit history for the listed tag of one or more of the repositories below, you'll receive the Mars 2020 Helicopter Contributor badge on your profile. The authored commit must be with a verified email address, associated with your account at the time {% data variables.product.prodname_dotcom %} determined the eligible contributions, in order to be attributed to you. You can be the original author or [one of the co-authors](/github/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors) of the commit. Future changes to verified emails will not have an effect on the badge. We built the list based on information received from NASA's Jet Propulsion Laboratory.
| {% data variables.product.prodname_dotcom %} Repository | Version | Tag |
| ----------------------------------------------------------------------------- | --------- | ---------------------------------------------------------------------------------------------------------- |
| [torvalds/linux](https://github.com/torvalds/linux) | 3.4 | [v3.4](https://github.com/torvalds/linux/releases/tag/v3.4) |
| [python/cpython](https://github.com/python/cpython) | 3.9.2 | [v3.9.2](https://github.com/python/cpython/releases/tag/v3.9.2) |
| [boto/boto3](https://github.com/boto/boto3) | 1.17.17 | [1.17.17](https://github.com/boto/boto3/releases/tag/1.17.17) |
| [boto/botocore](https://github.com/boto/botocore) | 1.20.11 | [1.20.11](https://github.com/boto/botocore/releases/tag/1.20.11) |
| [certifi/python-certifi](https://github.com/certifi/python-certifi) | 2020.12.5 | [2020.12.05](https://github.com/certifi/python-certifi/releases/tag/2020.12.05) |
| [chardet/chardet](https://github.com/chardet/chardet) | 4.0.0 | [4.0.0](https://github.com/chardet/chardet/releases/tag/4.0.0) |
| [matplotlib/cycler](https://github.com/matplotlib/cycler) | 0.10.0 | [v0.10.0](https://github.com/matplotlib/cycler/releases/tag/v0.10.0) |
| [elastic/elasticsearch-py](https://github.com/elastic/elasticsearch-py) | 6.8.1 | [6.8.1](https://github.com/elastic/elasticsearch-py/releases/tag/6.8.1) |
| [ianare/exif-py](https://github.com/ianare/exif-py) | 2.3.2 | [2.3.2](https://github.com/ianare/exif-py/releases/tag/2.3.2) |
| [kjd/idna](https://github.com/kjd/idna) | 2.10 | [v2.10](https://github.com/kjd/idna/releases/tag/v2.10) |
| [jmespath/jmespath.py](https://github.com/jmespath/jmespath.py) | 0.10.0 | [0.10.0](https://github.com/jmespath/jmespath.py/releases/tag/0.10.0) |
| [nucleic/kiwi](https://github.com/nucleic/kiwi) | 1.3.1 | [1.3.1](https://github.com/nucleic/kiwi/releases/tag/1.3.1) |
| [matplotlib/matplotlib](https://github.com/matplotlib/matplotlib) | 3.3.4 | [v3.3.4](https://github.com/matplotlib/matplotlib/releases/tag/v3.3.4) |
| [numpy/numpy](https://github.com/numpy/numpy) | 1.20.1 | [v1.20.1](https://github.com/numpy/numpy/releases/tag/v1.20.1) |
| [opencv/opencv-python](https://github.com/opencv/opencv-python) | 4.5.1.48 | [48](https://github.com/opencv/opencv-python/releases/tag/48) |
| [python-pillow/Pillow](https://github.com/python-pillow/Pillow) | 8.1.0 | [8.1.0](https://github.com/python-pillow/Pillow/releases/tag/8.1.0) |
| [pycurl/pycurl](https://github.com/pycurl/pycurl) | 7.43.0.6 | [REL_7_43_0_6](https://github.com/pycurl/pycurl/releases/tag/REL_7_43_0_6) |
| [pyparsing/pyparsing](https://github.com/pyparsing/pyparsing) | 2.4.7 | [pyparsing_2.4.7](https://github.com/pyparsing/pyparsing/releases/tag/pyparsing_2.4.7) |
| [pyserial/pyserial](https://github.com/pyserial/pyserial) | 3.5 | [v3.5](https://github.com/pyserial/pyserial/releases/tag/v3.5) |
| [dateutil/dateutil](https://github.com/dateutil/dateutil) | 2.8.1 | [2.8.1](https://github.com/dateutil/dateutil/releases/tag/2.8.1) |
| [yaml/pyyaml ](https://github.com/yaml/pyyaml) | 5.4.1 | [5.4.1](https://github.com/yaml/pyyaml/releases/tag/5.4.1) |
| [psf/requests](https://github.com/psf/requests) | 2.25.1 | [v2.25.1](https://github.com/psf/requests/releases/tag/v2.25.1) |
| [boto/s3transfer](https://github.com/boto/s3transfer) | 0.3.4 | [0.3.4](https://github.com/boto/s3transfer/releases/tag/0.3.4) |
| [enthought/scimath](https://github.com/enthought/scimath) | 4.2.0 | [4.2.0](https://github.com/enthought/scimath/releases/tag/4.2.0) |
| [scipy/scipy](https://github.com/scipy/scipy) | 1.6.1 | [v1.6.1](https://github.com/scipy/scipy/releases/tag/v1.6.1) |
| [benjaminp/six](https://github.com/benjaminp/six) | 1.15.0 | [1.15.0](https://github.com/benjaminp/six/releases/tag/1.15.0) |
| [enthought/traits](https://github.com/enthought/traits) | 6.2.0 | [6.2.0](https://github.com/enthought/traits/releases/tag/6.2.0) |
| [urllib3/urllib3](https://github.com/urllib3/urllib3) | 1.26.3 | [1.26.3](https://github.com/urllib3/urllib3/releases/tag/1.26.3) |
| [python-attrs/attrs](https://github.com/python-attrs/attrs) | 19.3.0 | [19.3.0](https://github.com/python-attrs/attrs/releases/tag/19.3.0) |
| [CheetahTemplate3/cheetah3](https://github.com/CheetahTemplate3/cheetah3/) | 3.2.4 | [3.2.4](https://github.com/CheetahTemplate3/cheetah3/releases/tag/3.2.4) |
| [pallets/click](https://github.com/pallets/click) | 7.0 | [7.0](https://github.com/pallets/click/releases/tag/7.0) |
| [pallets/flask](https://github.com/pallets/flask) | 1.1.1 | [1.1.1](https://github.com/pallets/flask/releases/tag/1.1.1) |
| [flask-restful/flask-restful](https://github.com/flask-restful/flask-restful) | 0.3.7 | [0.3.7](https://github.com/flask-restful/flask-restful/releases/tag/0.3.7) |
| [pytest-dev/iniconfig](https://github.com/pytest-dev/iniconfig) | 1.0.0 | [v1.0.0](https://github.com/pytest-dev/iniconfig/releases/tag/v1.0.0) |
| [pallets/itsdangerous](https://github.com/pallets/itsdangerous) | 1.1.0 | [1.1.0](https://github.com/pallets/itsdangerous/releases/tag/1.1.0) |
| [pallets/jinja](https://github.com/pallets/jinja) | 2.10.3 | [2.10.3](https://github.com/pallets/jinja/releases/tag/2.10.3) |
| [lxml/lxml](https://github.com/lxml/lxml) | 4.4.1 | [lxml-4.4.1](https://github.com/lxml/lxml/releases/tag/lxml-4.4.1) |
| [Python-Markdown/markdown](https://github.com/Python-Markdown/markdown) | 3.1.1 | [3.1.1](https://github.com/Python-Markdown/markdown/releases/tag/3.1.1) |
| [pallets/markupsafe](https://github.com/pallets/markupsafe) | 1.1.1 | [1.1.1](https://github.com/pallets/markupsafe/releases/tag/1.1.1) |
| [pypa/packaging](https://github.com/pypa/packaging) | 19.2 | [19.2](https://github.com/pypa/packaging/releases/tag/19.2) |
| [pexpect/pexpect](https://github.com/pexpect/pexpect) | 4.7.0 | [4.7.0](https://github.com/pexpect/pexpect/releases/tag/4.7.0) |
| [pytest-dev/pluggy](https://github.com/pytest-dev/pluggy) | 0.13.0 | [0.13.0](https://github.com/pytest-dev/pluggy/releases/tag/0.13.0) |
| [pexpect/ptyprocess](https://github.com/pexpect/ptyprocess) | 0.6.0 | [0.6.0](https://github.com/pexpect/ptyprocess/releases/tag/0.6.0) |
| [pytest-dev/py](https://github.com/pytest-dev/py) | 1.8.0 | [1.8.0](https://github.com/pytest-dev/py/releases/tag/1.8.0) |
| [pyparsing/pyparsing](https://github.com/pyparsing/pyparsing) | 2.4.5 | [pyparsing_2.4.5](https://github.com/pyparsing/pyparsing/releases/tag/pyparsing_2.4.5) |
| [pytest-dev/pytest](https://github.com/pytest-dev/pytest) | 5.3.0 | [5.3.0](https://github.com/pytest-dev/pytest/releases/tag/5.3.0) |
| [stub42/pytz](https://github.com/stub42/pytz) | 2019.3 | [release_2019.3](https://github.com/stub42/pytz/releases/tag/release_2019.3) |
| [uiri/toml](https://github.com/uiri/toml) | 0.10.0 | [0.10.0](https://github.com/uiri/toml/releases/tag/0.10.0) |
| [pallets/werkzeug](https://github.com/pallets/werkzeug) | 0.16.0 | [0.16.0](https://github.com/pallets/werkzeug/releases/tag/0.16.0) |
| [dmnfarrell/tkintertable](https://github.com/dmnfarrell/tkintertable) | 1.2 | [v1.2](https://github.com/dmnfarrell/tkintertable/releases/tag/v1.2) |
| [wxWidgets/wxPython-Classic](https://github.com/wxWidgets/wxPython-Classic) | 2.9.1.1 | [wxPy-2.9.1.1](https://github.com/wxWidgets/wxPython-Classic/releases/tag/wxPy-2.9.1.1) |
| [nasa/fprime](https://github.com/nasa/fprime) | 1.3 | [NASA-v1.3](https://github.com/nasa/fprime/releases/tag/NASA-v1.3) |
| [nucleic/cppy](https://github.com/nucleic/cppy) | 1.1.0 | [1.1.0](https://github.com/nucleic/cppy/releases/tag/1.1.0) |
| [opencv/opencv](https://github.com/opencv/opencv) | 4.5.1 | [4.5.1](https://github.com/opencv/opencv/releases/tag/4.5.1) |
| [curl/curl](https://github.com/curl/curl) | 7.72.0 | [curl-7_72_0](https://github.com/curl/curl/releases/tag/curl-7_72_0) |
| [madler/zlib](https://github.com/madler/zlib) | 1.2.11 | [v1.2.11](https://github.com/madler/zlib/releases/tag/v1.2.11) |
| [apache/lucene](https://github.com/apache/lucene) | 7.7.3 | [releases/lucene-solr/7.7.3](https://github.com/apache/lucene/releases/tag/releases%2Flucene-solr%2F7.7.3) |
| [yaml/libyaml](https://github.com/yaml/libyaml) | 0.2.5 | [0.2.5](https://github.com/yaml/libyaml/releases/tag/0.2.5) |
| [elastic/elasticsearch](https://github.com/elastic/elasticsearch) | 6.8.1 | [v6.8.1](https://github.com/elastic/elasticsearch/releases/tag/v6.8.1) |
| [twbs/bootstrap](https://github.com/twbs/bootstrap) | 4.3.1 | [v4.3.1](https://github.com/twbs/bootstrap/releases/tag/v4.3.1) |
| [vuejs/vue](https://github.com/vuejs/vue) | 2.6.10 | [v2.6.10](https://github.com/vuejs/vue/releases/tag/v2.6.10) |
| [carrotsearch/hppc](https://github.com/carrotsearch/hppc) | 0.7.1 | [0.7.1](https://github.com/carrotsearch/hppc/releases/tag/0.7.1) |
| [JodaOrg/joda-time](https://github.com/JodaOrg/joda-time) | 2.10.1 | [v2.10.1](https://github.com/JodaOrg/joda-time/releases/tag/v2.10.1) |
| [tdunning/t-digest](https://github.com/tdunning/t-digest) | 3.3.3 | [t-digest-3.2](https://github.com/tdunning/t-digest/releases/tag/t-digest-3.2) |
| [HdrHistogram/HdrHistogram](https://github.com/HdrHistogram/HdrHistogram) | 2.1.9 | [HdrHistogram-2.1.9](https://github.com/HdrHistogram/HdrHistogram/releases/tag/HdrHistogram-2.1.9) |
| [locationtech/spatial4j](https://github.com/locationtech/spatial4j) | 0.7 | [spatial4j-0.7](https://github.com/locationtech/spatial4j/releases/tag/spatial4j-0.7) |
| [locationtech/jts](https://github.com/locationtech/jts) | 1.15.0 | [jts-1.15.0](https://github.com/locationtech/jts/releases/tag/jts-1.15.0) |
| [apache/logging-log4j2](https://github.com/apache/logging-log4j2) | 2.11 | [log4j-2.11.0](https://github.com/apache/logging-log4j2/releases/tag/log4j-2.11.0) |
## Weiterführende Informationen
- „[Informationen zu Ihrem Profil](/articles/about-your-profile)“

View File

@@ -1,35 +0,0 @@
---
title: Elemente an Dein Profil anheften
intro: You can pin gists and repositories to your profile so other people can quickly see your best work.
redirect_from:
- /articles/pinning-repositories-to-your-profile/
- /articles/pinning-items-to-your-profile
- /github/setting-up-and-managing-your-github-profile/pinning-items-to-your-profile
- /github/setting-up-and-managing-your-github-profile/customizing-your-profile/pinning-items-to-your-profile
versions:
fpt: '*'
ghes: '*'
ghec: '*'
topics:
- Profiles
shortTitle: Pin items
---
Du kannst ein öffentliches Repository anheften, wenn Dir das Repository gehört oder wenn Du Beiträge zu dem Repository geleistet hast. Commits zu Forks zählen nicht als Beiträge. Daher kannst Du Forks, die Du nicht besitzt, auch nicht anheften. Weitere Informationen findest Du unter „[Warum werden meine Beiträge nicht in meinem Profil angezeigt?](/articles/why-are-my-contributions-not-showing-up-on-my-profile)“
Du kannst alle öffentlichen Gists anheften, die Du besitzt.
Angeheftete Elemente enthalten wichtige Informationen über das Element, wie beispielsweise die Anzahl der Sterne, die ein Repository erhalten hat, oder die ersten Zeilen eines Gist. Wenn Du Elemente an Dein Profil angeheftet hast, ersetzt der Bereich „Pinned“ (Angeheftet) den Bereich „Popular repositories“ (Beliebte Repositorys) in Deinem Profil.
Du kannst die Elemente im Bereich „Pinned“ (Angeheftet) neu anordnen. Klicke in der oberen rechten Ecke eines angehefteten Elements auf {% octicon "grabber" aria-label="The grabber symbol" %}, und ziehe es an eine andere Stelle.
{% data reusables.profile.access_profile %}
2. Klicke im Bereich „Popular repositories“ (Beliebte Repositorys) oder „Pinned“ (Angeheftet) auf **Customize your pins** (Angeheftete Elemente anpassen). ![Schaltfläche „Customize your pins“ (Deine angeheftete Elemente anpassen)](/assets/images/help/profile/customize-pinned-repositories.png)
3. Um eine durchsuchbare Liste mit anzuheftenden Elementen anzuzeigen, wähle „Repositories“ (Repositorys), „Gists“ (Gists) oder beides aus. ![Kontrollkästchen zum Auswählen der Art der anzuzeigenden Elemente](/assets/images/help/profile/pinned-repo-picker.png)
4. Um ein bestimmtes Element leichter zu finden, kannst Du optional den Namen eines Benutzers, einer Organisation, eines Repositorys oder eines Gists eingeben. ![Elemente filtern](/assets/images/help/profile/pinned-repo-search.png)
5. Wähle eine Kombination von bis zu sechs Repositorys und/oder Gists zum Anzeigen aus. ![Elemente auswählen](/assets/images/help/profile/select-items-to-pin.png)
6. Klicke auf **Save pins** (Angeheftete Elemente speichern). ![Schaltfläche „Save pins“ (Angeheftete Elemente speichern)](/assets/images/help/profile/save-pinned-repositories.png)
## Weiterführende Informationen
- „[Informationen zu Ihrem Profil](/articles/about-your-profile)“

View File

@@ -1,19 +0,0 @@
---
title: Dein GitHub-Profil einrichten und verwalten
intro: You can customize your GitHub profile and manage your contribution graph.
shortTitle: Profile
redirect_from:
- /categories/setting-up-and-managing-your-github-profile
- /github/setting-up-and-managing-your-github-profile
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Profiles
children:
- /customizing-your-profile
- /managing-contribution-graphs-on-your-profile
---

View File

@@ -1,23 +0,0 @@
---
title: Beteiligungsdiagramme in Deinem Profil verwalten
intro: 'Deine Beiträge, darunter auch Commits, vorgeschlagene Pull Requests und geöffnete Issues, werden in Deinem Profil angezeigt, damit andere Personen Deine Arbeit leicht finden können.'
redirect_from:
- /articles/managing-contribution-graphs-on-your-profile
- /github/setting-up-and-managing-your-github-profile/managing-contribution-graphs-on-your-profile
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Profiles
children:
- /viewing-contributions-on-your-profile
- /showing-an-overview-of-your-activity-on-your-profile
- /publicizing-or-hiding-your-private-contributions-on-your-profile
- /sending-enterprise-contributions-to-your-githubcom-profile
- /why-are-my-contributions-not-showing-up-on-my-profile
- /troubleshooting-commits-on-your-timeline
shortTitle: Manage contribution graph
---

View File

@@ -1,36 +0,0 @@
---
title: Private Beiträge in Deinem Profil veröffentlichen oder verbergen
intro: 'Ihr {% data variables.product.product_name %}-Profil zeigt ein Diagramm Ihrer Repository-Beiträge des letzten Jahres an. You can choose to show anonymized activity from {% ifversion fpt or ghes or ghec %}private and internal{% else %}private{% endif %} repositories{% ifversion fpt or ghes or ghec %} in addition to the activity from public repositories{% endif %}.'
redirect_from:
- /articles/publicizing-or-hiding-your-private-contributions-on-your-profile
- /github/setting-up-and-managing-your-github-profile/publicizing-or-hiding-your-private-contributions-on-your-profile
- /github/setting-up-and-managing-your-github-profile/managing-contribution-graphs-on-your-profile/publicizing-or-hiding-your-private-contributions-on-your-profile
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Profiles
shortTitle: Private contributions
---
Wenn Du Deine privaten Beiträge veröffentlichst, können Benutzer, die keinen Zugriff auf die Repositorys haben, an denen Du mitarbeitest, die Informationen zu Deinen privaten Beiträgen nicht sehen. Stattdessen sehen sie die Anzahl an privaten Beiträgen, die Du pro Tag geleistet hast. Zu Deinen öffentlichen Beiträgen werden detaillierte Informationen angezeigt. For more information, see "[Viewing contributions on your profile page](/articles/viewing-contributions-on-your-profile-page)."
{% note %}
**Note:** {% ifversion fpt or ghes or ghec %}On {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom_the_website %}{% elsif ghes %}{% data variables.product.product_name %}{% endif %}, public contributions on your profile are visible {% ifversion fpt or ghec %}to anyone in the world who can access {% data variables.product.prodname_dotcom_the_website %}{% elsif ghes %}only to other users of {% data variables.product.product_location%}{% endif %}.{% elsif ghae %}On {% data variables.product.prodname_ghe_managed %}, only other members of your enterprise can see the contributions on your profile.{% endif %}
{% endnote %}
## Die Sichtbarkeit Deiner privaten Beiträge ändern
{% data reusables.profile.access_profile %}
1. Veröffentliche Deine privaten Beiträge in Deinem Profil, oder blende sie aus:
- Um Deine privaten Beiträge zu veröffentlichen, wähle über Deinem Beteiligungsdiagramm im Dropdownmenü **Contribution settings** (Beitragseinstellungen) die Option **Private contributions** (Private Beiträge) aus. Besucher sehen die Anzahl Deiner privaten Beiträge ohne weitere Details. ![Im Dropdownmenü mit den Beitragseinstellungen festlegen, dass Besucher private Beiträge sehen können](/assets/images/help/profile/private-contributions-on.png)
- Um Deine privaten Beiträge auszublenden, hebe über Deinem Beteiligungsdiagramm im Dropdownmenü **Contribution settings** (Beitragseinstellungen) die Auswahl der Option **Private contributions** (Private Beiträge) auf. Besucher sehen dann nur Deine öffentlichen Beiträge. ![Im Dropdownmenü mit den Beitragseinstellungen festlegen, dass Besucher private Beiträge sehen können](/assets/images/help/profile/private-contributions-off.png)
## Weiterführende Informationen
- „[Beiträge auf Ihrer Profilseite anzeigen](/articles/viewing-contributions-on-your-profile-page)“
- „[Warum werden meine Beiträge nicht in meinem Profil angezeigt?](/articles/why-are-my-contributions-not-showing-up-on-my-profile)“

View File

@@ -1,66 +0,0 @@
---
title: Sending enterprise contributions to your GitHub.com profile
intro: 'Sie können Ihre Arbeiten auf {% data variables.product.prodname_enterprise %} hervorheben, indem Sie die Anzahl Ihrer Beiträge an Ihr {% data variables.product.prodname_dotcom_the_website %}-Profil senden.'
redirect_from:
- /articles/sending-your-github-enterprise-contributions-to-your-github-com-profile/
- /articles/sending-your-github-enterprise-server-contributions-to-your-github-com-profile
- /articles/sending-your-github-enterprise-server-contributions-to-your-githubcom-profile
- /github/setting-up-and-managing-your-github-profile/sending-your-github-enterprise-server-contributions-to-your-githubcom-profile
- /github/setting-up-and-managing-your-github-profile/managing-contribution-graphs-on-your-profile/sending-your-github-enterprise-server-contributions-to-your-githubcom-profile
versions:
fpt: '*'
ghes: '*'
ghae: next
ghec: '*'
topics:
- Profiles
shortTitle: Send enterprise contributions
---
## About enterprise contributions on your {% data variables.product.prodname_dotcom_the_website %} profile
Your {% data variables.product.prodname_dotcom_the_website %} profile shows {% ifversion fpt or ghec %}{% data variables.product.prodname_ghe_server %}{% ifversion ghae-next %}<!-- Remove condition entirely when toggling feature flag --> or {% data variables.product.prodname_ghe_managed %}{% endif %}{% else %}{% data variables.product.product_name %}{% endif %} contribution counts from the past 90 days. Die {% data reusables.github-connect.sync-frequency %}-Anzahl Ihrer Beiträge aus {% data variables.product.prodname_enterprise %} wird unter Ihren privaten Beiträgen erfasst. The commit details will only show the contribution counts and that these contributions were made in a {% data variables.product.prodname_enterprise %} environment outside of {% data variables.product.prodname_dotcom_the_website %}.
You can decide whether to show counts for private contributions on your profile. Weitere Informationen findest Du unter „[Private Beiträge in Deinem Profil veröffentlichen oder verbergen](/articles/publicizing-or-hiding-your-private-contributions-on-your-profile/).“
Weitere Informationen zur Berechnung der Beitragszahlen findest Du unter „[Beteiligungsdiagramme in Deinem Profil verwalten](/articles/managing-contribution-graphs-on-your-profile/).“
{% note %}
**Hinweise:**
- Für die Verbindung zwischen Deinen Konten gilt die <a href="/articles/github-privacy-statement/" class="dotcom-only">GitHub-Datenschutzerklärung</a>. Benutzer, die diese Verbindung aktivieren, stimmen den <a href="/articles/github-terms-of-service/" class="dotcom-only">Nutzungsbedingungen von GitHub</a> zu.
- Before you can connect your {% ifversion fpt or ghec %}{% data variables.product.prodname_ghe_server %}{% ifversion ghae-next %}<!-- Remove condition entirely when toggling feature flag --> or {% data variables.product.prodname_ghe_managed %}{% endif %}{% else %}{% data variables.product.product_name %}{% endif %} profile to your {% data variables.product.prodname_dotcom_the_website %} profile, your enterprise owner must enable {% data variables.product.prodname_github_connect %} and enable contribution sharing between the environments. For more information, contact your enterprise owner.
{% endnote %}
{% ifversion fpt or ghes or ghae or ghec %}
## Sending your enterprise contributions to your {% data variables.product.prodname_dotcom_the_website %} profile
{% ifversion fpt or ghec %}
- To send enterprise contributions from {% data variables.product.prodname_ghe_server %} to your {% data variables.product.prodname_dotcom_the_website %} profile, see "[Sending enterprise contributions to your {% data variables.product.prodname_dotcom_the_website %} profile](/enterprise-server/account-and-profile/setting-up-and-managing-your-github-profile/managing-contribution-graphs-on-your-profile/sending-enterprise-contributions-to-your-githubcom-profile)" in the {% data variables.product.prodname_ghe_server %} documentation.{% ifversion ghae-next %}<!-- Condition is within an fpt block; remove condition entirely when toggling feature flag -->
- To send enterprise contributions from {% data variables.product.prodname_ghe_managed %} to your {% data variables.product.prodname_dotcom_the_website %} profile, see "[Sending enterprise contributions to your {% data variables.product.prodname_dotcom_the_website %} profile](/github-ae@latest/account-and-profile/setting-up-and-managing-your-github-profile/managing-contribution-graphs-on-your-profile/sending-enterprise-contributions-to-your-githubcom-profile)" in the {% data variables.product.prodname_ghe_managed %} documentation.{% endif %}
{% elsif ghes %}
1. Sign in to {% data variables.product.prodname_ghe_server %} and {% data variables.product.prodname_dotcom_the_website %}.
1. On {% data variables.product.prodname_ghe_server %}, in the upper-right corner of any page, click your profile photo, then click **Settings**. ![Symbol „Settings" (Einstellungen) auf der Benutzerleiste](/assets/images/help/settings/userbar-account-settings.png)
{% data reusables.github-connect.github-connect-tab-user-settings %}
{% data reusables.github-connect.connect-dotcom-and-enterprise %}
1. Überprüfe die Ressourcen, auf welche {% data variables.product.prodname_ghe_server %} von Deinem {% data variables.product.prodname_dotcom_the_website %}-Konto zugreifen wird, dann klicke **Authorize** (Autorisieren). ![Autorisiere die Verbindung zwischen dem GitHub Enterprise Server und GitHub.com](/assets/images/help/settings/authorize-ghe-to-connect-to-dotcom.png)
{% data reusables.github-connect.send-contribution-counts-to-githubcom %}
{% elsif ghae %}
1. Sign in to {% data variables.product.prodname_ghe_managed %} and {% data variables.product.prodname_dotcom_the_website %}.
1. On {% data variables.product.prodname_ghe_managed %}, in the upper-right corner of any page, click your profile photo, then click **Settings**. ![Symbol „Settings" (Einstellungen) auf der Benutzerleiste](/assets/images/help/settings/userbar-account-settings.png)
{% data reusables.github-connect.github-connect-tab-user-settings %}
{% data reusables.github-connect.connect-dotcom-and-enterprise %}
{% data reusables.github-connect.authorize-connection %}
{% data reusables.github-connect.send-contribution-counts-to-githubcom %}
{% endif %}
{% endif %}

View File

@@ -1,38 +0,0 @@
---
title: GitHub Enterprise Server-Beiträge an Dein GitHub.com-Profil senden
intro: 'Sie können Ihre Arbeiten auf {% data variables.product.prodname_ghe_server %} hervorheben, indem Sie die Anzahl Ihrer Beiträge an Ihr {% data variables.product.prodname_dotcom_the_website %}-Profil senden.'
redirect_from:
- /articles/sending-your-github-enterprise-contributions-to-your-github-com-profile/
- /articles/sending-your-github-enterprise-server-contributions-to-your-github-com-profile
- /articles/sending-your-github-enterprise-server-contributions-to-your-githubcom-profile
- /github/setting-up-and-managing-your-github-profile/sending-your-github-enterprise-server-contributions-to-your-githubcom-profile
- /github/setting-up-and-managing-your-github-profile/managing-contribution-graphs-on-your-profile/sending-your-github-enterprise-server-contributions-to-your-githubcom-profile
versions:
fpt: '*'
ghes: '*'
topics:
- Profiles
shortTitle: Send your contributions
---
{% note %}
**Hinweise:**
- Für die Verbindung zwischen Deinen Konten gilt die <a href="/articles/github-privacy-statement/" class="dotcom-only">GitHub-Datenschutzerklärung</a>. Benutzer, die diese Verbindung aktivieren, stimmen den <a href="/articles/github-terms-of-service/" class="dotcom-only">Nutzungsbedingungen von GitHub</a> zu.
- Um Ihr {% data variables.product.prodname_ghe_server %}-Profil mit Ihrem {% data variables.product.prodname_dotcom_the_website %}-Profil verbinden zu können, muss ein Websiteadministrator {% data variables.product.prodname_github_connect %} und den Beitragsaustausch zwischen den Umgebungen aktivieren. Weitere Informationen erhältst Du von Deinem {% data variables.product.prodname_ghe_server %}-Websiteadministrator.
{% endnote %}
Ihr {% data variables.product.prodname_dotcom_the_website %}-Profil zeigt die Anzahl Ihrer {% data variables.product.prodname_ghe_server %}-Beiträge der letzten 90 Tage an. Die {% data reusables.github-connect.sync-frequency %}-Anzahl Ihrer Beiträge aus {% data variables.product.prodname_ghe_server %} wird unter Ihren privaten Beiträgen erfasst. Die Commit-Details enthalten nur die Beitragszähler und die Information, dass diese Beiträge auf {% data variables.product.prodname_ghe_server %} erfolgt sind.
Endbenutzer von {% data variables.product.prodname_ghe_server %} und {% data variables.product.prodname_dotcom_the_website %} können ihre privaten Beitragszahlen veröffentlichen. Weitere Informationen findest Du unter „[Private Beiträge in Deinem Profil veröffentlichen oder verbergen](/articles/publicizing-or-hiding-your-private-contributions-on-your-profile/).“
Weitere Informationen zur Berechnung der Beitragszahlen findest Du unter „[Beteiligungsdiagramme in Deinem Profil verwalten](/articles/managing-contribution-graphs-on-your-profile/).“
{% data reusables.github-connect.access-dotcom-and-enterprise %}
{% data reusables.github-connect.access-profile-settings %}
{% data reusables.github-connect.github-connect-tab-user-settings %}
{% data reusables.github-connect.connect-dotcom-and-enterprise %}
{% data reusables.github-connect.authorize-connection %}
6. Aktivieren Sie unter „Contributions“ (Beiträge) das Kontrollkästchen **Send my contribution counts to {% data variables.product.prodname_dotcom_the_website %}** (Anzahl meiner Beiträge an {% data variables.product.prodname_dotcom_the_website %} senden), und klicken Sie auf **Update contributions** (Beiträge aktualisieren). ![Kontrollkästchen „Send my contribution counts...“ (Anzahl meiner Beiträge senden) und Schaltfläche „Update contributions“ (Beiträge aktualisieren)](/assets/images/help/settings/send-and-update-contributions.png)

View File

@@ -1,23 +0,0 @@
---
title: Übersicht über Deine Aktivitäten in Deinem Profil anzeigen
intro: 'In Deinem Profil kannst Du die Aktivitätsübersicht aktivieren, in der Betrachter eine Übersicht über die Art Deiner Beiträge erhalten.'
redirect_from:
- /articles/showing-an-overview-of-your-activity-on-your-profile
- /github/setting-up-and-managing-your-github-profile/showing-an-overview-of-your-activity-on-your-profile
- /github/setting-up-and-managing-your-github-profile/managing-contribution-graphs-on-your-profile/showing-an-overview-of-your-activity-on-your-profile
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Profiles
shortTitle: Show an overview
---
{% data reusables.profile.activity-overview-summary %} Weitere Informationen findest Du unter „[Beiträge in Deinem Profil anzeigen](/articles/viewing-contributions-on-your-profile).“
![Aktivitätsübersicht im Profil](/assets/images/help/profile/activity-overview-section.png)
{% data reusables.profile.access_profile %}
2. Verwende oberhalb Deines Beitragsdiagramms das Dropdownmenü **Contribution settings** (Beitragseinstellungen) und aktiviere oder deaktiviere die Option **Activity overview** (Aktivitätsübersicht). ![Aktivitätsübersicht im Dropdownmenü „Contribution settings“ (Beitragseinstellungen) aktivieren](/assets/images/help/profile/activity-overview.png)

View File

@@ -1,69 +0,0 @@
---
title: Fehlerbehebung bei Commit-Fehlern mithilfe der Zeitleiste
intro: 'Details zu einzelnen Commits findest Du in der Zeitleiste Deines Profils. Wenn Du in Deinem Profil respektive auf der Profilseite keine Details zu einem erwarteten Commit findest, weichen das Erstellungs- und das Commit-Datum des Commits eventuell voneinander ab.'
redirect_from:
- /articles/troubleshooting-commits-on-your-timeline
- /github/setting-up-and-managing-your-github-profile/troubleshooting-commits-on-your-timeline
- /github/setting-up-and-managing-your-github-profile/managing-contribution-graphs-on-your-profile/troubleshooting-commits-on-your-timeline
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Profiles
shortTitle: Troubleshoot commits
---
## Erwartetes Verhalten bei der Anzeige der Commit-Details über die Zeitleiste
Wenn Du in der Zeitleiste Deiner Profilseite neben einem Repository auf die Anzahl der Commits klickst, werden die Details zu Deinen Commits des betreffenden Zeitraums angezeigt, einschließlich eines Diffs der spezifischen Änderungen am Repository.
![Commit-Link in der Zeitleiste des Profils](/assets/images/help/profile/commit-link-on-profile-timeline.png)
![Commit-Details](/assets/images/help/commits/commit-details.png)
## Fehlende Commit-Details in der Zeitleiste
Wenn Du auf Deiner Profilseite auf einen Commit-Link klickst und auf der Commit-Seite des Repositorys nicht alle erwarteten Commits vorfindest, könnte es sein, dass der Commit-Verlauf in Git umgeschrieben wurde und das Erstellungs- und das Commit-Datum der Commits voneinander abweichen.
![Repository-Seite mit der Meldung „No commits found for octocat“ (Keine Commits für Octocat gefunden)](/assets/images/help/repository/no-commits-found.png)
## So verwendet GitHub das Erstellungs- und Commit-Datum von Git
In Git bezeichnet das Erstellungsdatum das Datum, an dem ein Commit ursprünglich mit dem Befehl `git commit` erstellt wurde. Das Commit-Datum ist mit diesem Datum identisch, solange der ursprüngliche Commit, und damit das Commit-Datum, nicht später durch `git commit --amend`, einen erzwungenen Push, ein Rebase oder einen anderen Git-Befehl geändert wurde.
Auf Deiner Profilseite wird das Bearbeitungsdatum zur Berechnung des Commit-Datums verwendet. In einem Repository gilt dagegen das Commit-Datum als Erstellungsdatum des Commits im Repository.
Meist sind das Verfassungs- und Commit-Datum identisch. Gelegentlich aber gerät die Commit-Abfolge durcheinander, wenn der Commit-Verlauf geändert wird. Weitere Informationen findest Du unter „[Warum werden meine Beiträge nicht in meinem Profil angezeigt?](/articles/why-are-my-contributions-not-showing-up-on-my-profile)“
## Fehlende Commit-Details in der Zeitleiste anzeigen
Mit dem Befehl `git show` und dem Flag `--pretty=fuller` kannst Du überprüfen, ob das Erstellungs- und das Commit-Datum eines Commits identisch sind.
```shell
$ git show <em>Your commit SHA number</em> --pretty=fuller
commit <em>Your commit SHA number</em>
Author: octocat <em>user email</em>
AuthorDate: Tue Apr 03 02:02:30 2018 +0900
Commit: Sally Johnson <em>user email</em>
CommitDate: Tue Apr 10 06:25:08 2018 +0900
```
Weichen das Erstellungs- und Commit-Datum voneinander ab, kannst Du das Commit-Datum in der URL manuell ändern, um die Commit-Details anzuzeigen.
Ein Beispiel:
- Die folgende URL verwendet das Verfassungsdatum `2018-04-03`:
`https://github.com/your-organization-or-personal-account/your-repository/commits?author=octocat&since=2018-04-03T00:00:00Z&until=2018-04-03T23:59:59Z`
- Die folgende URL verwendet das Commit-Datum `2018-04-10`:
`https://github.com/your-organization-or-personal-account/your-repository/commits?author=octocat&since=2018-04-10T00:00:00Z&until=2018-04-10T23:59:59Z`
Wenn Du die URL mit dem korrigierten Commit-Datum aufrufst, werden die Commit-Details angezeigt.
![Commit-Details](/assets/images/help/commits/commit-details.png)
## Wenn erwartete Commits in der Zeitleiste fehlen
Wenn in Deiner Zeitleiste nicht alle erwarteten Commits angezeigt werden, könnte es sein, dass der Commit-Verlauf in Git umgeschrieben wurde und das Erstellungs- und das Commit-Datum der Commits voneinander abweichen. Weitere Ursachen dieses Verhaltens werden unter der Frage „[Warum werden meine Beiträge nicht in meinem Profil angezeigt?](/articles/why-are-my-contributions-not-showing-up-on-my-profile)“ beschrieben.

View File

@@ -1,105 +0,0 @@
---
title: Beiträge auf Deinem Profil anzeigen
intro: 'Your {% data variables.product.product_name %} profile shows off {% ifversion fpt or ghes or ghec %}your pinned repositories as well as{% endif %} a graph of your repository contributions over the past year.'
redirect_from:
- /articles/viewing-contributions/
- /articles/viewing-contributions-on-your-profile-page/
- /articles/viewing-contributions-on-your-profile
- /github/setting-up-and-managing-your-github-profile/viewing-contributions-on-your-profile
- /github/setting-up-and-managing-your-github-profile/managing-contribution-graphs-on-your-profile/viewing-contributions-on-your-profile
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Profiles
shortTitle: View contributions
---
{% ifversion fpt or ghes or ghec %}Your contribution graph shows activity from public repositories. {% endif %}You can choose to show activity from {% ifversion fpt or ghes or ghec %}both public and {% endif %}private repositories, with specific details of your activity in private repositories anonymized. Weitere Informationen finden Sie unter „[Private Beiträge in Ihrem Profil veröffentlichen oder verbergen](/articles/publicizing-or-hiding-your-private-contributions-on-your-profile)“.
{% note %}
**Note:** Commits will only appear on your contributions graph if the email address you used to author the commits is connected to your account on {% data variables.product.product_name %}. Weitere Informationen findest Du unter „[Warum werden meine Beiträge nicht in meinem Profil angezeigt?](/articles/why-are-my-contributions-not-showing-up-on-my-profile#your-local-git-commit-email-isnt-connected-to-your-account)“
{% endnote %}
## Was zählt als ein Beitrag?
Bestimmte Aktionen zählen auf Deiner Profilseite als Beiträge:
- Commits zum Standardbranch eines Repositorys oder zum Branch `gh-pages`
- das Öffnen eines Issues
- Opening a discussion
- Answering a discussion
- das Vorschlagen eines Pull Requests
- das Absenden eines Pull-Request-Reviews{% ifversion ghes or ghae %}
- Commits mit Co-Autor im Standardbranch eines Repositorys oder im Branch `gh-pages`{% endif %}
{% data reusables.pull_requests.pull_request_merges_and_contributions %}
## Beliebte Repositorys
Dieser Abschnitt zeigt Deine Repositorys mit den meisten Beobachtern (Watcher) an. {% ifversion fpt or ghes or ghec %}Once you [pin repositories to your profile](/articles/pinning-repositories-to-your-profile), this section will change to "Pinned repositories."{% endif %}
![Beliebte Repositorys](/assets/images/help/profile/profile_popular_repositories.png)
{% ifversion fpt or ghes or ghec %}
## Angeheftete Repositorys
Dieser Abschnitt zeigt bis zu sechs öffentliche Repositorys an und kann sowohl Deine Repositorys als auch die Repositorys enthalten, an denen Du Dich beteiligt hast. Damit Du ohne Weiteres wichtige Details zu den ausgewählten Repositorys anzeigen kannst, enthält jedes Repository in diesem Abschnitt eine Zusammenfassung der zu erledigenden Arbeit, die Anzahl der [Sterne](/articles/saving-repositories-with-stars/) des Repositorys und die im Repository verwendete Hauptprogrammiersprache. Weitere Informationen findest Du unter „[Repositorys an Dein Profil anheften](/articles/pinning-repositories-to-your-profile).“
![Angeheftete Repositorys](/assets/images/help/profile/profile_pinned_repositories.png)
{% endif %}
## Beitragskalender
Dein Beitragskalender zeigt Deine Beitragsaktivität an.
### Beiträge aus bestimmten Zeiten anzeigen
- Klicke auf das Quadrat eines Tages, um die während diesem 24-Stunden-Zeitraum vorgenommenen Beiträge anzuzeigen.
- Press *Shift* and click on another day's square to show contributions made during that time span.
{% note %}
**Hinweis:** In Deinem Beitragskalender kannst Du einen Zeitraum von bis zu einem Monat auswählen. If you select a larger time span, we will only display one month of contributions.
{% endnote %}
![Dein Beteiligungsdiagramm](/assets/images/help/profile/contributions_graph.png)
### Funktionsweise der Berechnung von Ereigniszeiten für Beiträge
Zeitstempel werden für Commits und Pull Requests unterschiedlich berechnet:
- **Commits** verwenden die Zeitzoneninformationen im Commit-Zeitstempel. Weitere Informationen findest Du unter „[Fehlerbehebung bei Commits auf Deiner Zeitleiste](/articles/troubleshooting-commits-on-your-timeline).“
- Die auf {% data variables.product.product_name %} geöffneten **Pull Requests** und **Issues** verwenden die Zeitzone Deines Browsers. Die über die API geöffneten verwenden den Zeitstempel oder die Zeitzone, [der bzw. die im API-Aufruf angegeben wurde](https://developer.github.com/changes/2014-03-04-timezone-handling-changes).
## Aktivitätsübersicht
{% data reusables.profile.activity-overview-summary %} Weitere Informationen findest Du unter „[Übersicht über Deine Aktivitäten in Deinem Profil anzeigen](/articles/showing-an-overview-of-your-activity-on-your-profile).“
![Aktivitätsübersicht im Profil](/assets/images/help/profile/activity-overview-section.png)
Die in der Aktivitätsübersicht angezeigten Organisationen werden dementsprechend priorisiert, wie aktiv Sie in der Organisation sind. Wenn Sie in Ihrer Profil-Bio eine Organisation @erwähnen und Sie ein Organisationsmitglied sind, wird diese Organisation in der Aktivitätsübersicht priorisiert. For more information, see "[Mentioning people and teams](/articles/basic-writing-and-formatting-syntax/#mentioning-people-and-teams)" or "[Adding a bio to your profile](/articles/adding-a-bio-to-your-profile/)."
## Beitragsaktivität
Der Abschnitt für die Beitragsaktivität enthält eine detaillierte Zeitleiste zu Ihrer Arbeit. Dazu zählen die von Ihnen erstellten oder mitverfassten Commits, die von Ihnen vorgeschlagenen Pull Requests und die von Ihnen geöffneten Issues. Du kannst Deine über einen gewissen Zeitraum erstellten Beiträge anzeigen. Klicke dazu im unteren Bereich Deiner Beitragsaktivität auf **Show more activity** (Mehr Aktivität anzeigen) oder im rechten Bereich der Seite auf das gewünschte Jahr. Wichtige Momente werden in Ihrer Beitragsaktivität hervorgehoben. Dazu zählen Ihr Beitrittsdatum zu einer Organisation, Ihr erster vorgeschlagener Pull Request oder das Öffnen eines hochrangigen Issues. Wenn Sie bestimmte Ereignisse auf Ihrer Zeitleiste nicht anzeigen können, sollten Sie sicherstellen, dass Sie weiterhin auf die Organisation oder das Repository zugreifen können, in der bzw. in dem das Ereignis auftrat.
![Zeitfilter für Beitragsaktivität](/assets/images/help/profile/contributions_activity_time_filter.png)
{% ifversion fpt or ghes or ghae-next or ghec %}
## Beiträge von {% data variables.product.prodname_enterprise %} auf {% data variables.product.prodname_dotcom_the_website %} anzeigen
If you use {% ifversion fpt or ghec %}{% data variables.product.prodname_ghe_server %}{% ifversion ghae-next %} or {% data variables.product.prodname_ghe_managed %}{% endif %}{% else %}{% data variables.product.product_name %}{% endif %} and your enterprise owner enables {% data variables.product.prodname_unified_contributions %}, you can send enterprise contribution counts from to your {% data variables.product.prodname_dotcom_the_website %} profile. For more information, see "[Sending enterprise contributions to your {% data variables.product.prodname_dotcom_the_website %} profile](/account-and-profile/setting-up-and-managing-your-github-profile/managing-contribution-graphs-on-your-profile/sending-enterprise-contributions-to-your-githubcom-profile)."
{% endif %}
## Weiterführende Informationen
- „[Beiträge auf Ihrer Profilseite anzeigen](/articles/viewing-contributions-on-your-profile-page)“

View File

@@ -1,98 +0,0 @@
---
title: Warum werden meine Beiträge nicht in meinem Profil angezeigt?
intro: Learn common reasons that contributions may be missing from your contributions graph.
redirect_from:
- /articles/why-are-my-contributions-not-showing-up-on-my-profile
- /github/setting-up-and-managing-your-github-profile/why-are-my-contributions-not-showing-up-on-my-profile
- /github/setting-up-and-managing-your-github-profile/managing-contribution-graphs-on-your-profile/why-are-my-contributions-not-showing-up-on-my-profile
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Profiles
shortTitle: Missing contributions
---
## About your contribution graph
Your profile contributions graph is a record of contributions you've made to repositories {% ifversion ghae %}owned by{% else %}on{% endif %} {% data variables.product.product_location %}. Beiträge werden nicht entsprechend Deiner lokalen Zeitzone, sondern entsprechend der UTC-Zone (Coordinated Universal Time, koordinierte Weltzeit) mit Zeitstempeln versehen. Beiträge werden nur gezählt, falls sie bestimmte Kriterien erfüllen. In manchen Fällen muss Dein Diagramm allenfalls neu erstellt werden, damit die Beiträge angezeigt werden.
## Gezählte Beiträge
### Issues, pull requests and discussions
Issues, pull requests and discussions will appear on your contribution graph if they were opened in a standalone repository, not a fork.
### Commits
Commits werden in Deinem Beteiligungsdiagramm angezeigt, falls sie **alle** folgenden Bedingungen erfüllen:
- The email address used for the commits is associated with your account on {% data variables.product.product_location %}.
- Die Commits wurden in einem eigenständigen Repository vorgenommen und nicht in einem Fork.
- Die Commits wurden
- In the repository's default branch
- im `gh-pages`-Branch vorgenommen (für Repositorys mit Projekt-Websites)
For more information on project sites, see "[About {% data variables.product.prodname_pages %}](/pages/getting-started-with-github-pages/about-github-pages#types-of-github-pages-sites)."
Außerdem muss **mindestens eine** der folgenden Voraussetzung erfüllt sein:
- Du bist ein Repository-Mitarbeiter oder ein Mitglied der Organisation, welcher das Repository gehört.
- Du hast das Repository geforkt.
- Du hast einen Pull Request oder Issue im Repository geöffnet.
- Sie haben das Repository mit Sternen versehen.
## Allgemeine Ursachen für nicht gezählte Beiträge
{% data reusables.pull_requests.pull_request_merges_and_contributions %}
### Die Commit-Erstellung liegt weniger als 24 Stunden zurück
Nachdem Du einen Commit erstellt hast, der die Anforderung erfüllt, um als Beitrag gezählt zu werden, kann es bis zu 24 Stunden dauern, bis der Beitrag in Deinem Beteiligungsdiagramm angezeigt wird.
### Your local Git commit email isn't connected to your account
Commits must be made with an email address that is connected to your account on {% data variables.product.product_location %}{% ifversion fpt or ghec %}, or the {% data variables.product.prodname_dotcom %}-provided `noreply` email address provided to you in your email settings,{% endif %} in order to appear on your contributions graph.{% ifversion fpt or ghec %} For more information about `noreply` email addresses, see "[Setting your commit email address](/github/setting-up-and-managing-your-github-user-account/setting-your-commit-email-address#about-commit-email-addresses)."{% endif %}
Du kannst die für einen Commit verwendete E-Mail-Adresse überprüfen. Füge dazu `.patch` am Ende einer Commit-URL hinzu, also beispielsweise <a href="https://github.com/octocat/octocat.github.io/commit/67c0afc1da354d8571f51b6f0af8f2794117fd10.patch" data-proofer-ignore>https://github.com/octocat/octocat.github.io/commit/67c0afc1da354d8571f51b6f0af8f2794117fd10.patch</a>:
```
From 67c0afc1da354d8571f51b6f0af8f2794117fd10 Mon Sep 17 00:00:00 2001
From: The Octocat <octocat@nowhere.com>
Date: Sun, 27 Apr 2014 15:36:39 +0530
Subject: [PATCH] updated index for better welcome message
```
Bei der im Feld `From:` (Von) angegebenen E-Mail-Adresse handelt es sich um die Adresse, die in den [Einstellungen für die lokale Git-Konfiguration](/articles/set-up-git) festgelegt wurde. In diesem Beispiel lautet die für den Commit verwendete E-Mail-Adresse `octocat@nowhere.com`.
If the email address used for the commit is not connected to your account on {% data variables.product.product_location %}, {% ifversion ghae %}change the email address used to author commits in Git. For more information, see "[Setting your commit email address](/github/setting-up-and-managing-your-github-user-account/setting-your-commit-email-address#setting-your-commit-email-address-in-git)."{% else %}you must [add the email address](/articles/adding-an-email-address-to-your-github-account) to your account on {% data variables.product.product_location %}. Your contributions graph will be rebuilt automatically when you add the new address.{% endif %}
{% warning %}
**Warning**: Generic email addresses, such as `jane@computer.local`, cannot be added to {% data variables.product.prodname_dotcom %} accounts. If you use such an email for your commits, the commits will not be linked to your {% data variables.product.prodname_dotcom %} profile and will not show up in your contribution graph.
{% endwarning %}
### Commit wurde weder auf dem Standard- noch auf dem `gh-pages`-Branch durchgeführt
Commits are only counted if they are made in the default branch or the `gh-pages` branch (for repositories with project sites). For more information, see "[About {% data variables.product.prodname_pages %}](/pages/getting-started-with-github-pages/about-github-pages#types-of-github-pages-sites)."
Falls sich Deine Commits auf einem Nicht-Standard- oder Nicht-`gh-pages`-Branch befinden und sie auf Deine Beiträge angerechnet werden sollen, musst Du eine der folgenden Aktionen durchführen:
- [Öffne einen Pull Request](/articles/creating-a-pull-request), damit Deine Änderungen in den Standardbranch oder in den `gh-pages`-Branch zusammengeführt werden.
- [Ändere den Standardbranch](/github/administering-a-repository/changing-the-default-branch) des Repositorys.
{% warning %}
**Warning**: Changing the default branch of the repository will change it for all repository collaborators. Führe diese Aktion nur dann aus, wenn Du willst, dass der neue Branch zur neuen Basis wird, auf der alle künftigen Pull Requests und Commits durchgeführt werden.
{% endwarning %}
### Commit wurde in einem Fork durchgeführt
Die in einem Fork durchgeführten Commits werden nicht auf Deine Beiträge angerechnet. Führe eine der folgenden Aktionen durch, damit sie angerechnet werden:
- [Öffne einen Pull Request](/articles/creating-a-pull-request), damit Deine Änderungen in das übergeordnete Repository zusammengeführt werden.
- To detach the fork and turn it into a standalone repository on {% data variables.product.product_location %}, contact {% data variables.contact.contact_support %}. If the fork has forks of its own, let {% data variables.contact.contact_support %} know if the forks should move with your repository into a new network or remain in the current network. Weitere Informationen findest Du unter „[Informationen zu Forks](/articles/about-forks/).“
## Weiterführende Informationen
- „[Private Beiträge in Deinem Profil veröffentlichen oder verbergen](/articles/publicizing-or-hiding-your-private-contributions-on-your-profile)“
- „[Beiträge auf Ihrer Profilseite anzeigen](/articles/viewing-contributions-on-your-profile-page)“

View File

@@ -1,21 +0,0 @@
---
title: GitHub-Benutzerkonto einrichten und verwalten
intro: 'You can manage settings in your GitHub user account including email preferences, collaborator access for personal repositories, and organization memberships.'
shortTitle: Benutzerkonten
redirect_from:
- /categories/setting-up-and-managing-your-github-user-account
- /github/setting-up-and-managing-your-github-user-account
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Accounts
children:
- /managing-user-account-settings
- /managing-email-preferences
- /managing-access-to-your-personal-repositories
- /managing-your-membership-in-organizations
---

View File

@@ -1,25 +0,0 @@
---
title: Zugriff auf Deine persönlichen Repositorys verwalten
intro: Du kannst anderen Personen Zugriff als Mitarbeiter auf Repositorys Deines persönlichen Kontos gewähren.
redirect_from:
- /categories/101/articles/
- /categories/managing-repository-collaborators/
- /articles/managing-access-to-your-personal-repositories
- /github/setting-up-and-managing-your-github-user-account/managing-access-to-your-personal-repositories
product: '{% data reusables.gated-features.user-repo-collaborators %}'
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Accounts
- Repositories
children:
- /inviting-collaborators-to-a-personal-repository
- /removing-a-collaborator-from-a-personal-repository
- /removing-yourself-from-a-collaborators-repository
- /maintaining-ownership-continuity-of-your-user-accounts-repositories
shortTitle: Access to your repositories
---

View File

@@ -1,61 +0,0 @@
---
title: Mitarbeiter zu einem persönlichen Repository einladen
intro: 'Du kannst {% ifversion fpt or ghec %}Benutzer als Mitarbeiter zu Deinem persönlichen Repository einladen{% else %}Benutzer als Mitarbeiter zu Deinem persönlichen Repository hinzufügen{% endif %}.'
redirect_from:
- /articles/how-do-i-add-a-collaborator/
- /articles/adding-collaborators-to-a-personal-repository/
- /articles/inviting-collaborators-to-a-personal-repository
- /github/setting-up-and-managing-your-github-user-account/inviting-collaborators-to-a-personal-repository
- /github/setting-up-and-managing-your-github-user-account/managing-access-to-your-personal-repositories/inviting-collaborators-to-a-personal-repository
product: '{% ifversion fpt %}{% data reusables.gated-features.user-repo-collaborators %}{% endif %}'
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Accounts
- Repositories
shortTitle: Invite collaborators
---
Repositorys, die einer Organisation gehören, können feiner abgestufte Zugriffsberechtigungen gewähren. Weitere Informationen findest Du unter „[Zugriffsberechtigungen auf {% data variables.product.prodname_dotcom %}](/articles/access-permissions-on-github).“
{% data reusables.organizations.org-invite-expiration %}
{% ifversion fpt or ghec %}
If you're a member of an {% data variables.product.prodname_emu_enterprise %}, you can only invite other members of your enterprise to collaborate with you. {% data reusables.enterprise-accounts.emu-more-info-account %}
{% note %}
**Hinweis:** {% data variables.product.company_short %} beschränkt die Anzahl an Personen, die innerhalb von 24 Stunden zu einem Repository eingeladen werden können. Wenn Du diese Grenze überschreitest, musst Du entweder 24 Stunden warten oder eine Organisation erstellen, um mit mehr Benutzern zusammenzuarbeiten.
{% endnote %}
{% endif %}
1. Bringen Sie den Benutzernamen der Person in Erfahrung, die Sie als Mitarbeiter einladen möchten.{% ifversion fpt or ghec %} Wenn diese Person noch keinen Benutzernamen hat, kann sie sich bei {% data variables.product.prodname_dotcom %} anmelden. Weitere Informationen finden Sie unter „[Für ein neues {% data variables.product.prodname_dotcom %}-Konto anmelden](/articles/signing-up-for-a-new-github-account)“.{% endif %}
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-settings %}
{% ifversion fpt or ghec %}
{% data reusables.repositories.navigate-to-manage-access %}
1. Klicke auf **Invite a collaborator** (Mitarbeiter einladen). ![Schaltfläche "Invite a collaborator" (Mitarbeiter einladen)](/assets/images/help/repository/invite-a-collaborator-button.png)
2. Beginne im Suchfeld den Namen der Person einzugeben, die Du einladen möchtest, dann klicke in der Liste der Übereinstimmungen auf einen Namen. ![Suchfeld für die Eingabe des Namens der Person, die Du zu einem Repository einladen willst](/assets/images/help/repository/manage-access-invite-search-field-user.png)
3. Klicke auf **Add NAME to REPOSITORY** (füge NAME zum REPOSITORY hinzu). ![Schaltfläche, um Mitarbeiter hinzuzufügen](/assets/images/help/repository/add-collaborator-user-repo.png)
{% else %}
5. Klicke auf der linken Seitenleiste auf **Collaborators** (Mitarbeiter). ![Seitenleiste der Repository-Einstellungen, wobei „Collaborators“ (Mitarbeiter) hervorgehoben ist](/assets/images/help/repository/user-account-repo-settings-collaborators.png)
6. Gib unter „Collaborators“ (Mitarbeiter) den Benutzernamen des Mitarbeiters ein.
7. Wähle den Benutzernamen des Mitarbeiters aus dem Dropdownmenü aus. ![Dropdownmenü „Collaborator list" (Liste der Mitarbeiter)](/assets/images/help/repository/repo-settings-collab-autofill.png)
8. Klicke auf **Add collaborator** (Mitarbeiter hinzufügen). !["Add collaborator" button](/assets/images/help/repository/repo-settings-collab-add.png)
{% endif %}
{% ifversion fpt or ghec %}
9. Der Benutzer erhält per E-Mail eine Einladung zum Repository. Wenn er die Einladung annimmt, hat er Mitarbeiterzugriff auf Dein Repository.
{% endif %}
## Weiterführende Informationen
- „[Berechtigungsebenen für ein Repository eines Benutzerkontos](/articles/permission-levels-for-a-user-account-repository/#collaborator-access-for-a-repository-owned-by-a-user-account)“
- „[Mitarbeiter aus einem persönlichen Repository entfernen](/articles/removing-a-collaborator-from-a-personal-repository)“
- „[Dich selbst aus dem Repository eines Mitarbeiters entfernen](/articles/removing-yourself-from-a-collaborator-s-repository)“
- „[Mitglieder in Teams organisieren](/organizations/organizing-members-into-teams)“

View File

@@ -1,38 +0,0 @@
---
title: Kontinuität der Inhaberschaft der Repositorys Deines Benutzerkontos sicherstellen
intro: 'Du kannst jemanden einladen, Deine eigenen Repositorys zu verwalten, wenn Du nicht dazu in der Lage bist.'
versions:
fpt: '*'
ghec: '*'
topics:
- Accounts
- Repositories
redirect_from:
- /github/setting-up-and-managing-your-github-user-account/maintaining-ownership-continuity-of-your-user-accounts-repositories
- /github/setting-up-and-managing-your-github-user-account/managing-access-to-your-personal-repositories/maintaining-ownership-continuity-of-your-user-accounts-repositories
shortTitle: Ownership continuity
---
## Über Nachfolger
Wir empfehlen, einen anderen {% data variables.product.company_short %}-Benutzer einzuladen, Dein Nachfolger zu werden, um Deine eigenen Repositories zu verwalten, wenn Du dies nicht kannst. Als Nachfolger wird dieser Benutzer folgende Berechtigungen haben:
- Deine öffentlichen Repositorys zu archivieren.
- Deine öffentlichen Repositorys zu seinem eigenen Benutzerkonto zu übertragen.
- Deine öffentlichen Repositorys zu einer Organisation zu übertragen, in denen er Repositorys erstellen kann.
Nachfolger können sich nicht an Deinem Konto anmelden.
Ein ernannter Nachfolger kann Deine öffentlichen Repositories verwalten, wenn er eine Sterbeurkunde vorgelegt hat und dann 7 Tage wartet, oder wenn er einen Nachruf vorgelegt hat und dann 21 Tage wartet. For more information, see "[{% data variables.product.company_short %} Deceased User Policy](/free-pro-team@latest/github/site-policy/github-deceased-user-policy)."
Um den Zugriff zur Verwaltung von Repositorys als Nachfolger zu beantragen, kontaktiere [GitHub-Support](https://support.github.com/contact?tags=docs-accounts).
## Einen Nachfolger einladen
Die Person, die Du als Deinen Nachfolger einlädst, muss ein {% data variables.product.company_short %}-Konto haben.
{% data reusables.user_settings.access_settings %}
{% data reusables.user_settings.account_settings %}
3. Um einen Nachfolger einzuladen, fange unter „Successor settings" (Nachfolger-Einstellungen) an, den Benutzernamen, den vollen Namen oder die E-Mail-Adresse einzugeben, und klicke dann auf den Namen, wenn er erscheint. ![Suchfeld „Successor invitation" (Nachfolger-Einladung)](/assets/images/help/settings/settings-invite-successor-search-field.png)
4. Klicke auf **Add successor** (Nachfolger hinzufügen).
{% data reusables.user_settings.sudo-mode-popup %}
5. Der Benutzer, den du eingeladen hast, wird als "Ausstehend" aufgelistet, bis er zustimmt, dein Nachfolger zu werden. ![Ausstehende Nachfolger-Einladung](/assets/images/help/settings/settings-pending-successor.png)

View File

@@ -1,44 +0,0 @@
---
title: Mitarbeiter aus einem persönlichen Repository entfernen
intro: 'Wenn Du einen Mitarbeiter aus Deinem Projekt entfernst, verliert er seinen Lese-/Schreibzugriff auf Dein Repository. Falls das Repository privat ist und die Person einen Fork erstellt hat, wird der Fork ebenfalls gelöscht.'
redirect_from:
- /articles/how-do-i-remove-a-collaborator/
- /articles/what-happens-when-i-remove-a-collaborator-from-my-private-repository/
- /articles/removing-a-collaborator-from-a-private-repository/
- /articles/deleting-a-private-fork-of-a-private-user-repository/
- /articles/how-do-i-delete-a-fork-of-my-private-repository/
- /articles/removing-a-collaborator-from-a-personal-repository
- /github/setting-up-and-managing-your-github-user-account/removing-a-collaborator-from-a-personal-repository
- /github/setting-up-and-managing-your-github-user-account/managing-access-to-your-personal-repositories/removing-a-collaborator-from-a-personal-repository
product: '{% data reusables.gated-features.user-repo-collaborators %}'
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Accounts
- Repositories
shortTitle: Remove a collaborator
---
## Forks privater Repositorys löschen
Beim Entfernen eines Mitarbeiters werden zwar dessen Forks privater Repositorys gelöscht, seine lokalen Klone Deiner Repositorys behält er aber.
## Mitarbeiterberechtigungen einer Person entfernen, die zu einem Repository beiträgt
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-settings %}
{% ifversion fpt or ghec %}
{% data reusables.repositories.navigate-to-manage-access %}
4. Klicke rechts neben dem Mitarbeiter, den Du entfernen möchtest, auf {% octicon "trash" aria-label="The trash icon" %}. ![Schaltfläche „Remove collaborator" (Entfernen des Mitarbeiters)](/assets/images/help/repository/collaborator-remove.png)
{% else %}
3. Klicke auf der linken Seitenleiste auf **Collaborators & teams** (Mitarbeiter und Teams). ![Registerkarte „Collaborators" (Mitarbeiter)](/assets/images/help/repository/repo-settings-collaborators.png)
4. Klicke auf das **X** neben dem Mitarbeiter, den Du entfernen möchtest. ![Link „Remove“ (Entfernen)](/assets/images/help/organizations/Collaborator-Remove.png)
{% endif %}
## Weiterführende Informationen
- „[Organisationsmitglieder aus einem Team entfernen](/articles/removing-organization-members-from-a-team)“
- „[Externen Mitarbeiter von einem Organisations-Repository entfernen](/articles/removing-an-outside-collaborator-from-an-organization-repository)“

View File

@@ -1,27 +0,0 @@
---
title: Dich selbst aus dem Repository eines Mitarbeiters entfernen
intro: 'Wenn Du nicht mehr an einem fremden Repository mitarbeiten möchtest, kannst Du Dich daraus entfernen.'
redirect_from:
- /leave-a-collaborative-repo/
- /leave-a-repo/
- /articles/removing-yourself-from-a-collaborator-s-repo/
- /articles/removing-yourself-from-a-collaborator-s-repository
- /articles/removing-yourself-from-a-collaborators-repository
- /github/setting-up-and-managing-your-github-user-account/removing-yourself-from-a-collaborators-repository
- /github/setting-up-and-managing-your-github-user-account/managing-access-to-your-personal-repositories/removing-yourself-from-a-collaborators-repository
product: '{% data reusables.gated-features.user-repo-collaborators %}'
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Accounts
- Repositories
shortTitle: Remove yourself
---
{% data reusables.user_settings.access_settings %}
2. Klicke in der linken Seitenleiste auf **Repositories** (Repositorys). ![Registerkarte „Repositories“ (Repositorys)](/assets/images/help/settings/settings-sidebar-repositories.png)
3. Klicke neben dem Repository, das Du verlassen möchtest, auf **Leave** (Verlassen). ![Schaltfläche „Leave“ (Verlassen)](/assets/images/help/repository/repo-leave.png)
4. Lies die Warnung gut durch, und klicke dann auf „I understand, leave this repository“ (Ich habe verstanden und möchte das Repository verlassen). ![Dialogfeld zur Bestätigung des Verlassens](/assets/images/help/repository/repo-leave-confirmation.png)

View File

@@ -1,37 +0,0 @@
---
title: Eine E-Mail-Adresse zu Deinem GitHub-Konto hinzufügen
intro: 'Bei {% data variables.product.product_name %} können Sie so viele E-Mail-Adressen zu Ihrem Konto hinzufügen, wie Sie möchten. Wenn Du eine E-Mail-Adresse in der lokalen Git-Konfiguration festlegst, musst Du diese Adresse zu Deinen Kontoeinstellungen hinzufügen, um Deine Commits mit Deinem Konto zu verbinden. Weitere Informationen zu E-Mail-Adressen und Commits findest Du unter „[Deine Commit-E-Mail-Adresse festlegen](/articles/setting-your-commit-email-address/).“'
redirect_from:
- /articles/adding-an-email-address-to-your-github-account
- /github/setting-up-and-managing-your-github-user-account/adding-an-email-address-to-your-github-account
- /github/setting-up-and-managing-your-github-user-account/managing-email-preferences/adding-an-email-address-to-your-github-account
versions:
fpt: '*'
ghes: '*'
ghec: '*'
topics:
- Accounts
- Notifications
shortTitle: Add an email address
---
{% ifversion fpt or ghec %}
{% note %}
**Hinweise**:
- {% data reusables.user_settings.no-verification-disposable-emails %}
- If you're a member of an {% data variables.product.prodname_emu_enterprise %}, you cannot make changes to your email address on {% data variables.product.prodname_dotcom_the_website %}. {% data reusables.enterprise-accounts.emu-more-info-account %}
{% endnote %}
{% endif %}
{% data reusables.user_settings.access_settings %}
{% data reusables.user_settings.emails %}
{% data reusables.user_settings.add_and_verify_email %}
{% data reusables.user_settings.select_primary_email %}
## Weiterführende Informationen
- „[E-Mail-Voreinstellungen verwalten](/articles/managing-email-preferences/)“

View File

@@ -1,28 +0,0 @@
---
title: 'Pushes über die Befehlszeile blockieren, die Deine private E-Mail-Adresse offenlegen'
intro: 'Wenn Du festgelegt hast, dass Deine E-Mail-Adresse beim Durchführen webbasierter Vorgänge nicht offengelegt wird, kannst Du auch Pushes über die Befehlszeile blockieren, die Deine private E-Mail-Adresse offenlegen könnten.'
redirect_from:
- /articles/blocking-command-line-pushes-that-expose-your-personal-email-address
- /github/setting-up-and-managing-your-github-user-account/blocking-command-line-pushes-that-expose-your-personal-email-address
- /github/setting-up-and-managing-your-github-user-account/managing-email-preferences/blocking-command-line-pushes-that-expose-your-personal-email-address
versions:
fpt: '*'
ghec: '*'
topics:
- Accounts
- Notifications
shortTitle: Block push with personal email
---
Wenn Du Commits über die Befehlszeile freigibst, wird die E-Mail-Adresse, die Du [in Git festgelegt](/articles/setting-your-commit-email-address) hast, mit Deinen Commits verknüpft. If you enable this setting, each time you push to GitHub, well check the most recent commit. If the author email on that commit is a private email on your GitHub account, we will block the push and warn you about exposing your private email.
{% data reusables.user_settings.about-commit-email-addresses %}
{% data reusables.user_settings.access_settings %}
{% data reusables.user_settings.emails %}
{% data reusables.user_settings.keeping_your_email_address_private %}
4. Um eine Offenlegung Deiner E-Mail-Adresse bei Commits, die Du über die Befehlszeile freigibst, zu verhindern, wähle **Block command line pushes that expose my email** (Pushes über die Befehlszeile blockieren, die meine E-Mail-Adresse offenlegen) aus. ![Option zum Blockieren von Befehlszeilen-Pushes, die E-Mail-Adressen offenlegen](/assets/images/help/settings/email_privacy_block_command_line_pushes.png)
## Weiterführende Informationen
- „[Commit-E-Mail-Adresse festlegen](/articles/setting-your-commit-email-address)“

View File

@@ -1,31 +0,0 @@
---
title: Deine primäre E-Mail-Adresse ändern
intro: Du kannst die mit Deinem Benutzerkonto verknüpfte E-Mail-Adresse jederzeit ändern.
redirect_from:
- /articles/changing-your-primary-email-address
- /github/setting-up-and-managing-your-github-user-account/changing-your-primary-email-address
- /github/setting-up-and-managing-your-github-user-account/managing-email-preferences/changing-your-primary-email-address
versions:
fpt: '*'
ghes: '*'
ghec: '*'
topics:
- Accounts
- Notifications
shortTitle: Primary email address
---
{% note %}
**Note:** You cannot change your primary email address to an email that is already set to be your backup email address.
{% endnote %}
{% data reusables.user_settings.access_settings %}
{% data reusables.user_settings.emails %}
3. Wenn Du eine neue E-Mail-Adresse hinzufügen und als primäre E-Mail-Adresse festlegen möchtest, gib unter „Add email address“ (E-Mail-Adresse hinzufügen) eine neue E-Mail-Adresse ein. Klicke dann auf **Add** (Hinzufügen). ![Schaltfläche zum Hinzufügen einer anderen E-Mail-Adresse](/assets/images/help/settings/add_another_email_address.png)
4. Klicke im Dropdownmenü unter „Primary email address“ (Primäre E-Mail-Adresse) auf die E-Mail-Adresse, die Du als primäre E-Mail-Adresse festlegen möchtest, und klicke dann auf **Save** (Speichern). ![Schaltfläche zum Festlegen als primäre Adresse](/assets/images/help/settings/set_as_primary_email.png)
5. Um die alte E-Mail-Adresse aus Ihrem Konto zu entfernen, klicken Sie neben der alten E-Mail-Adresse auf {% octicon "trash" aria-label="The trash symbol" %}.
{% ifversion fpt or ghec %}
6. Verifiziere Deine neue primäre E-Mail-Adresse. Ohne verifizierte E-Mail-Adresse kannst Du nicht alle Funktionen von {% data variables.product.product_name %} nutzen. Weitere Informationen findest Du unter „[Eigene E-Mail-Adresse verifizieren](/articles/verifying-your-email-address).“
{% endif %}

View File

@@ -1,27 +0,0 @@
---
title: E-Mail-Voreinstellungen verwalten
intro: 'You can add or change the email addresses associated with your account on {% ifversion ghae %}{% data variables.product.product_name %}{% else %}{% data variables.product.product_location %}{% endif %}. Sie können auch E-Mails verwalten, die Sie von {% data variables.product.product_name %} erhalten.'
redirect_from:
- /categories/managing-email-preferences/
- /articles/managing-email-preferences
- /github/setting-up-and-managing-your-github-user-account/managing-email-preferences
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Accounts
- Notifications
children:
- /adding-an-email-address-to-your-github-account
- /changing-your-primary-email-address
- /setting-a-backup-email-address
- /setting-your-commit-email-address
- /blocking-command-line-pushes-that-expose-your-personal-email-address
- /remembering-your-github-username-or-email
- /types-of-emails-github-sends
- /managing-marketing-emails-from-github
shortTitle: Manage email preferences
---

View File

@@ -1,33 +0,0 @@
---
title: Marketing-E-Mails von GitHub verwalten
intro: 'Neben Benachrichtigungen und Konto-E-Mails versendet {% data variables.product.prodname_dotcom %} gelegentlich auch Marketing-E-Mails mit Neuigkeiten und Informationen zu unseren Produkten. Wenn Sie die Marketing-E-Mails kündigen, sind Sie von zukünftigen Kampagnen ausgeschlossen, sofern Sie Ihre {% data variables.product.prodname_dotcom %}-E-Mail-Einstellungen nicht entsprechend ändern.'
redirect_from:
- /articles/managing-marketing-emails-from-github
- /github/setting-up-and-managing-your-github-user-account/managing-marketing-emails-from-github
- /github/setting-up-and-managing-your-github-user-account/managing-email-preferences/managing-marketing-emails-from-github
versions:
fpt: '*'
ghec: '*'
topics:
- Accounts
- Notifications
shortTitle: Marketing-E-Mails
---
## Marketing-E-Mails von {% data variables.product.prodname_dotcom %} kündigen
{% tip %}
**Tipp:** Wenn Du alle Marketing-E-Mails kündigst und anschließend den Explore-Newsletter abonnierst, erhältst Du nur den Explore-Newsletter und keine zusätzlichen Marketing-E-Mails.
{% endtip %}
{% data reusables.user_settings.access_settings %}
{% data reusables.user_settings.emails %}
3. Wähle unter *Email preferences* (E-Mail-Voreinstellungen) **Only receive account related emails, and those I subscribe to** (Nur kontobezogene und abonnierte E-Mails erhalten) aus. ![Screenshot vom Abwählen der Marketing-E-Mails](/assets/images/help/notifications/email_preferences.png)
4. Klicke auf **Save email preferences** (E-Mail-Voreinstellungen speichern). ![Schaltfläche „Save email preferences“ (E-Mail-Voreinstellungen speichern)](/assets/images/help/notifications/save_email_preferences.png)
## Weiterführende Informationen
- „[Arten der von GitHub versendeten E-Mails](/articles/types-of-emails-github-sends)“
- „[Benachrichtigungen konfigurieren](/github/managing-subscriptions-and-notifications-on-github/configuring-notifications)"

View File

@@ -1,76 +0,0 @@
---
title: Erinnerung für Deinen GitHub-Benutzernamen oder Deine GitHub-E-Mail-Adresse
intro: 'Meldest Du Dich seit langem einmal wieder bei {% data variables.product.product_location %} an? Herzlich willkommen! Wenn Sie sich nicht mehr an den Namen Ihres {% data variables.product.product_name %}-Benutzerkontos erinnern können, versuchen Sie ihn mit den folgenden Methoden zu finden.'
redirect_from:
- /articles/oh-noes-i-ve-forgotten-my-username-email/
- /articles/oh-noes-i-ve-forgotten-my-username-or-email/
- /articles/remembering-your-github-username-or-email
- /github/setting-up-and-managing-your-github-user-account/remembering-your-github-username-or-email
- /github/setting-up-and-managing-your-github-user-account/managing-email-preferences/remembering-your-github-username-or-email
versions:
fpt: '*'
ghes: '*'
ghec: '*'
topics:
- Accounts
- Notifications
shortTitle: Find your username or email
---
{% mac %}
## {% data variables.product.prodname_desktop %}-Benutzer
1. Klicke im **GitHub Desktop**-Menü auf **Preferences** (Einstellungen).
2. Überprüfe im Einstellungsfenster Folgendes:
- Klicke auf **Accounts** (Konten), um Deinen {% data variables.product.product_name %}-Benutzernamen anzuzeigen.
- Klicke auf **Git**, um Deine Git-E-Mail-Adresse anzuzeigen. Eventuell ist diese Adresse jedoch nicht Ihre [primäre {% data variables.product.product_name %}-E-Mail-Adresse](/articles/changing-your-primary-email-address).
{% endmac %}
{% windows %}
## {% data variables.product.prodname_desktop %}-Benutzer
1. Klicke im Menü **File** (Datei) auf **Options** (Optionen).
2. Überprüfe im Optionsfenster Folgendes:
- Klicke auf **Accounts** (Konten), um Deinen {% data variables.product.product_name %}-Benutzernamen anzuzeigen.
- Klicke auf **Git**, um Deine Git-E-Mail-Adresse anzuzeigen. Eventuell ist diese Adresse jedoch nicht Ihre [primäre {% data variables.product.product_name %}-E-Mail-Adresse](/articles/changing-your-primary-email-address).
{% endwindows %}
## Eigenen Benutzernamen in Deiner `user.name`-Konfiguration finden
Bei der Einrichtung hast Du vermutlich [Deinen Benutzernamen in Git festgelegt](/github/getting-started-with-github/setting-your-username-in-git). Wenn dies der Fall ist, kannst Du den Wert dieser Konfigurationseinstellung wie folgt abrufen:
```shell
$ git config user.name
# Zeigt die Einstellung an
<em>YOUR_USERNAME</em>
```
## Eigenen Benutzernamen in der URL von Remote-Repositorys finden
Wenn Dir lokale Kopien persönlicher Repositorys vorliegen, die Du erstellt oder geforkt hast, kannst Du die URL des Remote-Repositorys überprüfen.
{% tip %}
**Tipp**: Diese Methode funktioniert nur, wenn Dir das Originalrepository oder Dein eigener Fork eines fremden Repositorys vorliegt. Wenn Du das Repository einer anderen Person geklont hast, wird deren Benutzername statt Deinem angezeigt. Ebenso wird bei Organisationsrepositorys in der Remote-URL statt eines bestimmten Benutzers der Name der Organisation angezeigt.
{% endtip %}
```shell
$ cd <em>YOUR_REPOSITORY</em>
# Wechselt das Verzeichnis zum initialisierten Git-Repository
$ git remote -v
origin https://{% data variables.command_line.codeblock %}/<em>YOUR_USERNAME</em>/<em>YOUR_REPOSITORY</em>.git (fetch)
origin https://{% data variables.command_line.codeblock %}/<em>YOUR_USERNAME</em>/<em>YOUR_REPOSITORY</em>.git (push)
```
Ihr Benutzername folgt unmittelbar auf `https://{% data variables.command_line.backticks %}/`.
{% ifversion fpt or ghec %}
## Weiterführende Informationen
- „[Eigene E-Mail-Adresse überprüfen](/articles/verifying-your-email-address)“
{% endif %}

View File

@@ -1,27 +0,0 @@
---
title: Backup-E-Mail-Adresse festlegen
intro: 'Use a backup email address as an additional destination for security-relevant account notifications{% ifversion not ghae %} and to securely reset your password if you can no longer access your primary email address{% endif %}.'
redirect_from:
- /articles/setting-a-backup-email-address
- /github/setting-up-and-managing-your-github-user-account/setting-a-backup-email-address
- /github/setting-up-and-managing-your-github-user-account/managing-email-preferences/setting-a-backup-email-address
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Accounts
- Notifications
shortTitle: Set backup email address
---
{% data reusables.user_settings.access_settings %}
{% data reusables.user_settings.emails %}
3. Wähle im Dropdownmenü unter „Backup email address“ (Backup-E-Mail-Adresse) die E-Mail-Adresse aus, die Du als Backup-E-Mail-Adresse festlegen möchtest. ![Backup-E-Mail-Adresse](/assets/images/help/settings/backup-email-address.png)
4. Klicke auf **Save** (Speichern).
## Weiterführende Informationen
- „[E-Mail-Voreinstellungen verwalten](/articles/managing-email-preferences/)“
- „[Anmeldeinformationen für den Zugriff auf GitHub aktualisieren](/articles/updating-your-github-access-credentials/)“

View File

@@ -1,105 +0,0 @@
---
title: E-Mail-Adresse für Commits festlegen
intro: 'You can set the email address that is used to author commits on {% data variables.product.product_location %} and on your computer.'
redirect_from:
- /articles/keeping-your-email-address-private/
- /articles/setting-your-commit-email-address-on-github/
- /articles/about-commit-email-addresses/
- /articles/git-email-settings/
- /articles/setting-your-email-in-git/
- /articles/set-your-user-name-email-and-github-token/
- /articles/setting-your-commit-email-address-in-git/
- /articles/setting-your-commit-email-address
- /github/setting-up-and-managing-your-github-user-account/setting-your-commit-email-address
- /github/setting-up-and-managing-your-github-user-account/managing-email-preferences/setting-your-commit-email-address
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Accounts
- Notifications
shortTitle: Set commit email address
---
## Informationen zu E-Mail-Adressen für Commits
{% data variables.product.prodname_dotcom %} uses your commit email address to associate commits with your account on {% data variables.product.product_location %}. Du kannst den Commits, die Du über die Befehlszeile überträgst, wie auch Deinen webbasierten Git-Operationen jeweils eine eigene E-Mail-Adresse zuordnen.
For web-based Git operations, you can set your commit email address on {% ifversion ghae %}{% data variables.product.product_name %}{% else %}{% data variables.product.product_location %}{% endif %}. Für Commits, die Du per Push über die Befehlszeile überträgst, legst Du die E-Mail-Adresse für Commits in Git fest.
{% ifversion fpt or ghec %}Alle Commits, die Sie vor der Änderung Ihrer E-Mail-Adresse für Commits durchgeführt haben, bleiben mit Ihrer früheren E-Mail-Adresse verbunden.{% else %}Nach der Änderung Ihrer E-Mail-Adresse für Commits auf {% data variables.product.product_name %} wird die neue E-Mail-Adresse standardmäßig allen zukünftigen webbasierten Git-Operationen zugeordnet. Alle Commits, die Du vor der Änderung Deiner Commit-E-Mail-Adresse durchgeführt hast, bleiben mit Deiner früheren E-Mail-Adresse verbunden.{% endif %}
{% ifversion fpt or ghec %}
{% note %}
**Hinweis:** {% data reusables.user_settings.no-verification-disposable-emails %}
{% endnote %}
{% endif %}
{% ifversion fpt or ghec %}If you'd like to keep your personal email address private, you can use a `no-reply` email address from {% data variables.product.product_name %} as your commit email address. Wenn Du eine `no-reply`-E-Mail-Adresse für Commits verwenden möchtest, die Du über die Befehlszeile überträgst, gib diese E-Mail-Adresse bei der Festlegung Deiner Commit-E-Mail-Adresse in Git an. Wenn Du eine `no-reply`-E-Mail-Adresse für webbasierte Git-Operationen verwenden möchtest, lege Deine Commit-E-Mail-Adresse auf GitHub fest, und wähle dabei **Keep my email address private** (E-Mail-Adresse privat halten) aus.
Du kannst auch festlegen, dass Commits, die Du über die Befehlszeile überträgst, blockiert werden, wenn diese Deine persönliche E-Mail-Adresse offenlegen. Weitere Informationen findest Du unter „[Pushes über die Befehlszeile blockieren, die Deine private E-Mail-Adresse offenlegen](/articles/blocking-command-line-pushes-that-expose-your-personal-email-address)“.{% endif %}
To ensure that commits are attributed to you and appear in your contributions graph, use an email address that is connected to your account on {% data variables.product.product_location %}{% ifversion fpt or ghec %}, or the `noreply` email address provided to you in your email settings{% endif %}. {% ifversion not ghae %}For more information, see "[Adding an email address to your {% data variables.product.prodname_dotcom %} account](/github/setting-up-and-managing-your-github-user-account/adding-an-email-address-to-your-github-account)."{% endif %}
{% ifversion fpt or ghec %}
{% note %}
**Note:** If you created your account on {% data variables.product.product_location %} _after_ July 18, 2017, your `no-reply` email address for {% data variables.product.product_name %} is a seven-digit ID number and your username in the form of <code><em>ID+username</em>@users.noreply.github.com</code>. If you created your account on {% data variables.product.product_location %} _prior to_ July 18, 2017, your `no-reply` email address from {% data variables.product.product_name %} is <code><em>username</em>@users.noreply.github.com</code>. You can get an ID-based `no-reply` email address for {% data variables.product.product_name %} by selecting (or deselecting and reselecting) **Keep my email address private** in your email settings.
{% endnote %}
If you use your `noreply` email address for {% data variables.product.product_name %} to make commits and then [change your username](/articles/changing-your-github-username), those commits will not be associated with your account on {% data variables.product.product_location %}. This does not apply if you're using the ID-based `noreply` address from {% data variables.product.product_name %}. Weitere Informationen findest Du unter „[{% data variables.product.prodname_dotcom %}-Benutzernamen ändern](/articles/changing-your-github-username)“.{% endif %}
## Deine Commit-E-Mail-Adresse auf {% data variables.product.prodname_dotcom %} festlegen
{% data reusables.files.commit-author-email-options %}
{% data reusables.user_settings.access_settings %}
{% data reusables.user_settings.emails %}
{% data reusables.user_settings.add_and_verify_email %}
{% data reusables.user_settings.select_primary_email %}{% ifversion fpt or ghec %}
{% data reusables.user_settings.keeping_your_email_address_private %}{% endif %}
## Deine Commit-E-Mail-Adresse in Git festlegen
Mit dem Befehl `git config` können Sie die Ihren Git-Commits zugeordnete E-Mail-Adresse ändern. Die neue E-Mail-Adresse wird bei allen zukünftigen Commits angezeigt, die Sie über die Befehlszeile per Push an {% data variables.product.product_location %} übertragen. Alle Commits, die Sie vor der Änderung Ihrer E-Mail-Adresse für Commits durchgeführt haben, bleiben mit Ihrer früheren E-Mail-Adresse verbunden.
### E-Mail-Adresse für alle Repositorys auf Deinem Computer festlegen
{% data reusables.command_line.open_the_multi_os_terminal %}
2. {% data reusables.user_settings.set_your_email_address_in_git %}
```shell
$ git config --global user.email "<em>email@example.com</em>"
```
3. {% data reusables.user_settings.confirm_git_email_address_correct %}
```shell
$ git config --global user.email
<span class="output">email@example.com</span>
```
4. {% data reusables.user_settings.link_email_with_your_account %}
### E-Mail-Adresse für ein einzelnes Repository festlegen
{% data variables.product.product_name %} uses the email address set in your local Git configuration to associate commits pushed from the command line with your account on {% data variables.product.product_location %}.
Sie können die E-Mail-Adresse für Ihre Commits an einem bestimmten Repository ändern. Dadurch werden Ihre globalen Git-Konfigurationseinstellungen ausschließlich für dieses eine Repository überschrieben, d. h., die anderen Repositorys sind von dieser Änderung nicht betroffen.
{% data reusables.command_line.open_the_multi_os_terminal %}
2. Ändere das aktuelle Arbeitsverzeichnis in das lokale Repository, für das Du die E-Mail-Adresse für Deine Git-Commits festlegen möchten.
3. {% data reusables.user_settings.set_your_email_address_in_git %}
```shell
$ git config user.email "<em>email@example.com</em>"
```
4. {% data reusables.user_settings.confirm_git_email_address_correct %}
```shell
$ git config user.email
<span class="output">email@example.com</span>
```
5. {% data reusables.user_settings.link_email_with_your_account %}

View File

@@ -1,54 +0,0 @@
---
title: Arten der von GitHub versendeten E-Mails
intro: 'There are several types of emails you can receive from {% data variables.product.product_name %}, including notifications, account information, customer research invitations, and marketing communications.'
redirect_from:
- /articles/types-of-emails-github-sends
- /github/setting-up-and-managing-your-github-user-account/types-of-emails-github-sends
- /github/setting-up-and-managing-your-github-user-account/managing-email-preferences/types-of-emails-github-sends
versions:
fpt: '*'
ghec: '*'
topics:
- Accounts
- Notifications
shortTitle: Emails from GitHub
---
## Benachrichtigungs-E-Mails
Du kannst festlegen, ob und welche Aktivitätsbenachrichtigungen Du via E-Mail erhalten willst. Weitere Informationen findest Du unter „[Über Benachrichtigungen](/github/managing-subscriptions-and-notifications-on-github/about-notifications)." Benachrichtigungs-E-Mails können folgendes beinhalten:
- Sicherheitsrelevante Aktivitäten an Repositorys, auf die Du Administratorzugriff hast
- Aktivitäten in von Dir beobachteten Repositorys
- Unterhaltungen, an denen Du teilnimmst
- Unterhaltungen, in denen Du @erwähnt wurdest
- Pushes an Pull Requests, an denen Du mitwirkst
- Einladungen zur Mitarbeit in einer Organisation oder an einem Repository
- Deine eigenen Aktivitäten, beispielsweise das Öffnen, Kommentieren oder Schließen von Issues und Pull Requests
Auch kannst Du die Art der E-Mail-Aktualisierungen festlegen, die Du zu Unterhaltungen erhältst, die Du beobachtest oder an denen Du teilnimmst. Weitere Informationen findest Du unter „[Benachrichtigungen konfigurieren](/github/managing-subscriptions-and-notifications-on-github/configuring-notifications)."
## E-Mails mit Kontoinformationen
Falls Du ein Upgrade auf bezahlte Produkte oder Funktionen durchgeführt hast, erhältst Du an die primäre E-Mail-Adresse Deines Kontos Abrechnungsquittungen. Weitere Informationen findest Du unter „[E-Mail-Adresse für die Abrechnung festlegen](/articles/setting-your-billing-email).“
## Customer research emails
{% data variables.product.product_name %} occasionally seeks customers to participate in research sessions to help us build a better GitHub. These are conducted remotely, open to customers worldwide, and may include:
- Feedback surveys
- Research interviews
- Usability testing sessions
- Previewing early prototypes or concepts
These emails are infrequent and you can choose whether or not to participate. If you're interested in additional opportunities to participate in research sessions, you may add yourself to the GitHub Customer Research Panel. For more information, see "[GitHub Customer Experience Research](https://cxr.github.com)."
## Marketing-E-Mails
{% data variables.product.product_name %} versendet gelegentlich auch E-Mails mit folgenden Arten von Marketingkommunikation:
- Tipps und Tricks für die ersten Schritte mit Deinem Konto
- Persönlich abgestimmte Informationen zu interessanten neuen Projekten oder Funktionen
- Abonnierte Newsletter wie {% data variables.explore.explore_github %}
Weitere Informationen findest Du unter „[Marketing-E-Mails von GitHub verwalten](/articles/managing-marketing-emails-from-github).“

View File

@@ -1,63 +0,0 @@
---
title: Informationen zum persönlichen Dashboard
redirect_from:
- /hidden/about-improved-navigation-to-commonly-accessed-pages-on-github/
- /articles/opting-into-the-public-beta-for-a-new-dashboard/
- /articles/about-your-personal-dashboard
- /github/setting-up-and-managing-your-github-user-account/about-your-personal-dashboard
- /github/setting-up-and-managing-your-github-user-account/managing-user-account-settings/about-your-personal-dashboard
intro: 'Über Dein persönliches Dashboard kannst Du über Issues und Pull Requests, die Du bearbeitest oder verfolgst, auf dem Laufenden bleiben, zu Deinen wichtigsten Repositorys und Teamseiten navigieren, Dich über die neuesten Aktivitäten in Organisationen und Repositorys informieren, die Du abonniert hast, und empfohlene Repositorys erkunden.'
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Accounts
shortTitle: Your personal dashboard
---
## Auf Dein persönliches Dashboard zugreifen
Ihr persönliches Dashboard ist die erste Seite, die Sie sehen, wenn Sie sich bei {% data variables.product.product_name %} anmelden.
Um nach der Anmeldung auf Ihr persönliches Dashboard zuzugreifen, klicken Sie auf das {% octicon "mark-github" aria-label="The github octocat logo" %} in der oberen linken Ecke einer beliebigen Seite auf {% data variables.product.product_name %}.
## Neueste Aktivitäten finden
Im Abschnitt „Recent activity" (Neueste Aktivitäten) Deines Newsfeed kannst Du schnell die zuletzt aktualisierten Issues und Pull Requests finden und weiterverfolgen, an denen Du arbeitest. Im Abschnitt „Recent activity" (Neueste Aktivitäten) kannst Du bis zu 12 der letzten Aktualisierungen anzeigen, die in den vergangenen 2 Wochen gemacht wurden.
{% data reusables.dashboard.recent-activity-qualifying-events %}
## Deine wichtigsten Repositorys und Teams finden
Über die linke Seitenleiste Deines Dashboards kannst Du auf die wichtigsten Repositorys und Teams zugreifen, die Du verwendest.
![Liste mit Repositorys und Teams verschiedener Organisationen](/assets/images/help/dashboard/repositories-and-teams-from-personal-dashboard.png)
The list of top repositories is automatically generated, and can include any repository you have interacted with, whether it's owned directly by your account or not. Interactions include making commits and opening or commenting on issues and pull requests. The list of top repositories cannot be edited, but repositories will drop off the list 4 months after you last interacted with them.
Wenn Du oben auf einer beliebigen Seite auf {% data variables.product.product_name %} in die Suchleiste klickst, findest Du außerdem eine Liste Deiner zuletzt aufgerufenen Repositorys, Teams und Projektboards.
## Über Aktivitäten in der Community auf dem Laufenden bleiben
Im Abschnitt „All activity" (Alle Aktivitäten) in Deinem Newsfeed kannst Du Aktualisierungen von Repositorys sehen, die Du abonniert hast und von Personen, denen Du folgst. Der Abschnitt „All activity" (Alle Aktivitäten) zeigt Aktualisierungen von Repositorys, die Du beobachtest oder mit Stern versehen hast und von Benutzern, denen Du folgst.
In Ihrem News-Feed werden Aktualisierungen angezeigt, wenn ein Benutzer, dem Sie folgen,
- Ein Repository mit einem Stern versieht.
- Follows another user.{% ifversion fpt or ghes or ghec %}
- Creates a public repository.{% endif %}
- Einen Issue oder Pull Request mit der Kennzeichnung „help wanted“ oder „good first issue“ in einem von Dir beobachteten Repository öffnet.
- Pushes commits to a repository you watch.{% ifversion fpt or ghes or ghec %}
- Forks a public repository.{% endif %}
- Publishes a new release.
Weitere Informationen zu Sternen für Repositorys und zum Folgen von Personen finden Sie unter „[Repositorys mit Sternen speichern ](/articles/saving-repositories-with-stars/)“ und „[Jemandem folgen](/articles/following-people)“.
## Empfohlene Repositorys erkunden
Im Abschnitt "Explore repositories" (Repositories erkunden) auf der rechten Seite Deines Dashboards kannst Du empfohlene Repositorys in Deinen Communities erkunden. Empfehlungen basieren auf den von Dir markierten oder besuchten Repositorys, auf den Personen, denen Du folgst und auf den Aktivitäten innerhalb der Repositorys, auf die Du Zugriff hast.{% ifversion fpt or ghec %} Weitere Informationen findest Du unter „[Möglichkeiten zum Beitragen an Open Source auf {% data variables.product.prodname_dotcom %} finden](/github/getting-started-with-github/finding-ways-to-contribute-to-open-source-on-github)."{% endif %}
## Weiterführende Informationen
- „[Informationen zum Dashboard Deiner Organisation](/articles/about-your-organization-dashboard)“

View File

@@ -1,40 +0,0 @@
---
title: Best Practices beim Verlassen Deines Unternehmens
intro: 'Ein Wechsel der Arbeitsstelle gehört zum Leben. Wenn Du Dein GitHub-Benutzerkonto für private *und* berufliche Zwecke nutzt, musst Du ein paar Dinge beachten, wenn Du Dein Unternehmen verlässt.'
redirect_from:
- /articles/best-practices-for-leaving-your-company
- /github/setting-up-and-managing-your-github-user-account/best-practices-for-leaving-your-company
- /github/setting-up-and-managing-your-github-user-account/managing-user-account-settings/best-practices-for-leaving-your-company
versions:
fpt: '*'
ghec: '*'
topics:
- Accounts
shortTitle: Leaving your company
---
Bevor Du Dein Unternehmen verlässt, stelle sicher, dass Du die folgenden Angaben in Deinem Benutzerkonto aktualisierst:
- Widerrufe die Verifizierung Deiner beruflichen E-Mail-Adresse, indem Du [sie in den E-Mail-Einstellungen löschst](/articles/changing-your-primary-email-address). Du kannst die Adresse dann ohne erneute Verifizierung wieder hinzufügen, damit zugehörige Commits mit Deinem Konto verknüpft bleiben.
- [Ändere die primäre E-Mail-Adresse](/articles/changing-your-primary-email-address) von der beruflichen in Deine private E-Mail-Adresse um.
{% ifversion fpt or ghec %}
- [Verifiziere die neue primäre E-Mail-Adresse](/articles/verifying-your-email-address).
{% endif %}
- [Ändere Deinen GitHub-Benutzernamen](/articles/changing-your-github-username), um alle Verweise auf Dein Unternehmen oder Deine Organisation zu entfernen, falls erforderlich.
## Unternehmen verlassen
Wenn Du mit Repositorys gearbeitet hast, die einer Organisation gehören, [entfernen Dich selbst als Mitglied der Organisation](/articles/removing-yourself-from-an-organization). Beachte: Wenn Du der Organisationsinhaber bist, solltest Du zunächst [die Inhaberschaft der Organisation an eine andere Person übertragen](/articles/transferring-organization-ownership).
## Berufliche Verknüpfungen aus persönlichen Repositorys entfernen
Wenn Du beruflich mit einer anderen Person an Repositorys zusammengearbeitet hast, die zum persönlichen Benutzerkonto dieser Person gehören, [entferne Dich selbst als Mitarbeiter](/articles/removing-yourself-from-a-collaborator-s-repository) von diesen Repositorys.
- [Beobachte keine Repositorys mehr](https://github.com/watching), die zu Deiner Arbeit gehören. Du brauchst diese Benachrichtigungen nicht mehr!
- [Übertrage Repositorys, deren Inhaber Du bist](/articles/how-to-transfer-a-repository) und die andere Personen möglicherweise noch bearbeiten müssen, nachdem Du das Unternehmen verlassen hast.
- [Lösche Forks, die Dir gehören](/articles/deleting-a-repository) und die mit Deiner Arbeit zusammenhängen. Sei unbesorgt beim Löschen eines Forks wird das vorgelagerte Repository nicht gelöscht.
- Lösche lokale Kopien Deiner Forks, sofern auf Deinem Computer vorhanden:
```shell
$ rm -rf <em>arbeitsverzeichnis</em>
```

View File

@@ -1,88 +0,0 @@
---
title: Deinen GitHub-Benutzernamen ändern
intro: 'You can change the username for your account on {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom_the_website %}{% elsif ghes %}{% data variables.product.product_location %} if your instance uses built-in authentication{% endif %}.'
redirect_from:
- /articles/how-to-change-your-username/
- /articles/changing-your-github-user-name/
- /articles/renaming-a-user/
- /articles/what-happens-when-i-change-my-username/
- /articles/changing-your-github-username
- /github/setting-up-and-managing-your-github-user-account/changing-your-github-username
- /github/setting-up-and-managing-your-github-user-account/managing-user-account-settings/changing-your-github-username
versions:
fpt: '*'
ghes: '*'
ghec: '*'
topics:
- Accounts
shortTitle: Change your username
---
{% ifversion ghec or ghes %}
{% note %}
{% ifversion ghec %}
**Note**: Members of an {% data variables.product.prodname_emu_enterprise %} cannot change usernames. Your enterprise's IdP administrator controls your username for {% data variables.product.product_name %}. For more information, see "[About {% data variables.product.prodname_emus %}](/admin/authentication/managing-your-enterprise-users-with-your-identity-provider/about-enterprise-managed-users)."
{% elsif ghes %}
**Note**: If you sign into {% data variables.product.product_location %} with LDAP credentials or single sign-on (SSO), only your local administrator can change your username. For more information about authentication methods for {% data variables.product.product_name %}, see "[Authenticating users for {% data variables.product.product_location %}](/admin/authentication/authenticating-users-for-your-github-enterprise-server-instance)."
{% endif %}
{% endnote %}
{% endif %}
## Informationen zu Änderungen des Benutzernamens
You can change your username to another username that is not currently in use.{% ifversion fpt or ghec %} If the username you want is not available, consider other names or unique variations. Using a number, hyphen, or an alternative spelling might help you find a similar username that's still available.
If you hold a trademark for the username, you can find more information about making a trademark complaint on our [Trademark Policy](/free-pro-team@latest/github/site-policy/github-trademark-policy) page.
If you do not hold a trademark for the name, you can choose another username or keep your current username. {% data variables.contact.github_support %} kann den für Sie nicht verfügbaren Benutzernamen nicht freigeben. Weitere Informationen findest Du unter „[Benutzernamen ändern](#changing-your-username)“.{% endif %}
Wenn Du Deinen Benutzernamen geändert hast, steht Dein alter Benutzername wieder der Allgemeinheit zur Verfügung. Die meisten Verweise auf Deine Repositorys unter dem alten Benutzernamen werden automatisch in den neuen Benutzernamen geändert. Einige Links auf Dein Profil werden jedoch nicht automatisch weitergeleitet.
Für Folgendes kann {% data variables.product.product_name %} keine Weiterleitungen einrichten:
- [@Erwähnungen](/articles/basic-writing-and-formatting-syntax/#mentioning-people-and-teams) des alten Benutzernamens
- Links zu [Gists](/articles/creating-gists), die Deinen alten Benutzernamen enthalten
{% ifversion fpt or ghec %}
If you're a member of an {% data variables.product.prodname_emu_enterprise %}, you cannot make changes to your username. {% data reusables.enterprise-accounts.emu-more-info-account %}
{% endif %}
## Repository-Verweise
Wenn Du Deinen Benutzernamen geändert hast, leitet {% data variables.product.product_name %} Verweise auf Deine Repositorys automatisch weiter.
- Weblinks zu Deinen vorhandenen Repositorys funktionieren auch weiterhin. Dieser Vorgang kann einige Minuten dauern, nachdem Du die Änderung vorgenommen hast.
- Befehlszeilen-Pushes von Deinen lokalen Repository-Klonen zu den alten Remote-Tracking-URLs funktionieren auch weiterhin.
Wenn der neue Inhaber Deines alten Benutzernamens ein Repository mit demselben Namen wie Dein Repository erstellt, wird der Weiterleitungseintrag überschrieben und Deine Weiterleitung wird nicht mehr funktionieren. Angesichts dieser Möglichkeit empfehlen wir Dir, alle vorhandenen Remote-Repository-URLs nach dem Ändern Deines Benutzernamens zu aktualisieren. For more information, see "[Managing remote repositories](/github/getting-started-with-github/managing-remote-repositories)."
## Links zu früheren Profilseiten
Nach dem Ändern Deines Benutzernamens lösen Links zu Deinen früheren Profilseiten, z. B. `https://{% data variables.command_line.backticks %}/previoususername`, eine 404-Fehlermeldung aus. We recommend updating any links to your account on {% data variables.product.product_location %} from elsewhere{% ifversion fpt or ghec %}, such as your LinkedIn or Twitter profile{% endif %}.
## Deine Git-Commits
{% ifversion fpt or ghec %}Git commits that were associated with your {% data variables.product.product_name %}-provided `noreply` email address won't be attributed to your new username and won't appear in your contributions graph.{% endif %} If your Git commits are associated with another email address you've [added to your GitHub account](/articles/adding-an-email-address-to-your-github-account), {% ifversion fpt or ghec %}including the ID-based {% data variables.product.product_name %}-provided `noreply` email address, {% endif %}they'll continue to be attributed to you and appear in your contributions graph after you've changed your username. Weitere Informationen zum Einrichten Deiner E-Mail-Adresse findest Du unter „[Commit-E-Mail-Adresse festlegen](/articles/setting-your-commit-email-address).“
## Deinen Benutzernamen ändern
{% data reusables.user_settings.access_settings %}
{% data reusables.user_settings.account_settings %}
3. Klicke im Abschnitt „Change username“ (Benutzername ändern) auf **Change username** (Benutzername ändern). ![Change Username button](/assets/images/help/settings/settings-change-username.png){% ifversion fpt or ghec %}
4. Lies die Warnungen in Bezug auf das Ändern Deines Benutzernamens. Falls Du Deinen Benutzernamen dennoch ändern möchtest, klicke auf **I understand, let's change my username** (Ich habe verstanden, meinen Benutzernamen ändern). ![Schaltfläche mit Warnung zur Änderung des Benutzernamens](/assets/images/help/settings/settings-change-username-warning-button.png)
5. Gib einen neuen Benutzernamen ein. ![Feld für neuen Benutzernamen](/assets/images/help/settings/settings-change-username-enter-new-username.png)
6. Falls der gewünschte Benutzername verfügbar ist, klicke auf **Change my username** (Meinen Benutzernamen ändern). Falls der gewünschte Benutzername nicht verfügbar ist, kannst Du versuchen, einen anderen Benutzernamen oder einen der angezeigten Vorschläge zu verwenden. ![Schaltfläche mit Warnung zur Änderung des Benutzernamens](/assets/images/help/settings/settings-change-my-username-button.png)
{% endif %}
## Weiterführende Informationen
- "[Why are my commits linked to the wrong user?](/articles/why-are-my-commits-linked-to-the-wrong-user)"{% ifversion fpt or ghec %}
- "[{% data variables.product.prodname_dotcom %} Username Policy](/free-pro-team@latest/github/site-policy/github-username-policy)"{% endif %}

View File

@@ -1,67 +0,0 @@
---
title: Benutzer in eine Organisation umwandeln
redirect_from:
- /articles/what-is-the-difference-between-create-new-organization-and-turn-account-into-an-organization/
- /articles/explaining-the-account-transformation-warning/
- /articles/converting-a-user-into-an-organization
- /github/setting-up-and-managing-your-github-user-account/converting-a-user-into-an-organization
- /github/setting-up-and-managing-your-github-user-account/managing-user-account-settings/converting-a-user-into-an-organization
intro: 'Du kannst Dein Benutzerkonto in eine Organisation umwandeln. Dadurch sind feiner abgestufte Berechtigungen für Repositorys möglich, die zu der Organisation gehören.'
versions:
fpt: '*'
ghes: '*'
ghec: '*'
topics:
- Accounts
shortTitle: User into an organization
---
{% warning %}
**Warnung:** Bevor Du einen Benutzer in eine Organisation umwandelst, beachte Folgendes:
- Du kannst Dich **nicht mehr** beim umgewandelten Benutzerkonto anmelden.
- Du kannst **keine** Gists mehr erstellen oder ändern, die zum umgewandelten Benutzerkonto gehören.
- Eine Organisation **kann nicht** zurück in einen Benutzer umgewandelt werden.
- The SSH keys, OAuth tokens, job profile, reactions, and associated user information, **will not** be transferred to the organization. Dies gilt nur für das Benutzerkonto, das umgewandelt wird, nicht für die Mitarbeiter des Benutzerkontos.
- Alle Commits, die mit dem umgewandelten Benutzerkonto vorgenommen wurden, **sind nicht mehr** mit diesem Konto verknüpft. Die Commits selbst **bleiben** intakt.
- Any forks of private repositories made with the converted user account will be deleted.
{% endwarning %}
## Das persönliche Benutzerkonto behalten und manuell eine neue Organisation erstellen
Wenn Du möchtest, dass Deine Organisation denselben Namen aufweist, den Du aktuell für Dein persönliches Konto verwendest, oder wenn Du die Informationen Deines persönlichen Benutzerkontos intakt halten möchtest, musst Du eine neue Organisation erstellen und Deine Repositorys in diese Organisation übertragen, anstatt Dein Benutzerkonto in eine Organisation umzuwandeln.
1. Um den aktuellen Namen Deines Benutzerkontos für den persönlichen Gebrauch zu behalten, [ändere den Namen Deines persönlichen Benutzerkontos](/articles/changing-your-github-username) in einen neuen Namen, der Dir gefällt.
2. [Erstelle eine neue Organisation](/articles/creating-a-new-organization-from-scratch) mit dem ursprünglichen Namen Deines persönlichen Benutzerkontos.
3. [Übertrage Deine Repositorys](/articles/transferring-a-repository) in Dein neues Organisationskonto.
## Das persönliche Konto automatisch in eine Organisation umwandeln
Du kannst Dein persönliches Benutzerkonto auch direkt in eine Organisation umwandeln. Beim Umwandeln Deines Kontos geschieht Folgendes:
- Die Repositorys werden so beibehalten, wie sie sind, ohne dass Du sie manuell an ein anderes Konto übertragen musst
- Es werden automatisch Mitarbeiter zu Teams eingeladen, wobei die Berechtigungen den bisherigen Berechtigungen entsprechen.
{% ifversion fpt or ghec %} Bei Benutzerkonten auf {% data variables.product.prodname_pro %} wird die Abrechnung automatisch auf [das bezahlte {% data variables.product.prodname_team %}](/articles/about-billing-for-github-accounts) umgestellt, ohne dass Du die Zahlungsinformationen erneut eingeben, Deinen Abrechnungszeitraum anpassen oder doppelt bezahlen musst.{% endif %}
1. Erstelle ein neues persönliches Konto, mit dem Du Dich nach der Umwandlung bei GitHub anmelden und auf die Organisation und Deine Repositorys zugreifst.
2. [Verlasse alle Organisationen](/articles/removing-yourself-from-an-organization), denen das Benutzerkonto angehört, das Du gerade umwandelst.
{% data reusables.user_settings.access_settings %}
{% data reusables.user_settings.organizations %}
5. Klicke unter „Transform account“ (Konto umwandeln) auf **Turn <username> into an organization** (Benutzer in eine Organisation umwandeln). ![Schaltfläche „Organization conversion" (Umwandeln in eine Organisation)](/assets/images/help/settings/convert-to-organization.png)
6. Überprüfe und bestätige im Dialogfeld „Account Transformation Warning“ (Warnung zur Kontoumwandlung) die Umwandlung. Beachte, dass die Informationen in diesem Feld mit der Warnung oben in diesem Artikel übereinstimmt. ![Warnung zur Umwandlung](/assets/images/help/organizations/organization-account-transformation-warning.png)
7. Wähle auf der Seite „Transform your user into an organization“ (Benutzer in eine Organisation umwandeln) unter „Choose an organization owner“ (Organisationsinhaber auswählen) entweder das sekundäre persönliche Konto, das Du im vorherigen Abschnitt erstellt hast, oder einen anderen vertrauenswürdigen Benutzer für die Verwaltung der Organisation aus. ![Seite „Add organization owner" (Hinzufügen eines Organisationsinhabers)](/assets/images/help/organizations/organization-add-owner.png)
8. Wähle das Abonnement der neuen Organisation aus, und gib auf Aufforderung Deine Abrechnungsinformationen ein.
9. Klicke auf **Create Organization** (Organisation erstellen).
10. Melde Dich bei dem neuen Benutzerkonto an, das Du in Schritt 1 erstellt hast, und greife dann mithilfe des Kontextumschalters auf Deine neue Organisation zu.
{% tip %}
**Tipp:** Wenn Du ein Benutzerkonto in eine Organisation umwandelst, fügen wir Mitarbeiter von Repositorys, die zum Konto gehören, als *externe Mitarbeiter* zur neuen Organisation hinzu. Du kannst dann *externe Mitarbeiter* dazu einladen, Mitglieder Deiner neuen Organisation zu werden. For more information, see "[Roles in an organization](/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#outside-collaborators)."
{% endtip %}
## Weiterführende Informationen
- „[Teams einrichten](/articles/setting-up-teams)“
{% ifversion fpt or ghec %}- „[Benutzer zum Beitritt zu Deiner Organisation einladen](/articles/inviting-users-to-join-your-organization)“{% endif %}
- „[Auf eine Organisation zugreifen](/articles/accessing-an-organization)“

View File

@@ -1,50 +0,0 @@
---
title: Dein Benutzerkonto löschen
intro: 'Sie können Ihr {% data variables.product.product_name %}-Benutzerkonto jederzeit löschen.'
redirect_from:
- /articles/deleting-a-user-account/
- /articles/deleting-your-user-account
- /github/setting-up-and-managing-your-github-user-account/deleting-your-user-account
- /github/setting-up-and-managing-your-github-user-account/managing-user-account-settings/deleting-your-user-account
versions:
fpt: '*'
ghes: '*'
ghec: '*'
topics:
- Accounts
shortTitle: Dein Benutzerkonto löschen
---
Wenn Du Dein Benutzerkonto löschst, werden alle dazugehörigen Repositorys, Forks von privaten Repositorys, Wikis, Issues, Pull Requests und Seiten Deines Kontos ebenfalls gelöscht. {% ifversion fpt or ghec %} Deine Issues, Pull Requests und Kommentare in Repositorys von anderen Benutzern werden nicht gelöscht, sondern mit unserem [Ghost user](https://github.com/ghost) (Geisterbenutzer) verknüpft.{% else %}Deine Issues, Pull Requests und Kommentare in Repositorys von anderen Benutzern werden nicht gelöscht.{% endif %}
{% ifversion fpt or ghec %} When you delete your account we stop billing you. The email address associated with the account becomes available for use with a different account on {% data variables.product.product_location %}. After 90 days, the account name also becomes available to anyone else to use on a new account. {% endif %}
Wenn Du der alleinige Inhaber einer Organisation bist, musst Du die Inhaberschaft auf eine andere Person übertragen oder die Organisation löschen, bevor Du Dein Benutzerkonto löschen kannst. Wenn es noch weitere Inhaber Deiner Organisation gibt, musst Du Dich selbst aus der Organisation löschen, bevor Du Dein Benutzerkonto löschen kannst.
Weitere Informationen findest Du unter:
- „[Inhaberschaft an einer Organisation übertragen](/articles/transferring-organization-ownership)“
- „[Ein Organisationskonto löschen](/articles/deleting-an-organization-account)“
- „[Dich selbst aus einer Organisation entfernen](/articles/removing-yourself-from-an-organization/)“
## Deine Kontoinformationen sichern
Bevor Du Dein Benutzerkonto löschst, erstelle Kopien aller Repositorys, privaten Forks, Wikis, Issues und Pull Requests Deines Kontos.
{% warning %}
**Warnung:** Sobald Dein Benutzerkonto gelöscht wurde, kann GitHub Deine Inhalte nicht wiederherstellen.
{% endwarning %}
## Dein Benutzerkonto löschen
{% data reusables.user_settings.access_settings %}
{% data reusables.user_settings.account_settings %}
3. Klicke unten auf der Seite mit den Kontoeinstellungen unter „Delete account“ (Konto löschen) auf **Delete your account** (Dein Konto löschen). Vor dem Löschen Deines Benutzerkontos musst Du Folgendes tun:
- Wenn Du der alleinige Inhaber einer Organisation bist, musst Du die Inhaberschaft auf eine andere Person übertragen oder die Organisation löschen.
- Wenn es andere Inhaber der Organisation gibt, musst Du Dich selbst aus der Organisation entfernen. ![Schaltfläche zum Löschen des Kontos](/assets/images/help/settings/settings-account-delete.png)
4. Fülle das Dialogfeld „Are you sure you want to do this?“ (Möchtest Du das wirklich tun?) aus, um zu bestätigen, dass Du die Folgen der Kontolöschung verstanden hast: ![Dialogfeld zum Bestätigen der Kontolöschung](/assets/images/help/settings/settings-account-deleteconfirm.png)
{% ifversion fpt or ghec %} Denken Sie daran, dass alle Repositorys, Forks von privaten Repositorys, Wikis, Issues, Pull Requests und Seiten von Ihrem Konto ebenfalls gelöscht werden, dass Ihre Abrechnung beendet wird und Ihr Benutzername wieder für die Verwendung auf {% data variables.product.product_name %} freigegeben wird.
{% else %} Denke daran, dass alle Repositorys, Forks von privaten Repositorys, Wikis, Issues, Pull Requests und Seiten von Deinem Konto ebenfalls gelöscht werden und Dein Benutzername wieder für die Verwendung auf {% data variables.product.product_name %} freigegeben wird.
{% endif %} Gib im ersten Feld Deinen {% data variables.product.product_name %}-Benutzernamen oder Deine E-Mail-Adresse ein.
- Gib im zweiten Feld den Text von der Aufforderung ein.

View File

@@ -1,34 +0,0 @@
---
title: Benutzerkontoeinstellungen verwalten
intro: 'Du kannst mehrere Einstellungen für Dein persönliches Konto ändern. Dazu gehört auch, dass Du Deinen Benutzernamen ändern und Dein Konto löschen kannst.'
redirect_from:
- /categories/29/articles/
- /categories/user-accounts/
- /articles/managing-user-account-settings
- /github/setting-up-and-managing-your-github-user-account/managing-user-account-settings
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Accounts
children:
- /about-your-personal-dashboard
- /managing-your-theme-settings
- /managing-your-tab-size-rendering-preference
- /changing-your-github-username
- /merging-multiple-user-accounts
- /converting-a-user-into-an-organization
- /deleting-your-user-account
- /permission-levels-for-a-user-account-repository
- /permission-levels-for-user-owned-project-boards
- /managing-the-default-branch-name-for-your-repositories
- /managing-security-and-analysis-settings-for-your-user-account
- /managing-access-to-your-user-accounts-project-boards
- /integrating-jira-with-your-personal-projects
- /best-practices-for-leaving-your-company
- /what-does-the-available-for-hire-checkbox-do
shortTitle: User account settings
---

View File

@@ -1,28 +0,0 @@
---
title: Jira in Deine persönlichen Projekte integrieren
intro: 'Du kannst Jira Cloud in Dein Benutzerkonto integrieren, um Commits und Pull Requests zu scannen und relevante Metadaten und Hyperlinks in allen erwähnten Jira-Issues zu erstellen.'
redirect_from:
- /articles/integrating-jira-with-your-personal-projects
- /github/setting-up-and-managing-your-github-user-account/integrating-jira-with-your-personal-projects
- /github/setting-up-and-managing-your-github-user-account/managing-user-account-settings/integrating-jira-with-your-personal-projects
versions:
ghes: '*'
ghae: '*'
shortTitle: Integrate Jira with projects
---
{% data reusables.user_settings.access_settings %}
{% data reusables.user_settings.developer_settings %}
3. Klicken Sie auf der linken Seitenleiste auf **{% data variables.product.prodname_oauth_apps %}**. ![Registerkarte „{% data variables.product.prodname_oauth_apps %}" in der linken Seitenleiste](/assets/images/help/settings/developer-settings-oauth-apps.png)
3. Klicke auf **Register a new application** (Eine neue Anwendung registrieren).
4. Gib unter **Application name** (Anwendungsname) „Jira“ ein.
5. Gib unter **Homepage URL** (URL für Startseite) die vollständige URL Deiner Jira-Instanz ein.
6. Gib unter **Authorization callback URL** (Autorisierungs-Callback-URL) die vollständige URL Deiner Jira-Instanz ein.
7. Klicke auf **Register application** (Anwendung registrieren). ![Schaltfläche „Register application“ (Anwendung registrieren)](/assets/images/help/oauth/register-application-button.png)
8. Notiere Dir unter **Developer applications** (Entwickler-Anwendungen) die Werte für „Client ID“ (Client-ID) und „Client Secret“ (Clientgeheimnis). ![Client-ID und Client-Geheimnis](/assets/images/help/oauth/client-id-and-secret.png)
{% data reusables.user_settings.jira_help_docs %}
## Weiterführende Informationen
- [„Jira in das Projektboard Deiner Organisation integrieren“](/articles/integrating-jira-with-your-organization-project-board)
- <a href="https://confluence.atlassian.com/adminjiracloud/connect-jira-cloud-to-github-814188429.html" data-proofer-ignore> Jira Cloud mit GitHub verbinden</a> (Atlassian-Dokumentation)

View File

@@ -1,37 +0,0 @@
---
title: Zugriff auf die Projektboards Deines Benutzerkontos verwalten
intro: Als Projektboard-Inhaber kannst Du einen Mitarbeiter hinzufügen oder entfernen und seine Berechtigungen für das Projektboard anpassen.
redirect_from:
- /articles/managing-project-boards-in-your-repository-or-organization/
- /articles/managing-access-to-your-user-account-s-project-boards
- /articles/managing-access-to-your-user-accounts-project-boards
- /github/setting-up-and-managing-your-github-user-account/managing-access-to-your-user-accounts-project-boards
- /github/setting-up-and-managing-your-github-user-account/managing-user-account-settings/managing-access-to-your-user-accounts-project-boards
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Accounts
shortTitle: Manage access project boards
---
Ein Mitarbeiter ist eine Person, die Berechtigungen für eines Deiner Projektboards besitzt. Die Berechtigung eines Mitarbeiters ist standardmäßig der Lesezugriff. Weitere Informationen findest Du unter „[Berechtigungsebenen für Benutzer-Projektboards](/articles/permission-levels-for-user-owned-project-boards).“
## Mitarbeiter in ein Benutzer-Projektboard einladen
1. Navigiere zu dem Projektboard, zu dem Du einen Mitarbeiter hinzufügen möchtest.
{% data reusables.project-management.click-menu %}
{% data reusables.project-management.access-collaboration-settings %}
{% data reusables.project-management.collaborator-option %}
5. Geben Sie unter „Search by username, full name or email address“ (Nach Benutzernamen, vollständigem Namen oder E-Mail-Adresse suchen) den Namen, den Benutzernamen oder die {% data variables.product.prodname_dotcom %}-E-Mail-Adresse des Mitarbeiters ein. ![Der Bereich „Collaborators“ (Mitarbeiter) mit Octocat-Benutzernamen im Suchfeld](/assets/images/help/projects/org-project-collaborators-find-name.png)
{% data reusables.project-management.add-collaborator %}
7. Der neue Mitarbeiter besitzt standardmäßig Leseberechtigung. Wähle optional im Dropdownmenü neben dem Namen des neuen Mitarbeiters eine andere Berechtigungsebene aus. ![Der Mitarbeiter-Bereich mit ausgewähltem Berechtigungs-Dropdownmenü](/assets/images/help/projects/user-project-collaborators-edit-permissions.png)
## Mitarbeiter aus einem Benutzer-Projektboard entfernen
{% data reusables.project-management.click-menu %}
{% data reusables.project-management.access-collaboration-settings %}
{% data reusables.project-management.collaborator-option %}
{% data reusables.project-management.remove-collaborator %}

View File

@@ -1,47 +0,0 @@
---
title: Managing security and analysis settings for your user account
intro: 'You can control features that secure and analyze the code in your projects on {% data variables.product.prodname_dotcom %}.'
versions:
fpt: '*'
ghec: '*'
topics:
- Accounts
redirect_from:
- /github/setting-up-and-managing-your-github-user-account/managing-security-and-analysis-settings-for-your-user-account
- /github/setting-up-and-managing-your-github-user-account/managing-user-account-settings/managing-security-and-analysis-settings-for-your-user-account
shortTitle: Manage security & analysis
---
## About management of security and analysis settings
{% data variables.product.prodname_dotcom %} can help secure your repositories. This topic tells you how you can manage the security and analysis features for all your existing or new repositories.
You can still manage the security and analysis features for individual repositories. For more information, see "[Managing security and analysis settings for your repository](/github/administering-a-repository/managing-security-and-analysis-settings-for-your-repository)."
{% data reusables.security.some-security-and-analysis-features-are-enabled-by-default %}
{% data reusables.security.security-and-analysis-features-enable-read-only %}
For an overview of repository-level security, see "[Securing your repository](/code-security/getting-started/securing-your-repository)."
## Enabling or disabling features for existing repositories
{% data reusables.user_settings.access_settings %}
{% data reusables.user_settings.security-analysis %}
3. Under "Configure security and analysis features", to the right of the feature, click **Disable all** or **Enable all**. !["Enable all" or "Disable all" button for "Configure security and analysis" features](/assets/images/help/settings/security-and-analysis-disable-or-enable-all.png)
6. Optionally, enable the feature by default for new repositories in your organization. !["Enable by default" option for new repositories](/assets/images/help/settings/security-and-analysis-enable-by-default-in-modal.png)
7. Click **Disable FEATURE** or **Enable FEATURE** to disable or enable the feature for all the repositories you own. ![Button to disable or enable feature](/assets/images/help/settings/security-and-analysis-enable-dependency-graph.png)
{% data reusables.security.displayed-information %}
## Enabling or disabling features for new repositories
{% data reusables.user_settings.access_settings %}
{% data reusables.user_settings.security-analysis %}
3. Under "Configure security and analysis features", to the right of the feature, enable or disable the feature by default for new repositories in your organization. ![Checkbox for enabling or disabling a feature for new repositories](/assets/images/help/settings/security-and-analysis-enable-or-disable-feature-checkbox.png)
## Weiterführende Informationen
- "[About the dependency graph](/github/visualizing-repository-data-with-graphs/about-the-dependency-graph)"
- "[Managing vulnerabilities in your project's dependencies](/github/managing-security-vulnerabilities/managing-vulnerabilities-in-your-projects-dependencies)"
{% ifversion fpt or ghec %}- "[Keeping your dependencies updated automatically](/github/administering-a-repository/keeping-your-dependencies-updated-automatically)"{% endif %}

View File

@@ -1,33 +0,0 @@
---
title: Managing the default branch name for your repositories
intro: 'You can set the default branch name for new repositories that you create on {% data variables.product.product_location %}.'
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Accounts
redirect_from:
- /github/setting-up-and-managing-your-github-user-account/managing-the-default-branch-name-for-your-repositories
- /github/setting-up-and-managing-your-github-user-account/managing-user-account-settings/managing-the-default-branch-name-for-your-repositories
shortTitle: Manage default branch name
---
## About the default branch name
When you create a new repository on {% data variables.product.product_location %}, the repository contains one branch, which is the default branch. You can change the name that {% data variables.product.product_name %} uses for the default branch in new repositories you create. For more information about the default branch, see "[About branches](/github/collaborating-with-issues-and-pull-requests/about-branches#about-the-default-branch)."
{% data reusables.branches.set-default-branch %}
## Setting the default branch name
{% data reusables.user_settings.access_settings %}
{% data reusables.user_settings.repo-tab %}
3. Under "Repository default branch", click **Change default branch name now**. ![Override button](/assets/images/help/settings/repo-default-name-button.png)
4. Type the default name that you would like to use for new branches. ![Text box for entering default name](/assets/images/help/settings/repo-default-name-text.png)
5. Klicke auf **Update** (Aktualisieren). ![Update button](/assets/images/help/settings/repo-default-name-update.png)
## Weiterführende Informationen
- "[Managing the default branch name for repositories in your organization](/organizations/managing-organization-settings/managing-the-default-branch-name-for-repositories-in-your-organization)"

View File

@@ -1,16 +0,0 @@
---
title: Managing your tab size rendering preference
intro: You can manage the number of spaces a tab is equal to for your user account.
versions:
fpt: '*'
ghec: '*'
topics:
- Accounts
shortTitle: Managing your tab size
---
If you feel that tabbed indentation in code rendered on {% data variables.product.product_name %} takes up too much, or too little space, you can change this in your settings.
{% data reusables.user_settings.access_settings %}
1. In the user settings sidebar, click **Appearance**. !["Appearance" tab in user settings sidebar](/assets/images/help/settings/appearance-tab.png)
2. Under "Tab size preference", select the drop-down menu and choose your preference. ![Tab size preference button](/assets/images/help/settings/tab-size-preference.png)

View File

@@ -1,54 +0,0 @@
---
title: Managing your theme settings
intro: 'You can manage how {% data variables.product.product_name %} looks to you by setting a theme preference that either follows your system settings or always uses a light or dark mode.'
versions:
fpt: '*'
ghae: next
ghes: '>=3.2'
ghec: '*'
topics:
- Accounts
redirect_from:
- /github/setting-up-and-managing-your-github-user-account/managing-your-theme-settings
- /github/setting-up-and-managing-your-github-user-account/managing-user-account-settings/managing-your-theme-settings
shortTitle: Manage theme settings
---
For choice and flexibility in how and when you use {% data variables.product.product_name %}, you can configure theme settings to change how {% data variables.product.product_name %} looks to you. You can choose from themes that are light or dark, or you can configure {% data variables.product.product_name %} to follow your system settings.
You may want to use a dark theme to reduce power consumption on certain devices, to reduce eye strain in low-light conditions, or because you prefer how the theme looks.
{% ifversion fpt or ghae-issue-4618 or ghec %} If you have low vision, you may benefit from a high contrast theme, with greater contrast between foreground and background elements.{% endif %}{% ifversion fpt or ghae-issue-4619 or ghec %} If you have colorblindness, you may benefit from our light and dark colorblind themes.
{% note %}
**Note:** The colorblind themes are currently in public beta. For more information on enabling features in public beta, see "[Exploring early access releases with feature preview](/get-started/using-github/exploring-early-access-releases-with-feature-preview)."
{% endnote %}
{% endif %}
{% data reusables.user_settings.access_settings %}
1. In the user settings sidebar, click **Appearance**. !["Appearance" tab in user settings sidebar](/assets/images/help/settings/appearance-tab.png)
2. Under "Theme mode", select the drop-down menu, then click a theme preference. ![Drop-down menu under "Theme mode" for selection of theme preference](/assets/images/help/settings/theme-mode-drop-down-menu.png)
3. Klicke auf das gewünschte Design.
- If you chose a single theme, click a theme.
{% ifversion fpt or ghae-issue-4618 or ghec %}![Radio buttons for the choice of a single theme](/assets/images/help/settings/theme-choose-a-single-theme-highcontrast.png){% else %}![Radio buttons for the choice of a single theme](/assets/images/help/settings/theme-choose-a-single-theme.png){% endif %}
- If you chose to follow your system settings, click a day theme and a night theme.
{% ifversion fpt or ghae-issue-4618 or ghec %}![Buttons for the choice of a theme to sync with the system setting](/assets/images/help/settings/theme-choose-a-day-and-night-theme-to-sync-highcontrast.png){% else %}![Buttons for the choice of a theme to sync with the system setting](/assets/images/help/settings/theme-choose-a-day-and-night-theme-to-sync.png){% endif %}
{% ifversion fpt or ghae-issue-4619 or ghec %}
- If you would like to choose a theme which is currently in public beta, you will first need to enable it with feature preview. For more information, see "[Exploring early access releases with feature preview](/get-started/using-github/exploring-early-access-releases-with-feature-preview)."{% endif %}
{% if command-palette %}
{% note %}
**Note:** You can also change your theme settings with the command palette. For more information, see "[{% data variables.product.prodname_command_palette %}](/get-started/using-github/github-command-palette)".
{% endnote %}
{% endif %}
## Weiterführende Informationen
- „[Design für {% data variables.product.prodname_desktop %} festlegen](/desktop/installing-and-configuring-github-desktop/setting-a-theme-for-github-desktop)“

View File

@@ -1,30 +0,0 @@
---
title: Mehrere Benutzerkonten zusammenführen
intro: 'Wenn Du separate Konten für die Arbeit und für die private Nutzung besitzt, kannst Du die Konten zusammenführen.'
redirect_from:
- /articles/can-i-merge-two-accounts/
- /articles/keeping-work-and-personal-repositories-separate/
- /articles/merging-multiple-user-accounts
- /github/setting-up-and-managing-your-github-user-account/merging-multiple-user-accounts
- /github/setting-up-and-managing-your-github-user-account/managing-user-account-settings/merging-multiple-user-accounts
versions:
fpt: '*'
ghec: '*'
topics:
- Accounts
shortTitle: Merge multiple user accounts
---
{% tip %}
**Tipp:** Wir empfehlen, nur ein Benutzerkonto für die Verwaltung persönlicher und beruflicher Repositorys zu verwenden.
{% endtip %}
1. [Übertrage die Repositorys](/articles/how-to-transfer-a-repository) vom Konto, das Du löschen möchtest, zu dem Konto, das Du behalten möchtest. Issues, Pull Requests und Wikis werden ebenfalls übertragen. Überprüfe, ob die Repositorys in dem Konto, das Du behalten möchtest, vorhanden sind.
2. [Aktualisiere die Remote-URLs](/github/getting-started-with-github/managing-remote-repositories) bei allen lokalen Klonen der Repositorys, die verschoben wurden.
3. [Lösche das Konto](/articles/deleting-your-user-account), das Du nicht mehr verwenden möchtest.
## Weiterführende Informationen
- „[Arten von {% data variables.product.prodname_dotcom %}-Konten](/articles/types-of-github-accounts)“

View File

@@ -1,98 +0,0 @@
---
title: Berechtigungsebenen für ein Repository eines Benutzerkontos
intro: 'A repository owned by a user account has two permission levels: the repository owner and collaborators.'
redirect_from:
- /articles/permission-levels-for-a-user-account-repository
- /github/setting-up-and-managing-your-github-user-account/permission-levels-for-a-user-account-repository
- /github/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-a-user-account-repository
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Accounts
shortTitle: Permission user repositories
---
## About permissions levels for a user account repository
Repositories owned by user accounts have one owner. Ownership permissions can't be shared with another user account.
You can also {% ifversion fpt or ghec %}invite{% else %}add{% endif %} users on {% data variables.product.product_name %} to your repository as collaborators. For more information, see "[Inviting collaborators to a personal repository](/github/setting-up-and-managing-your-github-user-account/inviting-collaborators-to-a-personal-repository)."
{% tip %}
**Tip:** If you require more granular access to a repository owned by your user account, consider transferring the repository to an organization. Weitere Informationen finden Sie unter „[Ein Repository übertragen](/github/administering-a-repository/transferring-a-repository#transferring-a-repository-owned-by-your-user-account)“.
{% endtip %}
## Owner access for a repository owned by a user account
Der Repository-Inhaber besitzt die vollständige Kontrolle über das Repository. In addition to the actions that any collaborator can perform, the repository owner can perform the following actions.
| Aktion | Weitere Informationen |
|:----------------------------------------------------------------------------------------------------------------------------------------------------------------- |:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| {% ifversion fpt or ghec %}Invite collaborators{% else %}Add collaborators{% endif %} | |
| „[Mitarbeiter in ein persönliches Repository einladen](/github/setting-up-and-managing-your-github-user-account/inviting-collaborators-to-a-personal-repository)“ | |
| Change the visibility of the repository | "[Setting repository visibility](/github/administering-a-repository/setting-repository-visibility)" |{% ifversion fpt or ghec %}
| Limit interactions with the repository | "[Limiting interactions in your repository](/communities/moderating-comments-and-conversations/limiting-interactions-in-your-repository)" |{% endif %}{% ifversion fpt or ghes > 3.0 or ghae-next or ghec %}
| Rename a branch, including the default branch | "[Renaming a branch](/github/administering-a-repository/renaming-a-branch)"
{% endif %}
| Einen Pull Request auf einem geschützten Branch zusammenführen, selbst ohne genehmigende Reviews | „[Informationen zu geschützten Branches](/github/administering-a-repository/about-protected-branches)“ |
| Das Repository löschen | „[Repository löschen](/github/administering-a-repository/deleting-a-repository)“ |
| Manage the repository's topics | "[Classifying your repository with topics](/github/administering-a-repository/classifying-your-repository-with-topics)" |{% ifversion fpt or ghec %}
| Manage security and analysis settings for the repository | "[Managing security and analysis settings for your repository](/github/administering-a-repository/managing-security-and-analysis-settings-for-your-repository)" |{% endif %}{% ifversion fpt or ghec %}
| Enable the dependency graph for a private repository | "[Exploring the dependencies of a repository](/github/visualizing-repository-data-with-graphs/exploring-the-dependencies-of-a-repository#enabling-and-disabling-the-dependency-graph-for-a-private-repository)" |{% endif %}{% ifversion fpt or ghes > 3.0 or ghec %}
| Delete and restore packages | "[Deleting and restoring a package](/packages/learn-github-packages/deleting-and-restoring-a-package)" |{% endif %}{% ifversion ghes = 3.0 or ghae %}
| Pakete löschen | "[Deleting packages](/packages/learn-github-packages/deleting-a-package)"
{% endif %}
| Customize the repository's social media preview | "[Customizing your repository's social media preview](/github/administering-a-repository/customizing-your-repositorys-social-media-preview)" |
| Create a template from the repository | "[Creating a template repository](/github/creating-cloning-and-archiving-repositories/creating-a-template-repository)" |{% ifversion fpt or ghes or ghae-issue-4864 or ghec %}
| Control access to {% data variables.product.prodname_dependabot_alerts %} alerts for vulnerable dependencies | "[Managing security and analysis settings for your repository](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-security-and-analysis-settings-for-your-repository#granting-access-to-security-alerts)" |{% endif %}{% ifversion fpt or ghec %}
| Dismiss {% data variables.product.prodname_dependabot_alerts %} in the repository | „[Angreifbare Abhängigkeiten in Ihrem Repository anzeigen und aktualisieren](/github/managing-security-vulnerabilities/viewing-and-updating-vulnerable-dependencies-in-your-repository)“ |
| Manage data use for a private repository | "[Managing data use settings for your private repository](/github/understanding-how-github-uses-and-protects-your-data/managing-data-use-settings-for-your-private-repository)"
{% endif %}
| Codeinhaber für das Repository definieren | „[Informationen zu Codeinhabern](/github/creating-cloning-and-archiving-repositories/about-code-owners)“ |
| Archive the repository | "[Archiving repositories](/repositories/archiving-a-github-repository/archiving-repositories)" |{% ifversion fpt or ghec %}
| Sicherheitshinweise erstellen | "[About {% data variables.product.prodname_security_advisories %}](/github/managing-security-vulnerabilities/about-github-security-advisories)" |
| Eine Sponsorenschaltfläche anzeigen | "[Displaying a sponsor button in your repository](/github/administering-a-repository/displaying-a-sponsor-button-in-your-repository)" |{% endif %}{% ifversion fpt or ghae or ghes > 3.0 or ghec %}
| Allow or disallow auto-merge for pull requests | "[Managing auto-merge for pull requests in your repository](/github/administering-a-repository/managing-auto-merge-for-pull-requests-in-your-repository)" | {% endif %}
## Collaborator access for a repository owned by a user account
Collaborators on a personal repository can pull (read) the contents of the repository and push (write) changes to the repository.
{% note %}
**Hinweis:** In einem privaten Repository können Repository-Inhaber Mitarbeitern nur Schreibzugriff gewähren. Mitarbeiter können nicht Nur-Lese-Zugriff auf Repositorys haben, die einem Benutzerkonto gehören.
{% endnote %}
Collaborators can also perform the following actions.
| Aktion | Weitere Informationen |
|:----------------------------------------------------------------------------------------- |:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Fork the repository | "[About forks](/github/collaborating-with-issues-and-pull-requests/about-forks)" |{% ifversion fpt or ghes > 3.1 or ghae-next or ghec %}
| Rename a branch other than the default branch | "[Renaming a branch](/github/administering-a-repository/renaming-a-branch)"
{% endif %}
| Create, edit, and delete comments on commits, pull requests, and issues in the repository | <ul><li>"[About issues](/github/managing-your-work-on-github/about-issues)"</li><li>"[Commenting on a pull request](/github/collaborating-with-issues-and-pull-requests/commenting-on-a-pull-request)"</li><li>"[Managing disruptive comments](/communities/moderating-comments-and-conversations/managing-disruptive-comments)"</li></ul> |
| Create, assign, close, and re-open issues in the repository | "[Managing your work with issues](/github/managing-your-work-on-github/managing-your-work-with-issues)" |
| Manage labels for issues and pull requests in the repository | "[Labeling issues and pull requests](/github/managing-your-work-on-github/labeling-issues-and-pull-requests)" |
| Manage milestones for issues and pull requests in the repository | „[Meilensteine für Issues und Pull Requests erstellen und bearbeiten](/github/managing-your-work-on-github/creating-and-editing-milestones-for-issues-and-pull-requests)“ |
| Mark an issue or pull request in the repository as a duplicate | "[About duplicate issues and pull requests](/github/managing-your-work-on-github/about-duplicate-issues-and-pull-requests)" |
| Create, merge, and close pull requests in the repository | "[Proposing changes to your work with pull requests](/github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests)" |{% ifversion fpt or ghae or ghes > 3.0 or ghec %}
| Enable and disable auto-merge for a pull request | "[Automatically merging a pull request](/github/collaborating-with-issues-and-pull-requests/automatically-merging-a-pull-request)"{% endif %}
| Apply suggested changes to pull requests in the repository | "[Incorporating feedback in your pull request](/github/collaborating-with-issues-and-pull-requests/incorporating-feedback-in-your-pull-request)" |
| Create a pull request from a fork of the repository | „[Einen Pull Request von einem Fork erstellen](/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request-from-a-fork)“ |
| Submit a review on a pull request that affects the mergeability of the pull request | „[Vorgeschlagene Änderungen in einem Pull Request überprüfen](/github/collaborating-with-issues-and-pull-requests/reviewing-proposed-changes-in-a-pull-request)" |
| Create and edit a wiki for the repository | „[Informationen zu Wikis](/communities/documenting-your-project-with-wikis/about-wikis)“ |
| Create and edit releases for the repository | "[Managing releases in a repository](/github/administering-a-repository/managing-releases-in-a-repository)" |
| Act as a code owner for the repository | "[About code owners](/articles/about-code-owners)" |{% ifversion fpt or ghae or ghec %}
| Publish, view, or install packages | "[Publishing and managing packages](/github/managing-packages-with-github-packages/publishing-and-managing-packages)"
{% endif %}
| sich selbst als Mitarbeiter aus dem Repository entfernen | „[Dich selbst aus dem Repository eines Mitarbeiters entfernen](/github/setting-up-and-managing-your-github-user-account/removing-yourself-from-a-collaborators-repository)“ |
## Weiterführende Informationen
- "[Repository roles for an organization](/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization)"

View File

@@ -1,64 +0,0 @@
---
title: Berechtigungsebenen für Benutzer-Projektboards
intro: 'Ein Projektboard, das einem Benutzerkonto gehört, hat zwei Berechtigungsebenen: den Projektboard-Inhaber und die Mitarbeiter.'
redirect_from:
- /articles/permission-levels-for-user-owned-project-boards
- /github/setting-up-and-managing-your-github-user-account/permission-levels-for-user-owned-project-boards
- /github/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Accounts
shortTitle: Permission user project boards
---
## Überblick über die Berechtigungen
Es gibt nur einen Inhaber eines Benutzer-Projektboards. Diese Berechtigung kann nicht mit einem anderen Benutzerkonto geteilt werden. Neben dem Inhaber können auch andere Personen an Projektboards mitarbeiten.
Für Projektboard-Mitarbeiter gibt es drei Berechtigungsstufen:
{% data reusables.project-management.project-board-permissions %}
## Inhaber- und Administratorberechtigungen für ein Benutzer-Projektboard
Der Projektboard-Inhaber und die Mitarbeiter mit Administratorzugriff besitzen die vollständige Kontrolle über das Projektboard. Neben den Berechtigungen, die auch Projektboard-Mitarbeitern erteilt werden, stehen einem Projektboard-Inhaber und Mitarbeitern mit Administratorzugriff zusätzlich folgende Möglichkeiten zur Verfügung:
- [Mitarbeiter verwalten, anzeigen und hinzufügen](/articles/managing-access-to-your-user-account-s-project-boards)
- [Configure a project board as {% ifversion ghae %}internal{% else %}public{% endif %} or private](/articles/changing-project-board-visibility)
- [Ein Projektboard löschen](/articles/deleting-a-project-board/)
- [Ein Projektboard schließen](/articles/closing-a-project-board/)
- [Ein geschlossenes Projektboard erneut öffnen](/articles/reopening-a-closed-project-board)
## Lese- und Schreibberechtigungen für ein Benutzer-Projektboard
Mitarbeiter mit Lesezugriff auf ein Benutzer-Projektboard können Folgendes tun:
- Ein Projektboard anzeigen
- Ein Projektboard kopieren
- Tickets auf einem Projektboard filtern
Mitarbeiter mit Schreibzugriff auf ein Benutzer-Projektboard können Folgendes tun:
- Ein Projektboard anzeigen
- Ein Projektboard kopieren
- Tickets auf einem Projektboard filtern
- Ein Projektboard bearbeiten
- Ein Repository mit einem Projektboard verknüpfen
- Automatisierung für Projektboards konfigurieren
- Ein Projektboard kopieren
- Issues und Pull Requests zu einem Projektboard hinzufügen
- Hinweise zu einem Projektboard hinzufügen
- Fortschritt in Deinem Projektboard verfolgen
- Tickets auf einem Projektboard archivieren
## Sichtbarkeit des Projektboards
You can change the project board's visibility from private to {% ifversion ghae %}internal{% else %}public{% endif %} and back again. Standardmäßig sind Benutzer-Projektboards privat. Weitere Informationen finden Sie unter „[Sichtbarkeit des Projektboards ändern](/articles/changing-project-board-visibility)“.
## Weiterführende Informationen
- „[Zugriff auf die Projektboards Deines Benutzerkontos verwalten](/articles/managing-access-to-your-user-account-s-project-boards)“

View File

@@ -1,27 +0,0 @@
---
title: Funktionsweise des Kontrollkästchens „Available for hire“ (Zur Anstellung verfügbar)
intro: 'Verwende das Kontrollkästchen **Available for hire** (Zur Anstellung verfügbar), um GitHub Jobs-Beiträge in GitHub anzuzeigen.'
redirect_from:
- /articles/what-does-the-available-for-hire-checkbox-do
- /github/setting-up-and-managing-your-github-user-account/what-does-the-available-for-hire-checkbox-do
- /github/setting-up-and-managing-your-github-user-account/managing-user-account-settings/what-does-the-available-for-hire-checkbox-do
versions:
fpt: '*'
ghec: '*'
topics:
- Accounts
shortTitle: Available for hire checkbox
---
{% warning %}
Deprecation note: GitHub Jobs is now deprecated. The last date to post a job was May 19, 2021. The GitHub Jobs site has shut down entirely on August 19, 2021, and now redirects to the [GitHub blog post](https://github.blog/changelog/2021-04-19-deprecation-notice-github-jobs-site/) notice, which has more information on the now-completed deprecation of GitHub Jobs.
{% endwarning %}
Das [GitHub Jobs](https://jobs.github.com/)-Board ist eine tolle Möglichkeit, um im technischen Bereich eine Stelle zu finden. Du kannst die in Deinem GitHub-Dashboard eingestellten Stellenangebote ansehen.
![GitHub Jobs-Anzeigen im Dashboard](/assets/images/help/settings/jobs-ads-on-dashboard.png)
{% data reusables.user_settings.access_settings %}
2. Wähle unter „Jobs Profile“ (Stellen-Profil) die Option **Available for hire** (Zur Anstellung verfügbar) aus. Klicke anschließend auf **Save jobs profile** (Stellen-Profil speichern). ![Einstellungen für Stellen-Profil](/assets/images/help/settings/jobs-profile-settings.png)

View File

@@ -1,53 +0,0 @@
---
title: Informationen zur Organisationsmitgliedschaft
intro: 'Du kannst Mitglied einer Organisation werden, um mit Mitarbeitern oder Open-Source-Mitwirkenden in vielen Repositorys gleichzeitig zusammenzuarbeiten.'
redirect_from:
- /articles/about-organization-membership
- /github/setting-up-and-managing-your-github-user-account/about-organization-membership
- /github/setting-up-and-managing-your-github-user-account/managing-your-membership-in-organizations/about-organization-membership
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Accounts
shortTitle: Organization membership
---
Ein Organisationsinhaber kann Dich einladen, seiner Organisation als Mitglied, Abrechnungsmanager oder Inhaber beizutreten. Ein Organisationsinhaber oder Mitglied mit Administratorberechtigungen für ein Repository kann Dich einladen, als externer Mitarbeiter in einem oder mehreren Repositorys zusammenzuarbeiten. For more information, see "[Roles in an organization](/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization)."
Auf Deiner Profilseite kannst Du auf Organisationen zugreifen, denen Du angehörst. Weitere Informationen findest Du unter „[Auf eine Organisation zugreifen](/articles/accessing-an-organization).“
Wenn Du eine Einladung annimmst, einer Organisation beizutreten, können die Inhaber der Organisation unter Umständen Folgendes sehen:
- Deine öffentlichen Profilinformationen
- Deine E-Mail-Adresse
- Ob die Zwei-Faktor-Authentifizierung bei Dir aktiviert hast
- Repositorys, auf die Du innerhalb der Organisation Zugriff hast, und Deine Zugriffsebene
- Bestimmte Aktivitäten innerhalb der Organisation
- Das Land der Antragstellung
- Deine IP-Adresse
Weitere Informationen findest Du in der <a href="/articles/github-privacy-statement/" class="dotcom-only">{% data variables.product.prodname_dotcom %}-Datenschutzerklärung</a>.
{% note %}
**Hinweis:** Inhaber können die IP-Adressen der Mitglieder nicht im Auditprotokoll der Organisation anzeigen. Bei einem Sicherheitsvorfall, beispielsweise einer Kontokompromittierung oder einer versehentlichen Weitergabe vertraulicher Daten, können Unternehmensinhaber Details zum Zugriff auf private Repositorys anfordern. Zu den von uns übermittelten Informationen kann auch Deine IP-Adresse gehören.
{% endnote %}
Die Sichtbarkeit Deiner Mitgliedschaft in einer Organisation ist standardmäßig auf privat eingestellt. Du kannst wählen, ob Du einzelne Mitgliedschaften in Organisationen in Deinem Profil veröffentlichen möchtest. Weitere Informationen findest Du unter „[Mitgliedschaft in einer Organisation veröffentlichen oder ausblenden](/articles/publicizing-or-hiding-organization-membership).“
{% ifversion fpt or ghec %}
Wenn Deine Organisation zu einem Enterprise-Konto gehört, bist Du automatisch Mitglied des Enterprise-Kontos und für Inhaber des Enterprise-Kontos sichtbar. Weitere Informationen findest Du unter „[Informationen zu Enterprise-Konten](/admin/overview/about-enterprise-accounts).“
{% endif %}
Du kannst eine Organisation jederzeit verlassen. Weitere Informationen findest Du unter „[Dich selbst aus einer Organisation entfernen](/articles/removing-yourself-from-an-organization).“
## Weiterführende Informationen
- „[Informationen zu Organisationen](/articles/about-organizations)“
- „[Deine Mitgliedschaft in Organisationen verwalten](/articles/managing-your-membership-in-organizations)“

View File

@@ -1,27 +0,0 @@
---
title: Auf eine Organisation zugreifen
intro: 'Wenn Du auf eine Organisation zugreifen möchtest, der Du angehörst, musst Du Dich bei Deinem persönlichen Benutzerkonto anmelden.'
redirect_from:
- /articles/error-cannot-log-in-that-account-is-an-organization/
- /articles/cannot-log-in-that-account-is-an-organization/
- /articles/how-do-i-access-my-organization-account/
- /articles/accessing-an-organization
- /github/setting-up-and-managing-your-github-user-account/accessing-an-organization
- /github/setting-up-and-managing-your-github-user-account/managing-your-membership-in-organizations/accessing-an-organization
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Accounts
---
{% tip %}
**Tipp:** Nur Organisationsinhaber können die Kontoeinstellungen für eine Organisation einsehen und ändern.
{% endtip %}
{% data reusables.profile.access_org %}
{% data reusables.user_settings.access_org %}

View File

@@ -1,26 +0,0 @@
---
title: Deine Mitgliedschaft in Organisationen verwalten
intro: |-
Wenn Du Mitglied einer Organisation bist, kannst Du Deine Mitgliedschaft veröffentlichen oder ausblenden, die Rollen anderer Benutzer anzeigen und
Dich selbst aus der Organisation entfernen.
redirect_from:
- /articles/managing-your-membership-in-organizations
- /github/setting-up-and-managing-your-github-user-account/managing-your-membership-in-organizations
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Accounts
children:
- /about-organization-membership
- /accessing-an-organization
- /viewing-peoples-roles-in-an-organization
- /requesting-organization-approval-for-oauth-apps
- /publicizing-or-hiding-organization-membership
- /managing-your-scheduled-reminders
- /removing-yourself-from-an-organization
shortTitle: Manage organization membership
---

View File

@@ -1,59 +0,0 @@
---
title: Verwalten Deiner geplanten Erinnerungen
intro: 'Du kannst in Slack Erinnerungen erhalten, wenn für Dich oder Dein Team Pull Requests auf einen Review warten.'
versions:
fpt: '*'
ghec: '*'
topics:
- Accounts
redirect_from:
- /github/setting-up-and-managing-your-github-user-account/managing-your-scheduled-reminders
- /github/setting-up-and-managing-your-github-user-account/managing-your-membership-in-organizations/managing-your-scheduled-reminders
shortTitle: Manage scheduled reminders
---
## Über geplante Erinnerungen für Benutzer
Geplante Erinnerungen werden verwendet, um sicherzustellen, dass Benutzer sich auf die wichtigsten Review-Anforderungen konzentrieren, die ihre Aufmerksamkeit erfordern. Geplante Erinnerungen für Pull Requests senden Dir in Slack eine Nachricht mit offenen Pull Requests, die Deinen Review zu einem bestimmten Zeitpunkt benötigen. Du kannst beispielsweise planmäßige Erinnerungen so einrichten, dass sie Dir jeden Morgen um 10 Uhr eine Nachricht in Slack zusenden über Pull Requests, die von Dir oder einem Deiner Teams überprüft werden müssen.
Für bestimmte Ereignisse kannst Du auch Echtzeit-Alarmierung für geplante Erinnerungen einrichten. Echtzeit-Alarme werden in Deinen Slack-Kanal gesendet, sobald ein wichtiges Ereignis stattfindet, beispielsweise wenn Du einem Review zugewiesen wirst.
Du kannst geplante Erinnerungen für persönliche oder für Team-Review-Anfragen für Pull Requests in Organisationen festlegen, in denen Du Mitglied bist. Bevor Du eine geplante Erinnerung für Dich selbst erstellen kannst, muss ein Organisationsinhaber Deinen Slack-Arbeitsbereich autorisieren. Weitere Informationen findest Du unter „[Geplante Erinnerungen für Deine Organisation verwalten](/organizations/managing-organization-settings/managing-scheduled-reminders-for-your-organization)."
{% data reusables.reminders.scheduled-reminders-limitations %}
## Geplante Erinnerungen für Dein Benutzerkonto erstellen
{% data reusables.user_settings.access_settings %}
{% data reusables.reminders.scheduled-reminders %}
![Schaltfläche „Scheduled reminders" (Geplante Erinnerungen)](/assets/images/help/profile/scheduled-reminders-profile.png)
3. Neben der Organisation, für die Du Erinnerungen planen möchtest, klicke auf **Edit** (Bearbeiten). ![Schaltfläche „Scheduled reminders edit" (geplante Erinnerungen bearbeiten)](/assets/images/help/settings/scheduled-reminders-org-choice.png)
{% data reusables.reminders.add-reminder %}
{% data reusables.reminders.authorize-slack %}
{% data reusables.reminders.days-dropdown %}
{% data reusables.reminders.times-dropdowns %}
8. Um optional geplante Erinnerungen für Reviews zu erhalten, die Dir zugewiesen wurden, wähle **Review requests assigned to you** (Review-Anforderungen, die Dir zugewiesen wurden). ![Kontrollfeld „Review requests assigned to you" (Dir zugewiesene Review-Anforderungen)](/assets/images/help/profile/scheduled-reminders-your-requests.png)
9. Um optional geplante Erinnerungen für Reviews zu erhalten, die einem Team zugewiesen wurden, in dem Du Mitglied bist, wähle **Review requests assigned to your team** (Review-Anforderungen, die Deinem Team zugewiesen wurden). ![Kontrollfeld „Review requests assigned to your team" (Deinem Team zugewiesene Review-Anforderungen)](/assets/images/help/profile/scheduled-reminders-your-team-requests.png)
{% data reusables.reminders.real-time-alerts %}
![Kontrollfeld „Enable real-time alerts" (Echtzeit-Alarme aktivieren)](/assets/images/help/settings/scheduled-reminders-real-time-alerts-personal.png)
{% data reusables.reminders.create-reminder %}
## Geplante Erinnerungen für Dein Benutzerkonto verwalten
{% data reusables.user_settings.access_settings %}
{% data reusables.reminders.scheduled-reminders %}
![Schaltfläche „Scheduled reminders" (Geplante Erinnerungen)](/assets/images/help/profile/scheduled-reminders-profile.png)
3. Klicke neben der Organisation, für die Du geplante Erinnerungen bearbeiten möchtest, auf **Edit** (Bearbeiten). ![Schaltfläche „Scheduled reminders edit" (geplante Erinnerungen bearbeiten)](/assets/images/help/settings/scheduled-reminders-org-choice.png)
{% data reusables.reminders.edit-page %}
{% data reusables.reminders.update-buttons %}
## Geplante Erinnerungen für Dein Benutzerkonto löschen
{% data reusables.user_settings.access_settings %}
{% data reusables.reminders.scheduled-reminders %}
![Schaltfläche „Scheduled reminders" (Geplante Erinnerungen)](/assets/images/help/profile/scheduled-reminders-profile.png)
3. Klicke neben der Organisation, für die Du geplante Erinnerungen löschen möchtest, auf **Edit** (Bearbeiten). ![Schaltfläche „Scheduled reminders edit" (geplante Erinnerungen bearbeiten)](/assets/images/help/settings/scheduled-reminders-org-choice.png)
{% data reusables.reminders.delete %}
## Weiterführende Informationen
- „[Geplante Erinnerungen für Deine Organisation verwalten](/organizations/managing-organization-settings/managing-scheduled-reminders-for-your-organization)"
- „[Geplante Erinnerungen für Dein Team verwalten](/organizations/organizing-members-into-teams/managing-scheduled-reminders-for-your-team)"

View File

@@ -1,29 +0,0 @@
---
title: Mitgliedschaft in einer Organisation veröffentlichen oder ausblenden
intro: 'Wenn Du öffentlich mitteilen möchtest, zu welchen Organisationen Du gehörst, kannst Du die Avatare der Organisationen in Deinem Profil anzeigen.'
redirect_from:
- /articles/publicizing-or-concealing-organization-membership/
- /articles/publicizing-or-hiding-organization-membership
- /github/setting-up-and-managing-your-github-user-account/publicizing-or-hiding-organization-membership
- /github/setting-up-and-managing-your-github-user-account/managing-your-membership-in-organizations/publicizing-or-hiding-organization-membership
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Accounts
shortTitle: Show or hide membership
---
![Feld „Organizations“ (Organisationen) im Profil](/assets/images/help/profile/profile_orgs_box.png)
## Sichtbarkeit Deiner Organisationsmitgliedschaft ändern
{% data reusables.profile.access_org %}
{% data reusables.user_settings.access_org %}
{% data reusables.organizations.people %}
4. Suche in der Liste der Mitglieder Deinen Benutzernamen. Wenn die Liste sehr umfangreich ist, kannst Du Deinen Benutzernamen über das Suchfeld finden. ![Suchfeld für Organisationsmitglieder](/assets/images/help/organizations/member-search-box.png)
5. Wähle im Menü rechts neben Deinem Benutzernamen eine neue Option für die Sichtbarkeit aus:
- Um Deine Mitgliedschaft zu veröffentlichen, wähle **Public** (Öffentlich) aus.
- Um Deine Mitgliedschaft auszublenden, wähle **Private** (Privat) aus. ![Link für Sichtbarkeit der Organisationsmitglieder](/assets/images/help/organizations/member-visibility-link.png)

View File

@@ -1,33 +0,0 @@
---
title: Dich selbst aus einer Organisation entfernen
intro: Als externer Mitarbeiter oder Mitglied einer Organisation kannst Du die Organisation jederzeit aus eigener Initiative verlassen.
redirect_from:
- /articles/how-do-i-remove-myself-from-an-organization/
- /articles/removing-yourself-from-an-organization
- /github/setting-up-and-managing-your-github-user-account/removing-yourself-from-an-organization
- /github/setting-up-and-managing-your-github-user-account/managing-your-membership-in-organizations/removing-yourself-from-an-organization
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Accounts
shortTitle: Leave an organization
---
{% ifversion fpt or ghec %}
{% warning %}
**Warnung:** Wenn Sie derzeit innerhalb Ihrer Organisation für die Zahlung der Nutzung von {% data variables.product.product_name %} verantwortlich sind, werden die für Ihre Organisation hinterlegten Abrechnungsinformationen durch Ihr Verlassen der Organisation **nicht** automatisch aktualisiert. Wenn Du Zahlungsverantwortlicher bist, **musst Du** den Organisationsinhaber oder einen anderen Abrechnungsmanager der Organisation bitten, die [Zahlungsmethode der Organisation zu aktualisieren](/articles/adding-or-editing-a-payment-method).
Weitere Informationen findest Du unter „[Inhaberschaft an einer Organisation übertragen](/articles/transferring-organization-ownership).“
{% endwarning %}
{% endif %}
{% data reusables.user_settings.access_settings %}
{% data reusables.user_settings.organizations %}
3. Suche unter „Organizations“ (Organisationen) die Organisation, die Du verlassen möchtest, und klicken Sie auf **Leave** (Verlassen). ![Schaltfläche „Leave organization“ (Organisation verlassen) mit angezeigten Rollen](/assets/images/help/organizations/context-leave-organization-with-roles-shown.png)

View File

@@ -1,29 +0,0 @@
---
title: Von einer Organisation die Genehmigung für OAuth-Apps anfordern
intro: 'Organisationsmitglieder können von einem Inhaber die Genehmigung für den Zugriff auf Organisationsressourcen für {% data variables.product.prodname_oauth_app %}s anfordern.'
redirect_from:
- /articles/requesting-organization-approval-for-third-party-applications/
- /articles/requesting-organization-approval-for-your-authorized-applications/
- /articles/requesting-organization-approval-for-oauth-apps
- /github/setting-up-and-managing-your-github-user-account/requesting-organization-approval-for-oauth-apps
- /github/setting-up-and-managing-your-github-user-account/managing-your-membership-in-organizations/requesting-organization-approval-for-oauth-apps
versions:
fpt: '*'
ghec: '*'
topics:
- Accounts
shortTitle: Request OAuth App approval
---
## Von einer Organisation die Genehmigung für eine {% data variables.product.prodname_oauth_app %} anfordern, die Sie bereits für Ihr persönliches Konto zugelassen haben
{% data reusables.user_settings.access_settings %}
{% data reusables.user_settings.access_applications %}
{% data reusables.user_settings.access_authorized_oauth_apps %}
3. Klicke in der Liste der Anwendungen auf den Namen der {% data variables.product.prodname_oauth_app %}, für die Du Zugriff anfordern möchtest. ![Schaltfläche „View application" (Anzeigen der Anwendung)](/assets/images/help/settings/settings-third-party-view-app.png)
4. Klicke neben der Organisation, von der Du Zugriff auf die {% data variables.product.prodname_oauth_app %} anfordern möchtest, auf **Request access** (Zugriff anfordern). ![Schaltfläche „Request access" (Anfordern des Zugriffs)](/assets/images/help/settings/settings-third-party-request-access.png)
5. Lies die Informationen zum Anfordern des {% data variables.product.prodname_oauth_app %}-Zugriffs, und klicke dann auf **Request approval from owners** (Genehmigung von Inhabern anfordern). ![Schaltfläche „Request approval" (Beantragen der Genehmigung)](/assets/images/help/settings/oauth-access-request-approval.png)
## Weiterführende Informationen
- „[Informationen zu Einschränkungen für den {% data variables.product.prodname_oauth_app %}-Zugriff](/articles/about-oauth-app-access-restrictions)“

View File

@@ -1,28 +0,0 @@
---
title: Rollen von Personen in einer Organisation anzeigen
intro: 'Du kannst eine Liste der Personen in Deiner Organisation anzeigen und nach deren Rollen filtern. For more information on organization roles, see "[Roles in an organization](/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization)."'
redirect_from:
- /articles/viewing-people-s-roles-in-an-organization
- /articles/viewing-peoples-roles-in-an-organization
- /github/setting-up-and-managing-your-github-user-account/viewing-peoples-roles-in-an-organization
- /github/setting-up-and-managing-your-github-user-account/managing-your-membership-in-organizations/viewing-peoples-roles-in-an-organization
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- Accounts
shortTitle: View people in an organization
---
{% note %}
**Hinweis:** Du musst ein Organisationsmitglied sein, um die Rollen von Personen in Deiner Organisation anzeigen zu können.
{% endnote %}
{% data reusables.profile.access_org %}
{% data reusables.user_settings.access_org %}
{% data reusables.organizations.people %}
4. Es wird eine Liste der Personen in Deiner Organisation angezeigt. Klicke zum Filtern der Liste nach Rolle auf **Role** (Rolle), und wähle die gewünschte Rolle aus. ![Auswahl der Rolle per Klick](/assets/images/help/organizations/view-list-of-people-in-org-by-role.png)

View File

@@ -1,212 +0,0 @@
---
title: Abhängigkeiten zwischenspeichern um Workflows zu beschleunigen
shortTitle: Abhängigkeiten „cachen“ (zwischenspeichern)
intro: 'Um Deine Workflows schneller und effizienter zu gestalten, kannst Du Caches für Abhängigkeiten und andere häufig wiederverwendete Dateien erstellen und verwenden.'
redirect_from:
- /github/automating-your-workflow-with-github-actions/caching-dependencies-to-speed-up-workflows
- /actions/automating-your-workflow-with-github-actions/caching-dependencies-to-speed-up-workflows
- /actions/configuring-and-managing-workflows/caching-dependencies-to-speed-up-workflows
- /actions/guides/caching-dependencies-to-speed-up-workflows
versions:
fpt: '*'
ghec: '*'
type: tutorial
topics:
- Workflows
---
## Informationen zum Zwischenspeichern von Workflow-Abhängigkeiten
Workflow-Läufe verwenden häufig dieselben Ausgaben oder heruntergeladenen Abhängigkeiten in aufeinanderfolgenden Durchläufen. Tools zur Verwaltung von Paketen und Abhängigkeiten wie beispielsweise Maven, Gradle, npm und Yarn halten einen lokalen Cache mit heruntergeladenen Abhängigkeiten.
Jobs bei {% data variables.product.prodname_dotcom %}-gehosteten Läufern beginnen in einer sauberen virtuellen Umgebung und müssen Abhängigkeiten jedes Mal herunterladen. Dies führt zu erhöhter Netzwerkauslastung, längerer Laufzeit und erhöhten Kosten. Um die Zeit zum Neuerstellen dieser Dateien einzusparen, kann {% data variables.product.prodname_dotcom %} in Workflows häufig verwendete Abhängigkeiten zwischenspeichern.
Um Abhängigkeiten für einen Job zu cachen, musst du die `Cache`-Aktion von {% data variables.product.prodname_dotcom %} verwenden. Die Aktion ruft einen Cache ab, der durch einen eindeutigen Schlüssel identifiziert wurde. Weitere Informationen findest Du unter [`Aktionen/Cache`](https://github.com/actions/cache).
If you are caching Ruby gems, instead consider using the Ruby maintained action, which can cache bundle installs on initiation. For more information, see [`ruby/setup-ruby`](https://github.com/ruby/setup-ruby#caching-bundle-install-automatically).
To cache and restore dependencies for npm, Yarn, or pnpm, you can use the [`actions/setup-node` action](https://github.com/actions/setup-node).
Gradle and Maven caching is available with [`actions/setup-java` action](https://github.com/actions/setup-java).
{% warning %}
**Warnung**: Wir empfehlen Ihnen, keine sensiblen Informationen im Cache von öffentlichen Repositories zu speichern. Sensible Informationen umfassen beispielsweise Zugriffstoken oder Anmeldedaten, die in einer Datei im Cache-Pfad gespeichert sind. Auch Kommandozeilen-Programme (CLI) wie `docker login` können Zugangsdaten in einer Konfigurationsdatei speichern. Jeder mit Lesezugriff kann einen Pull-Request auf ein Repository erstellen und auf den Inhalt des Caches zugreifen. Forks eines Repositorys können auch Pull-Requests auf den base branch (Basiszweig) erstellen und auf Caches im Basiszweig zugreifen.
{% endwarning %}
## Vergleich: Artefakte v/s Zwischenspeicherung von Abhängigkeiten
Artefakte und Caching sind ähnlich, da sie die Möglichkeit bieten, Dateien auf {% data variables.product.prodname_dotcom %} zu speichern, aber die beiden Funktionalitäten bieten verschiedene Anwendungsfälle und dürfen nicht miteinander verwechselt werden.
- Verwende Caching, wenn Du Dateien wiederverwenden willst, die sich zwischen Jobs oder Workflow-Läufen nicht oft ändern.
- Verwende Artefakte, wenn Du die von einem Job erzeugten Dateien speichern willst, um sie nach dem Ende eines Workflows anzuzeigen. Weitere Informationen findest Du unter "[Workflow-Daten mittels Artefakten persistieren](/github/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)."
## Einschränkungen für den Zugriff auf einen Cache
Mit `v2-` der `Cache-` -Aktion können Sie in Workflows auf den Cache zugreifen, die von jedem Ereignis ausgelöst werden, das über eine `GITHUB_REF`verfügt. Wenn Sie `v1-` der `-Cache-` -Aktion verwenden, können Sie nur in Workflows auf den Cache zugreifen, `durch pushen` - und `pull_request` -Ereignisse ausgelöst werden, mit Ausnahme des `pull_request` `` -Ereignis geschlossen. Weitere Informationen findest Du unter "[Ereignisse, die Workflows auslösen](/actions/reference/events-that-trigger-workflows)."
A workflow can access and restore a cache created in the current branch, the base branch (including base branches of forked repositories), or the default branch (usually `main`). For example, a cache created on the default branch would be accessible from any pull request. Also, if the branch `feature-b` has the base branch `feature-a`, a workflow triggered on `feature-b` would have access to caches created in the default branch (`main`), `feature-a`, and `feature-b`.
Access restrictions provide cache isolation and security by creating a logical boundary between different branches. For example, a cache created for the branch `feature-a` (with the base `main`) would not be accessible to a pull request for the branch `feature-b` (with the base `main`).
Multiple workflows within a repository share cache entries. A cache created for a branch within a workflow can be accessed and restored from another workflow for the same repository and branch.
## Verwenden der `-Cache-` -Aktion
Die Aktion `-cache-` wird versuchen, einen Cache basierend auf dem `key` (Schlüssel), den Du angibst, wiederherzustellen. Wenn die Aktion einen Cache findet, stellt die Aktion die zwischengespeicherten Dateien in dem `path` wieder her, den Du konfigurierst.
Wenn es keine exakte Übereinstimmung gibt, erzeugt die Aktion einen neuen Cache-Eintrag, wenn der Job erfolgreich abgeschlossen wird. Der neue Cache wird den `key` verwenden, den Du angegeben hast, und enthält die Dateien im Verzeichnis `path`.
Optional kannst Du eine Liste von `restore-keys` angeben, die verwendet werden sollen, wenn der `key` nicht mit einem vorhandenen Cache übereinstimmt. Eine Liste der `restore-keys` ist nützlich, wenn Du einen Cache aus einem anderen Zweig wiederherstellst, da `restore-keys` auch teilweise mit Cache-Schlüsseln übereinstimmen dürfen. Weitere Informationen zum Abgleich von `restore-keys`, siehe "[Einen Cache-Schlüssel abgleichen](#matching-a-cache-key)."
Weitere Informationen findest Du unter [`Aktionen/Cache`](https://github.com/actions/cache).
### Eingabeparameter für die `-Cache-` -Aktion
- `key`: **Erforderlich** Der Schlüssel, der beim Speichern eines Caches erstellt wurde, und der Schlüssel, der zum Suchen nach einem Cache verwendet wird. Kann eine beliebige Kombination von Variablen, Kontextwerten, statischen Strings und Funktionen sein. Schlüssel haben eine maximale Länge von 512 Zeichen und Schlüssel, die die maximale Länge überschreiten, lassen die Aktion fehlschlagen.
- `path`: **Erforderlich** Der Dateipfad auf dem Runner zum Anlegen oder Wiederherstellen des Caches. Der Pfad kann ein absoluter Pfad oder relativ zum Arbeitsverzeichnis sein.
- Pfade können entweder Verzeichnisse oder einzelne Dateien sein, und Glob-Muster werden unterstützt.
- With `v2` of the `cache` action, you can specify a single path, or you can add multiple paths on separate lines. Ein Beispiel:
```
- name: Cache Gradle packages
uses: actions/cache@v2
with:
path: |
~/.gradle/caches
~/.gradle/wrapper
```
- Bei `v1-` der `-Cache-` -Aktion wird nur ein einzelner Pfad unterstützt, und es muss sich um ein Verzeichnis handeln. Eine einzelne Datei kannst Du nicht cachen.
- `restore-keys`: **Optional** Eine geordnete Liste der alternativen Schlüssel, die zum Finden des Caches verwendet werden sollen, falls `key` keinen Treffer gebracht hat.
### Ausgangsparameter für die Cache-Aktion
- `Cache-Treffer`: Ein boolescher Wert, um eine genaue Übereinstimmung für den Schlüssel anzugeben.
### Beispiel für die Verwendung der `-Cache-` -Aktion
Dieses Beispiel erzeugt einen neuen Cache, wenn sich die Pakete in `package-lock.json` ändern oder wenn das Betriebssystem des Runners wechselt. Das folgende Beispiel verwendet Kontexte und Ausdrücke, um einen Schlüssel zu erzeugen, der eine Kennung des Runner-Betriebssystems und einen SHA-256-Hash der Datei `package-lock.json` enthält.
{% raw %}
```yaml{:copy}
name: Caching with npm
on: push
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Cache node modules
uses: actions/cache@v2
env:
cache-name: cache-node-modules
with:
# npm cache files are stored in `~/.npm` on Linux/macOS
path: ~/.npm
key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-build-${{ env.cache-name }}-
${{ runner.os }}-build-
${{ runner.os }}-
- name: Install Dependencies
run: npm install
- name: Build
run: npm build
- name: Test
run: npm test
```
{% endraw %}
Wenn `key` mit einem existierenden Cache übereinstimmt, wird das als „cache hit“ (Cache-Treffer) bezeichnet, und die Aktion stellt die zwischengespeicherten Dateien wieder her und legt sie in den `path`.
Wenn `key` nicht mit einem existierenden Cache übereinstimmt, wird das als „cache miss“ (Cache-Fehlschlag) bezeichnet. Wenn der Job erfolgreich abgeschlossen ist, wird ein neuer Cache erstellt. Wenn ein Cache-Fehlschlag auftritt, sucht die Aktion mittels der alternativen Schlüssel gemäß `restore-keys` weiter.
1. Wenn du `restore-keys` bereitstellst, sucht die `cache`-Aktion sequentiell nach Caches, die mit der Liste `restore-keys` übereinstimmen.
- Wenn es eine exakte Übereinstimmung gibt, stellt die Aktion die Dateien aus dem Cache in das Verzeichnis `path` wieder her.
- Wenn es keine exakten Übereinstimmungen gibt, sucht die Aktion nach partiellen Übereinstimmungen der „restore keys“ (Wiederherstellungs-Scvhlüssel). Wenn die Aktion eine partielle Übereinstimmung findet, wird der aktuellste Cache in das Verzeichnis `path` wiederhergestellt.
1. Die `Cache-` Aktion abgeschlossen wird, und der nächste Workflowschritt im Auftrag wird ausgeführt.
1. Wenn der Job erfolgreich abgeschlossen ist, erstellt die Aktion einen neuen Cache mit dem Inhalt des Verzeichnisses `path`.
Um Dateien in mehr als einem Verzeichnis zu cachen, benötigst Du einen step (Schritt), der die Aktion [`cache`](https://github.com/actions/cache) für jedes Verzeichnis verwendet. Sobald Du einen Cache erstellt hast, kannst Du den Inhalt eines bereits existierenden Caches nicht ändern, aber Du kannst einen neuen Cache mit einem neuen key (Schlüssel) erstellen.
### Cache-Keys aus Kontexten erstellen
Ein Cache-Key (Cache-Schlüssel) kann Kontexte, Funktionen, Literale und Operatoren enthalten, die von {% data variables.product.prodname_actions %} unterstützt werden. For more information, see "[Expressions](/actions/learn-github-actions/expressions)."
Wenn Du zum Erstellen eines `key`s Ausdrücke verwendest, kannst Du automatisch einen neuen Cache zu erstellen, sobald sich die Abhängigkeiten geändert haben. Zum Beispiel kannst Du einen `key` mittels eines Ausdrucks erstellen, der den Hash-Code einer npm-Datei `package-lock.json` errechnet.
{% raw %}
```yaml
npm-${{ hashFiles('package-lock.json') }}
```
{% endraw %}
{% data variables.product.prodname_dotcom %} wertet den Ausdruck aus `hash "package-lock.json"` um daraus den endgültigen `key` abzuleiten.
```yaml
npm-d5ea0750
```
## Einen Cache-Key abgleichen
Der `-Cache` Aktion sucht zuerst nach Cachetreffern nach `Schlüssel` und `Wiederherstellungsschlüssel n` in der Verzweigung, die die Workflowausführung enthält. Wenn in der aktuellen Verzweigung keine Treffer vorhanden sind, sucht der `-Cache` Aktion nach `Schlüssel` und `Wiederherstellungsschlüssel, die in den übergeordneten Zweigen und vorgelagerten Zweigen` .
Du kannst eine Liste der `restore-keys` angeben, die verwendet werden sollen, wenn auf `key` ein Cache-Fehler auftritt. Du kannst mehrere `restore-keys` erstellen, die von den spezifischsten zum am wenigsten spezifischen sortiert sind. Die Aktion `cache` sucht nach `restore-keys` in sequenzieller Reihenfolge. Wenn ein Schlüssel nicht direkt übereinstimmt, sucht die Aktion nach Schlüsseln denen der Restore-Key vorangestellt ist. Wenn mehrere Teiltreffer für einen Restore-Key vorhanden sind, gibt die Aktion den zuletzt erstellten Cache zurück.
### Beispiel für die Verwendung mehrerer Restore-Keys
{% raw %}
```yaml
restore-keys: |
npm-foobar-${{ hashFiles('package-lock.json') }}
npm-foobar-
npm-
```
{% endraw %}
Der Runner bewertet die Ausdrücke, die sich in folgende `restore-keys` auflösen lassen:
{% raw %}
```yaml
restore-keys: |
npm-foobar-d5ea0750
npm-foobar-
npm-
```
{% endraw %}
Der Restore-Key `npm-foobar-` passt auf jeden Schlüssel, der mit dem String `npm-foobar-` beginnt. Zum Beispiel passen zu ihm die beiden Schlüssel `npm-foobar-fd3052de` und `npm-foobar-a9b253ff`. Der Cache mit dem neuesten Erstellungsdatum wird verwendet. Die Schlüssel in diesem Beispiel werden in der folgenden Reihenfolge durchsucht:
1. **`npm-foobar-d5ea0750`** passt zu einem bestimmten Hash.
1. **`npm-foobar-`** deckt alle Cache-Schlüssel ab, die mit `npm-foobar-` beginnen.
1. **`npm-`** deckt alle Cache-Schlüssel ab, die mit `npm-` beginnen.
#### Beispiel für die Suchpriorität
```yaml
key:
npm-feature-d5ea0750
restore-keys: |
npm-feature-
npm-
```
For example, if a pull request contains a `feature` branch (the current scope) and targets the default branch (`main`), the action searches for `key` and `restore-keys` in the following order:
1. Schlüssel `npm-feature-d5eaa0750` im Zweig `feature`
1. Schlüssel `npm-feature-` im Zweig `feature`
2. Schlüssel `npm-` im Zweig `feature`
1. Key `npm-feature-d5ea0750` in the `main` branch scope
3. Key `npm-feature-` in the `main` branch scope
4. Key `npm-` in the `main` branch scope
## Nutzungsbeschränkungen und Räumungsrichtlinien
{% data variables.product.prodname_dotcom %} wird alle Cache-Einträge entfernen, auf die seit mehr als 7 Tagen nicht zugegriffen wurde. Es gibt keine Grenze für die Anzahl der Caches, die du speichern kannst, aber die Gesamtgröße aller Caches in einem Repository ist auf 5 GB begrenzt. Wenn du dieses Limit überschreitest, wird {% data variables.product.prodname_dotcom %} deinen Cache speichern, aber damit beginnen, Caches zu löschen, bis die Gesamtgröße kleiner als 5 GB ist.

View File

@@ -1,18 +0,0 @@
---
title: Advanced guides
shortTitle: Advanced guides
intro: 'How to cache dependencies, store output as artifacts, and use the GitHub CLI in workflows.'
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
redirect_from:
- /actions/guides/caching-and-storing-workflow-data
children:
- /caching-dependencies-to-speed-up-workflows
- /storing-workflow-data-as-artifacts
- /using-github-cli-in-workflows
---
{% data reusables.actions.ae-beta %}

View File

@@ -1,256 +0,0 @@
---
title: Storing workflow data as artifacts
shortTitle: Storing workflow artifacts
intro: Mit Artefakten kannst Du Daten zwischen Aufträgen in einem Workflow freigeben und Daten nach Abschluss des Workflows speichern.
redirect_from:
- /articles/persisting-workflow-data-using-artifacts
- /github/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts
- /actions/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts
- /actions/configuring-and-managing-workflows/persisting-workflow-data-using-artifacts
- /actions/guides/storing-workflow-data-as-artifacts
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: tutorial
topics:
- Workflows
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
## Informationen zu Workflow-Artefakten
Artefakte erlauben es dir, Daten nach dem Job-Abschluss abzuspeichern und diese Daten an einen anderen Job im selben Workflow weiterzugeben. Ein Artefakt ist eine Datei oder eine Dateisammlung, die während einer Workflow-Ausführung erstellt wird. Zum Beispiel kannst Du Artefakte verwenden, um Deine Build- und Testausgabe zu speichern, nachdem ein Workflow-Lauf beendet ist. {% data reusables.actions.reusable-workflow-artifacts %}
{% data reusables.github-actions.artifact-log-retention-statement %} The retention period for a pull request restarts each time someone pushes a new commit to the pull request.
Dies sind einige der gängigen Artefakte, die du hochladen kannst:
- Protokolldateien und Coredumps
- Testergebnisse, Fehler und Screenshots
- Binäre oder komprimierte Dateien
- Ergebnisse zur Stresstest-Leistungsausgabe und Codeabdeckung
{% ifversion fpt or ghec %}
Das Speichern von Artefakten verwendet Speicherplatz auf {% data variables.product.product_name %}. {% data reusables.github-actions.actions-billing %} Weitere Informationen findest Du unter „[Abrechnung für {% data variables.product.prodname_actions %} verwalten](/billing/managing-billing-for-github-actions)“.
{% else %}
Artefakte verfallen automatisch nach 90 Tagen, aber du kannst jederzeit den verwendeten Speicher auf {% data variables.product.prodname_actions %} wieder verfügbar machen, indem du Artefakte löschst, bevor sie auf {% data variables.product.product_name %} ablaufen.
{% endif %}
Artefakte werden während eines Workflow-Laufs hochgeladen und Du kannst den Namen und die Größe eines Artefakts in der Benutzeroberfläche anzeigen. Wenn ein Artefakt mit der {% data variables.product.product_name %}-Oberfläche heruntergeladen wird, werden alle Dateien, die als Teil des Artefakts einzeln hochgeladen wurden, zusammen in eine einzige Datei gezippt. Die Abrechnung erfolgt anhand der Größe des hochgeladenen Artefakts und nicht der Größe der Zip-Datei erfolgt.
{% data variables.product.product_name %} bietet zwei Aktionen, über die Sie Build-Artefakte hoch- und herunterladen können. For more information, see the {% ifversion fpt or ghec %}[actions/upload-artifact](https://github.com/actions/upload-artifact) and [download-artifact](https://github.com/actions/download-artifact) actions{% else %} `actions/upload-artifact` and `download-artifact` actions on {% data variables.product.product_location %}{% endif %}.
Daten zwischen Aufträgen freigeben:
* **Dateien hochladen**: Gib der hochgeladenen Datei einen Namen und lade die Daten hoch, bevor der Job endet.
* **Dateien herunterladen**: Du kannst nur Artefakte herunterladen, die während des gleichen Workflow-Laufs hochgeladen wurden. Wenn Du eine Datei herunterlädst, kannst Du sie mit Namen referenzieren.
Die Steps („Schritte“) eines Jobs teilen sich die selbe Umgebung auf der Runner-Maschine, laufen aber in ihren eigenen individuellen Prozessen. Mithilfe von Ein- und Ausgaben können Sie Daten zwischen den Schritten in einem Auftrag weitergeben. Weitere Informationen zu Ein- und Ausgaben findest Du unter „[Metadatensyntax für {% data variables.product.prodname_actions %}](/articles/metadata-syntax-for-github-actions)“.
## Build- und Testartefakte hochladen
Du kannst einen Workflow für kontinuierliche Integration (CI) erstellen, um Deinen Code zu bauen und zu testen. For more information about using {% data variables.product.prodname_actions %} to perform CI, see "[About continuous integration](/articles/about-continuous-integration)."
Durch die Ergebnisse der Erstellung und des Tests Deines Codes werden oft zum Debuggen von Testfehlern einsetzbare Dateien und bereitstellbarer Produktionscode erstellt. Du kannst einen Workflow konfigurieren, um den per Push-Vorgang an Dein Repository übertragenen Code zu erstellen und zu testen und um einen erfolgreichen oder fehlerhaften Status zu melden. Du kannst die Build- und Testausgabe hochladen, um sie für Bereitstellungen, zum Debuggen fehlerhafter Tests oder von Abstürzen und zum Anzeigen der Testsuite-Abdeckung zu verwenden.
Du kannst die Aktion `upload-artifact` verwenden um Artefakte hochzuladen. Beim Hochladen eines Artefakts können Sie eine einzelne Datei oder ein Verzeichnis oder mehrere Dateien oder Verzeichnisse angeben. Sie können auch bestimmte Dateien oder Verzeichnisse ausschließen und Platzhaltermuster verwenden. Es wird empfohlen, einen Namen für ein Artefakt bereitzustellen, aber wenn kein Name angegeben wird, wird `Artefakt` als Standardname verwendet. For more information on syntax, see the {% ifversion fpt or ghec %}[actions/upload-artifact](https://github.com/actions/upload-artifact) action{% else %} `actions/upload-artifact` action on {% data variables.product.product_location %}{% endif %}.
### Beispiel
Zum Beispiel kann Dein Projektarchiv oder eine Webanwendung SASS- und TypeScript-Dateien enthalten, die Du in CSS und JavaScript konvertieren musst. Falls Dein Build-Konfiguration die kompilierten Dateien im Verzeichnis `dist` ausgibt, würdest Du die im Verzeichnis `dist` enthaltenen Dateien auf Deinem Webanwendungsserver bereitstellen, sofern alle Tests erfolgreich abgeschlossen werden.
```
|-- hello-world (repository)
| └── dist
| └── tests
| └── src
| └── sass/app.scss
| └── app.ts
| └── output
| └── test
|
```
In diesem Beispiel wird gezeigt, wie Sie einen Workflow für ein Node.js-Projekt erstellen, das den Code im src-Verzeichnis `erstellt` und die Tests im `tests`-Verzeichnis ausführt. Wenn `npm test` ausgeführt wird, wird im Verzeichnis `output/test/` ein Bericht zur Codeabdeckung mit dem Namen `code-coverage.html` erstellt und gespeichert.
Der Workflow lädt die Produktionsartefakte in das `dist` Verzeichnis, schließt jedoch alle Markdowndateien aus. Es lädt auch die `code-coverage.html` Bericht als ein weiteres Artefakt.
```yaml{:copy}
Name: Node CI
on: [push]
jobs:
build_and_test:
läuft auf: ubuntu-latest
schritte:
- name: Checkout repository
verwendet: actions/checkout@v2
- name: npm install, build, and test
run: |
npm installieren sie
npm run build --if-present
npm test
- name: Archiv production artifacts
uses: actions/upload-artifact@v2
with:
name: dist-without-markdown
path: |
dist
!dist/**/*md
- Name: Archivcodeabdeckungsergebnisse
verwendet: Aktionen/Upload-artifact@v2
mit:
Name: code-coverage-report
pfad: output/test/code-coverage.html
```
## Configuring a custom artifact retention period
You can define a custom retention period for individual artifacts created by a workflow. When using a workflow to create a new artifact, you can use `retention-days` with the `upload-artifact` action. This example demonstrates how to set a custom retention period of 5 days for the artifact named `my-artifact`:
```yaml{:copy}
- name: 'Upload Artifact'
uses: actions/upload-artifact@v2
with:
name: my-artifact
path: my_file.txt
retention-days: 5
```
The `retention-days` value cannot exceed the retention limit set by the repository, organization, or enterprise.
## Artefakte herunterladen oder löschen
During a workflow run, you can use the [`download-artifact`](https://github.com/actions/download-artifact) action to download artifacts that were previously uploaded in the same workflow run.
After a workflow run has been completed, you can download or delete artifacts on {% data variables.product.prodname_dotcom %} or using the REST API. For more information, see "[Downloading workflow artifacts](/actions/managing-workflow-runs/downloading-workflow-artifacts)," "[Removing workflow artifacts](/actions/managing-workflow-runs/removing-workflow-artifacts)," and the "[Artifacts REST API](/rest/reference/actions#artifacts)."
### Herunterladen von Artefakten während einer Workflowausführung
The [`actions/download-artifact`](https://github.com/actions/download-artifact) action can be used to download previously uploaded artifacts during a workflow run.
{% note %}
**Hinweis:** Sie können nur Artefakte in einem Workflow herunterladen, die während desselben Workflowlaufs hochgeladen wurden.
{% endnote %}
Geben Sie den Namen eines Artefakts an, um ein einzelnes Artefakt herunterzuladen. Wenn Sie ein Artefakt hochgeladen haben, ohne einen Namen anzugeben, lautet der Standardname `Artefakt`.
```yaml
- Name: Laden Sie ein einzelnes Artefakt
verwendet: Aktionen/Download-artifact@v2
mit:
Name: my-artifact
```
Sie können auch alle Artefakte in einem Workflow herunterladen, der ausgeführt wird, indem Sie keinen Namen angeben. Dies kann nützlich sein, wenn Sie mit vielen Artefakten arbeiten.
```yaml
- Name: Laden Sie alle Workflow-Ausführungsartefakte
verwendet: Aktionen/Download-artifact@v2
```
Wenn Sie alle Artefakte einer Workflowausführung herunterladen, wird ein Verzeichnis für jedes Artefakt mit seinem Namen erstellt.
For more information on syntax, see the {% ifversion fpt or ghec %}[actions/download-artifact](https://github.com/actions/download-artifact) action{% else %} `actions/download-artifact` action on {% data variables.product.product_location %}{% endif %}.
## Daten zwischen Aufträgen in einem Workflow weitergeben
Du kannst die Aktionen `upload-artifact` und `download-artifact` verwenden, um innerhalb eines Workflows Daten zwischen Jobs auszutauschen. In diesem Beispiel-Workflow wird veranschaulicht, wie Daten zwischen Aufträgen im selben Workflow weitergegeben werden. For more information, see the {% ifversion fpt or ghec %}[actions/upload-artifact](https://github.com/actions/upload-artifact) and [download-artifact](https://github.com/actions/download-artifact) actions{% else %} `actions/upload-artifact` and `download-artifact` actions on {% data variables.product.product_location %}{% endif %}.
Von den Artefakten eines vorherigen Auftrags abhängige Aufträge müssen auf den erfolgreichen Abschluss des abhängigen Auftrags warten. Bei diesem Workflow kommt das Stichwort `needs` zum Einsatz, um sicherzustellen, dass `job_1`, `job_2` und `job_3` sequenziell ausgeführt werden. Beispielsweise schreibt `job_2` vor, dass `job_1` die Syntax `needs: job_1` verwendet.
Auftrag 1 führt die folgenden Schritte durch:
- Führt eine mathematische Berechnung aus und speichert das Ergebnis in einer Textdatei namens `math-homework.txt`.
- Uses the `upload-artifact` action to upload the `math-homework.txt` file with the artifact name `homework`.
Auftrag 2 verwendet das Ergebnis des vorherigen Auftrags:
- Lädt das im vorherigen Auftrag hochgeladene `homework`-Artefakt herunter. Die Aktion `download-artifact` lädt die Artefakte standardmäßig in das Verzeichnis der Arbeitsoberfläche, in dem der Schritt ausgeführt wird. Du kannst den Eingabeparameter `path` verwenden, um ein anderes Download-Verzeichnis anzugeben.
- Reads the value in the `math-homework.txt` file, performs a math calculation, and saves the result to `math-homework.txt` again, overwriting its contents.
- Lädt die Datei `math-homework.txt` hoch. This upload overwrites the previously uploaded artifact because they share the same name.
Auftrag 3 zeigt das im vorherigen Auftrag hochgeladene Ergebnis an:
- Lädt das `homework`-Artefakt herunter.
- Gibt das Ergebnis der mathematischen Gleichung im Protokoll aus.
Die vollständige, in diesem Workflow-Beispiel durchgeführte mathematische Operation lautet `(3 + 7) x 9 = 90`.
```yaml{:copy}
name: Daten zwischen Jobs
teilen: [push]
Jobs:
job_1:
Name: Hinzufügen von 3 und 7
-Runs-on: ubuntu-latest
Schritte:
- shell: bash
run: |
expr 3 + 7 > math-homework.txt
- Name: Math-Ergebnis für Job 1
verwendet: Aktionen/Upload-artifact@v2
mit:
Name: Hausaufgaben
Pfad: math-homework.txt
job_2:
Name: Multiplizieren mit 9
benötigt: job_1
-Run-on: Windows-neueste
Schritte:
- Name: Download Mathe-Ergebnis für Job 1
verwendet: Aktionen
artifact@v2
/
value='cat math-homework.txt'
expr $value '* 9 > math-homework.txt
- Name: Math-Ergebnis für Job 2
verwendet: aktionen/upload-artifact@v2
mit:
Name: Hausaufgaben
Pfad: math-homework.txt
job_3:
Name: Anzeigeergebnisse
Bedürfnisse: job_2
-Auslauf: macOS-neueste
Schritte:
- Name: Mathematisches Ergebnis für Job 2
verwendet: Aktionen/Download-artifact@v2
mit:
Name: Hausaufgaben
- Name: Drucken sie das Endergebnis
Shell: bash
run: |
value='cat math-homework.txt'
echo Das Ergebnis ist $value
```
The workflow run will archive any artifacts that it generated. For more information on downloading archived artifacts, see "[Downloading workflow artifacts](/actions/managing-workflow-runs/downloading-workflow-artifacts)."
{% ifversion fpt or ghes > 3.0 or ghae or ghec %}
![Workflow, der zum Durchführen mathematischer Operationen Daten zwischen Aufträgen weitergibt](/assets/images/help/repository/passing-data-between-jobs-in-a-workflow-updated.png)
{% else %}
![Workflow, der zum Durchführen mathematischer Operationen Daten zwischen Aufträgen weitergibt](/assets/images/help/repository/passing-data-between-jobs-in-a-workflow.png)
{% endif %}
{% ifversion fpt or ghec %}
## Weiterführende Informationen
- "[ Abrechnung für {% data variables.product.prodname_actions %} verwalten](/billing/managing-billing-for-github-actions)".
{% endif %}

View File

@@ -1,74 +0,0 @@
---
title: Using GitHub CLI in workflows
shortTitle: GitHub CLI in workflows
intro: 'You can script with {% data variables.product.prodname_cli %} in {% data variables.product.prodname_actions %} workflows.'
redirect_from:
- /actions/guides/using-github-cli-in-workflows
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- CLI
- Workflows
type: how_to
---
{% data reusables.actions.ae-beta %}
{% data reusables.cli.cli-learn-more %}
{% data variables.product.prodname_cli %} is preinstalled on all {% data variables.product.prodname_dotcom %}-hosted runners. For each step that uses {% data variables.product.prodname_cli %}, you must set an environment variable called `GITHUB_TOKEN` to a token with the required scopes.
You can execute any {% data variables.product.prodname_cli %} command. For example, this workflow uses the `gh issue comment` subcommand to add a comment when an issue is opened.
```yaml{:copy}
name: Comment when opened
on:
issues:
types:
- opened
jobs:
comment:
runs-on: ubuntu-latest
steps:
- run: gh issue comment $ISSUE --body "Thank you for opening this issue!"
env:
GITHUB_TOKEN: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
ISSUE: {% raw %}${{ github.event.issue.html_url }}{% endraw %}
```
You can also execute API calls through {% data variables.product.prodname_cli %}. For example, this workflow first uses the `gh api` subcommand to query the GraphQL API and parse the result. Then it stores the result in an environment variable that it can access in a later step. In the second step, it uses the `gh issue create` subcommand to create an issue containing the information from the first step.
```yaml{:copy}
name: Report remaining open issues
on:
schedule:
# Daily at 8:20 UTC
- cron: '20 8 * * *'
jobs:
track_pr:
runs-on: ubuntu-latest
steps:
- run: |
numOpenIssues="$(gh api graphql -F owner=$OWNER -F name=$REPO -f query='
query($name: String!, $owner: String!) {
repository(owner: $owner, name: $name) {
issues(states:OPEN){
totalCount
}
}
}
' --jq '.data.repository.issues.totalCount')"
echo 'NUM_OPEN_ISSUES='$numOpenIssues >> $GITHUB_ENV
env:
GITHUB_TOKEN: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
OWNER: {% raw %}${{ github.repository_owner }}{% endraw %}
REPO: {% raw %}${{ github.event.repository.name }}{% endraw %}
- run: |
gh issue create --title "Issue report" --body "$NUM_OPEN_ISSUES issues remaining" --repo $GITHUB_REPOSITORY
env:
GITHUB_TOKEN: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
```

View File

@@ -1,61 +0,0 @@
---
title: Informationen zur fortlaufenden Integration
intro: 'You can create custom continuous integration (CI) workflows directly in your {% data variables.product.prodname_dotcom %} repository with {% data variables.product.prodname_actions %}.'
redirect_from:
- /articles/about-continuous-integration
- /github/automating-your-workflow-with-github-actions/about-continuous-integration
- /actions/automating-your-workflow-with-github-actions/about-continuous-integration
- /actions/building-and-testing-code-with-continuous-integration/about-continuous-integration
- /actions/guides/about-continuous-integration
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: overview
topics:
- CI
shortTitle: Kontinuierliche Integration
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
## Informationen zur fortlaufenden Integration
Bei der Softwarepraktik der fortlaufenden Integration (CI) erfolgen häufige Code-Commits an ein gemeinsames Repository. Code-Commits in kurzen Abständen tragen dazu bei, Fehler frühzeitiger aufzudecken, und verringern die Codemenge, die ein Entwickler auf der Suche nach der Fehlerursache debuggen muss. Durch häufige Code-Aktualisierungen lassen sich zudem Änderungen von verschiedenen Mitgliedern eines Software-Entwicklungsteams leichter zusammenführen. Dies bedeutet einen erheblichen Vorteil für die Entwickler, die sich damit stärker auf das Schreiben des Codes konzentrieren können, statt Fehler debuggen oder Mergekonflikte beheben zu müssen.
Durch einen Code-Commit an das Repository können Sie den Code fortlaufend erstellen und testen, sodass gewährleistet ist, dass der Commit keine Fehler einbringt. Die Tests können beispielsweise Code-Linters (überprüfen Stilformatierungen), Sicherheitsprüfungen, Code-Abdeckung, Funktionstests und andere benutzerdefinierte Prüfungen umfassen.
Zum Erstellen und Testen des Codes ist ein Server erforderlich. Sie können Aktualisierungen lokal erstellen und testen, bevor Sie den Code per Push an ein Repository senden, oder auch einen CI-Server heranziehen, der neue Code-Commits in einem Repository prüft.
## Informationen zur kontinuierlichen Integration mit {% data variables.product.prodname_actions %}
{% ifversion ghae %}CI using {% data variables.product.prodname_actions %} offers workflows that can build the code in your repository and run your tests. Workflows can run on virtual machines hosted by {% data variables.product.prodname_dotcom %}. For more information, see "[About {% data variables.actions.hosted_runner %}s](/actions/using-github-hosted-runners/about-ae-hosted-runners)."
{% else %} CI using {% data variables.product.prodname_actions %} offers workflows that can build the code in your repository and run your tests. Workflows können auf {% data variables.product.prodname_dotcom %}gehosteten virtuellen Maschinen oder auf Computern ausgeführt werden, die Sie selbst hosten. For more information, see "[Virtual environments for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/automating-your-workflow-with-github-actions/virtual-environments-for-github-hosted-runners)" and "[About self-hosted runners](/actions/automating-your-workflow-with-github-actions/about-self-hosted-runners)."
{% endif %}
Sie können den CI-Workflow so konfigurieren, dass er bei einem {% data variables.product.prodname_dotcom %}-Ereignis (z. B. wenn neuer Code per Push in das Repository eingebracht wird), nach einem festen Zeitplan oder bei einem externen Ereignis anhand des Sende-Webhooks des Repositorys ausgeführt wird.
{% data variables.product.product_name %} führt die CI-Tests aus und stellt die Ergebnisse jedes Tests in der Pullanforderung bereit, sodass Sie sehen können, ob die Änderung in Ihrem Zweig einen Fehler verursacht. Sobald alle CI-Tests in einem Workflow bestanden wurden, können die per Push übermittelten Änderungen von einem Teammitglied geprüft oder zusammengeführt werden. Wenn ein Test nicht bestanden wird, liegt die Ursache eventuell in einer Ihrer Änderungen.
Wenn Sie CI in Ihrem Repository einrichten, analysiert {% data variables.product.product_name %} den Code in Ihrem Repository und empfiehlt CI-Workflows basierend auf der Sprache und dem Framework in Ihrem Repository. Wenn Sie beispielsweise [Node.js](https://nodejs.org/en/)verwenden, schlägt {% data variables.product.product_name %} eine Vorlagendatei vor, die Ihre Node.js-Pakete installiert und Ihre Tests ausführt. Sie können die von {% data variables.product.product_name %}vorgeschlagene CI-Workflowvorlage verwenden, die vorgeschlagene Vorlage anpassen oder eine eigene benutzerdefinierte Workflowdatei zum Ausführen der CI-Tests erstellen.
![Screenshot mit vorgeschlagenen Vorlagen für die fortlaufende Integration](/assets/images/help/repository/ci-with-actions-template-picker.png)
Sie können nicht nur ci-Workflows für Ihr Projekt einrichten, sondern auch {% data variables.product.prodname_actions %} verwenden, um Workflows über den gesamten Softwareentwicklungslebenszyklus hinweg zu erstellen. Sie können Ihr Projekt beispielsweise mithilfe von Aktionen bereitstellen, packen oder veröffentlichen. Weitere Informationen finden Sie unter "[über {% data variables.product.prodname_actions %}](/articles/about-github-actions)".
Eine Definition von gebräuchliche Begriffe finden Sie unter "[Kernkonzepte für {% data variables.product.prodname_actions %}](/github/automating-your-workflow-with-github-actions/core-concepts-for-github-actions)".
## Workflow templates
{% data variables.product.product_name %} bietet CI-Workflowvorlagen für eine Vielzahl von Sprachen und Frameworks.
Browse the complete list of CI workflow templates offered by {% data variables.product.company_short %} in the {% ifversion fpt or ghec %}[actions/starter-workflows](https://github.com/actions/starter-workflows/tree/main/ci) repository{% else %} `actions/starter-workflows` repository on {% data variables.product.product_location %}{% endif %}.
## Weiterführende Informationen
{% ifversion fpt or ghec %}
- "[ Abrechnung für {% data variables.product.prodname_actions %} verwalten](/billing/managing-billing-for-github-actions)"
{% endif %}

View File

@@ -1,127 +0,0 @@
---
title: Java bauen und testen mit Ant
intro: 'Du kannst einen Workflow für kontinuierliche Integration (CI) in GitHub-Aktionen erstellen, um Dein Java-Projekt mit Ant zu bauen und zu testen.'
redirect_from:
- /actions/language-and-framework-guides/building-and-testing-java-with-ant
- /actions/guides/building-and-testing-java-with-ant
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: tutorial
topics:
- CI
- Java
- Ant
shortTitle: Build & test Java & Ant
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
## Einführung
Dieser Leitfaden zeigt Dir, wie Du einen Workflow erstellen kannst, der eine kontinuierliche Integration (CI) für Dein Java-Projekt mit Hilfe des Build-Systems Ant durchführt. Der Workflow, den Du erstellst, zeigt Dir, wenn Commits zu einem Pull-Request zu Build- oder Testfehlern für deinen Standard-Zweig führen. Dieser Ansatz kann dazu beitragen, dass Dein Code immer brauchbar ist. Du kannst Deinen CI-Workflow so erweitern, dass er Artefakte von einem Workflow-Lauf hochlädt.
{% ifversion ghae %}For instructions on how to make sure your {% data variables.actions.hosted_runner %} has the required software installed, see "[Creating custom images](/actions/using-github-hosted-runners/creating-custom-images)."
{% else %}
{% data variables.product.prodname_dotcom %}-gehostete Runnner haben einen Tools-Cache mit vorinstallierter Software, einschließlich Java Development Kits (JDKs) und Ant. For a list of software and the pre-installed versions for JDK and Ant, see "[Specifications for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/reference/specifications-for-github-hosted-runners/#supported-software)".
{% endif %}
## Vorrausetzungen
Du solltest mit YAML und der Syntax für {% data variables.product.prodname_actions %} vertraut sein. Weitere Informationen findest Du unter:
- „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions)“
- "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)"
Du solltest ein grundlegendes Verständnis von Java und dem Framework Ant haben. Weitere Informationen findest Du im [Handbuch zu Apache Ant](https://ant.apache.org/manual/).
{% data reusables.actions.enterprise-setup-prereq %}
## Einstieg mit einer Ant-Workflow-Vorlage
{% data variables.product.prodname_dotcom %} bietet eine Ant-Workflow-Vorlage, die für die meisten Ant-basierten Java-Projekte funktionieren wird. For more information, see the [Ant workflow template](https://github.com/actions/starter-workflows/blob/main/ci/ant.yml).
Um schnell loszulegen, kannst Du beim Erstellen eines neuen Workflows die vorkonfigurierte Ant-Vorlage auswählen. For more information, see the "[{% data variables.product.prodname_actions %} quickstart](/actions/quickstart)."
Du kannst auch manuell diesen Workflow hinzufügen, indem Du eine neue Datei im Verzeichnis `.github/workflows` Deines Reporitorys erstellst.
{% raw %}
```yaml{:copy}
name: Java CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Set up JDK 11
uses: actions/setup-java@v2
with:
java-version: '11'
distribution: 'adopt'
- name: Build with Ant
run: ant -noinput -buildfile build.xml
```
{% endraw %}
Dieser Workflow führt die folgenden Schritte aus:
1. Der Schritt `checkout` lädt eine Kopie Deines Repositorys auf den Runner herunter.
2. The `setup-java` step configures the Java 11 JDK by Adoptium.
3. Der Schritt „Build with Ant“ (mittels Ant bauen) führt das standardmäßige „Target“ (Ziel) in Deiner `build.xml` im nicht-interaktiven Modus aus.
Die Standard-Workflow-Vorlagen sind ausgezeichnete Ausgangspunkte beim Erstellen des Build- und Testworkflows, und Du kannst die Vorlage an die Anforderungen Deines Projekts anpassen.
{% data reusables.github-actions.example-github-runner %}
{% data reusables.github-actions.java-jvm-architecture %}
## Deinen Code bauen und testen
Du kannst die gleichen Befehle verwenden, die Du auch lokal verwendest, um Deinen Code zu erstellen und zu testen.
Der Starter-Workflow führt das in der Datei _build.xml_ angegebene „default target“ (Standardziel) aus. Dein Standard-Ziel wird normalerweise eingestellt, um Klassen zu bauen, Tests durchzuführen und Klassen in ihr verteilbares Format (z.B . eine JAR-Datei) zu paketieren.
Wenn Du zum Bauen Deines Projekts andere Befehle verwenden oder ein anderes Ziel auszuführen möchtest, kannst Du dies angeben. Vielleicht möchtest Du beispielsweise das Ziel `jar` ausführen, das in Deiner Datei _build-ci.xml_ konfiguriert ist.
{% raw %}
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v2
with:
java-version: '11'
distribution: 'adopt'
- name: Run the Ant jar target
run: ant -noinput -buildfile build-ci.xml jar
```
{% endraw %}
## Workflow-Daten als Artefakte paketieren
Nachdem sowohl Build erfolgreich war und Deine Tests bestanden hat, wirst Du die resultierenden Java-Pakete als Build-Artefakt hochladen wollen. Dies speichert die gebauten Pakete als Teil der Workflow-Ausführung und ermöglicht Dir, sie herunterzuladen. Artefakte können Dir helfen, Pull-Requests in Deiner lokalen Umgebung zu testen und zu debuggen, bevor sie zusammengeführt werden („merge“). Weitere Informationen findest Du unter „[Workflow-Daten mittels Artefakten persistieren](/actions/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)“.
Ant erstellt normalerweise Ausgabedateien wie JARs, EARs oder WARs im Verzeichnis `build/jar`. Du kannst den Inhalt dieses Verzeichnisses mit der Aktion `upload-artifact` hochladen.
{% raw %}
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v2
with:
java-version: '11'
distribution: 'adopt'
- run: ant -noinput -buildfile build.xml
- uses: actions/upload-artifact@v2
with:
name: Package
path: build/jar
```
{% endraw %}

View File

@@ -1,162 +0,0 @@
---
title: Java bauen und testen mit Gradle
intro: 'Du kannst einen Workflow für kontinuierliche Integration (CI) in GitHub-Aktionen erstellen, um Dein Java-Projekt mit Gradle zu bauen und zu testen.'
redirect_from:
- /actions/language-and-framework-guides/building-and-testing-java-with-gradle
- /actions/guides/building-and-testing-java-with-gradle
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: tutorial
topics:
- CI
- Java
- Gradle
shortTitle: Build & test Java & Gradle
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
## Einführung
Dieser Leitfaden zeigt Dir, wie Du einen Workflow erstellen kannst, der eine kontinuierliche Integration (CI) für Dein Java-Projekt mit Hilfe des Build-Systems Gradle durchführt. Der Workflow, den Du erstellst, zeigt Dir, wenn Commits zu einem Pull-Request zu Build- oder Testfehlern für deinen Standard-Zweig führen. Dieser Ansatz kann dazu beitragen, dass Dein Code immer brauchbar ist. Du kannst Deinen CI-Workflow so erweitern, dass er Dateien im Cache zwischenspeichert und Artefakte von einem Workflow-Lauf hochlädt.
{% ifversion ghae %}For instructions on how to make sure your {% data variables.actions.hosted_runner %} has the required software installed, see "[Creating custom images](/actions/using-github-hosted-runners/creating-custom-images)."
{% else %}
{% data variables.product.prodname_dotcom %}-gehostete Runnner haben einen Tools-Cache mit vorinstallierter Software, einschließlich Java Development Kits (JDKs) und Gradle. For a list of software and the pre-installed versions for JDK and Gradle, see "[Specifications for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/reference/specifications-for-github-hosted-runners/#supported-software)".
{% endif %}
## Vorrausetzungen
Du solltest mit YAML und der Syntax für {% data variables.product.prodname_actions %} vertraut sein. Weitere Informationen findest Du unter:
- „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions)“
- "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)"
Du solltest ein grundlegendes Verständnis von Java und dem Framework Gradle haben. Weitere Informationen findest Du unter [Erste Schritte](https://docs.gradle.org/current/userguide/getting_started.html) in der Gradle-Dokumentation.
{% data reusables.actions.enterprise-setup-prereq %}
## Einstieg mit einer Gradle-Workflow-Vorlage
{% data variables.product.prodname_dotcom %} bietet eine Gradle-Workflow-Vorlage, die für die meisten Gradle-basierten Java-Projekte funktionieren wird. For more information, see the [Gradle workflow template](https://github.com/actions/starter-workflows/blob/main/ci/gradle.yml).
Um schnell loszulegen, kannst Du beim Erstellen eines neuen Workflows die vorkonfigurierte Gradle-Vorlage auswählen. For more information, see the "[{% data variables.product.prodname_actions %} quickstart](/actions/quickstart)."
Du kannst auch manuell diesen Workflow hinzufügen, indem Du eine neue Datei im Verzeichnis `.github/workflows` Deines Reporitorys erstellst.
```yaml{:copy}
{% data reusables.actions.actions-not-certified-by-github-comment %}
name: Java CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Set up JDK 11
uses: actions/setup-java@v2
with:
java-version: '11'
distribution: 'adopt'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
- name: Build with Gradle
run: ./gradlew build
```
Dieser Workflow führt die folgenden Schritte aus:
1. Der Schritt `checkout` lädt eine Kopie Deines Repositorys auf den Runner herunter.
2. The `setup-java` step configures the Java 11 JDK by Adoptium.
3. The "Validate Gradle wrapper" step validates the checksums of Gradle Wrapper JAR files present in the source tree.
4. Der Schritt "Build with Gradle" führt das Wrapper-Skript `gradlew` aus, um sicherzustellen, dass dein Code gebaut, Tests bestanden und ein Paket erstellt werden kann.
Die Standard-Workflow-Vorlagen sind ausgezeichnete Ausgangspunkte beim Erstellen des Build- und Testworkflows, und Du kannst die Vorlage an die Anforderungen Deines Projekts anpassen.
{% data reusables.github-actions.example-github-runner %}
{% data reusables.github-actions.java-jvm-architecture %}
## Deinen Code bauen und testen
Du kannst die gleichen Befehle verwenden, die Du auch lokal verwendest, um Deinen Code zu erstellen und zu testen.
Der Starter-Workflow führt standardmäßig den Task `build` aus. In der Standard-Gradle-Konfiguration lädt dieser Befehl Abhängigkeiten herunter, baut Klassen, führt Tests durch und paketiert Klassen in ihr verteilbares Format, zum Beispiel eine JAR-Datei.
Wenn Du zum Bauen Deines Projekts andere Befehle verwenden oder einen anderen Task auszuführen möchtest, kannst Du dies angeben. Vielleicht möchtest Du beispielsweise den Task `package` ausführen, der in Deiner Datei _ci.gradle_ konfiguriert ist.
{% raw %}
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v2
with:
java-version: '11'
distribution: 'adopt'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
- name: Run the Gradle package task
run: ./gradlew -b ci.gradle package
```
{% endraw %}
## Abhängigkeiten „cachen“ (zwischenspeichern)
When using {% data variables.product.prodname_dotcom %}-hosted runners, you can cache your dependencies to speed up your workflow runs. Nach einem erfolgreichen Lauf wird Dein lokaler Paket-Cache von Gradle in der Aktions-Infrastruktur auf GitHub gespeichert. Bei zukünftigen Workflow-Ausführungen wird der Cache wiederhergestellt, so dass Abhängigkeiten nicht aus entfernten Paket-Repositories heruntergeladen werden müssen. You can cache dependencies simply using the [`setup-java` action](https://github.com/marketplace/actions/setup-java-jdk) or can use [`cache` action](https://github.com/actions/cache) for custom and more advanced configuration.
{% raw %}
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Set up JDK 11
uses: actions/setup-java@v2
with:
java-version: '11'
distribution: 'adopt'
cache: gradle
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
- name: Build with Gradle
run: ./gradlew build
- name: Cleanup Gradle Cache
# Remove some files from the Gradle cache, so they aren't cached by GitHub Actions.
# Restoring these files from a GitHub Actions cache might cause problems for future builds.
run: |
rm -f ~/.gradle/caches/modules-2/modules-2.lock
rm -f ~/.gradle/caches/modules-2/gc.properties
```
{% endraw %}
This workflow will save the contents of your local Gradle package cache, located in the `.gradle/caches` and `.gradle/wrapper` directories of the runner's home directory. The cache key will be the hashed contents of the gradle build files (including the Gradle wrapper properties file), so any changes to them will invalidate the cache.
## Workflow-Daten als Artefakte paketieren
Nachdem sowohl Build erfolgreich war und Deine Tests bestanden hat, wirst Du die resultierenden Java-Pakete als Build-Artefakt hochladen wollen. Dies speichert die gebauten Pakete als Teil der Workflow-Ausführung und ermöglicht Dir, sie herunterzuladen. Artefakte können Dir helfen, Pull-Requests in Deiner lokalen Umgebung zu testen und zu debuggen, bevor sie zusammengeführt werden („merge“). Weitere Informationen findest Du unter „[Workflow-Daten mittels Artefakten persistieren](/actions/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)“.
Gradle erstellt normalerweise Ausgabedateien wie JARs, EARs oder WARs im Verzeichnis `build/libs`. Du kannst den Inhalt dieses Verzeichnisses mit der Aktion `upload-artifact` hochladen.
{% raw %}
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v2
with:
java-version: '11'
distribution: 'adopt'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
- run: ./gradlew build
- uses: actions/upload-artifact@v2
with:
name: Package
path: build/libs
```
{% endraw %}

View File

@@ -1,148 +0,0 @@
---
title: Java bauen und testen mit Maven
intro: 'Du kannst einen Workflow für kontinuierliche Integration (CI) in GitHub-Aktionen erstellen, um Dein Java-Projekt mit Maven zu bauen und zu testen.'
redirect_from:
- /actions/language-and-framework-guides/building-and-testing-java-with-maven
- /actions/guides/building-and-testing-java-with-maven
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: tutorial
topics:
- CI
- Java
- Maven
shortTitle: Build & test Java with Maven
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
## Einführung
Dieser Leitfaden zeigt Dir, wie Du einen Workflow erstellen kannst, der eine kontinuierliche Integration (CI) für Dein Java-Projekt mit Hilfe des Software-Projektmanagement-Tools Maven durchführt. Der Workflow, den Du erstellst, zeigt Dir, wenn Commits zu einem Pull-Request zu Build- oder Testfehlern für deinen Standard-Zweig führen. Dieser Ansatz kann dazu beitragen, dass Dein Code immer brauchbar ist. Du kannst Deinen CI-Workflow so erweitern, dass er Dateien im Cache zwischenspeichert und Artefakte von einem Workflow-Lauf hochlädt.
{% ifversion ghae %}For instructions on how to make sure your {% data variables.actions.hosted_runner %} has the required software installed, see "[Creating custom images](/actions/using-github-hosted-runners/creating-custom-images)."
{% else %}
{% data variables.product.prodname_dotcom %}-gehostete Runnner haben einen Tools-Cache mit vorinstallierter Software, einschließlich Java Development Kits (JDKs) und Maven. For a list of software and the pre-installed versions for JDK and Maven, see "[Specifications for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/reference/specifications-for-github-hosted-runners/#supported-software)".
{% endif %}
## Vorrausetzungen
Du solltest mit YAML und der Syntax für {% data variables.product.prodname_actions %} vertraut sein. Weitere Informationen findest Du unter:
- „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions)“
- "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)"
Du solltest ein grundlegendes Verständnis von Java und dem Framework Maven haben. Weitere Informationen findest Du in der [Anleitung für erste Schritte mit Maven](http://maven.apache.org/guides/getting-started/index.html) in der Maven-Dokumentation.
{% data reusables.actions.enterprise-setup-prereq %}
## Einstieg mit einer Maven-Workflow-Vorlage
{% data variables.product.prodname_dotcom %} bietet eine Maven-Workflow-Vorlage, die für die meisten Maven-basierten Java-Projekte funktionieren wird. Weitere Informationen findest Du im [Workflow-Template für Maven](https://github.com/actions/starter-workflows/blob/main/ci/maven.yml).
Um schnell loszulegen, kannst Du beim Erstellen eines neuen Workflows die vorkonfigurierte Maven-Vorlage auswählen. For more information, see the "[{% data variables.product.prodname_actions %} quickstart](/actions/quickstart)."
Du kannst auch manuell diesen Workflow hinzufügen, indem Du eine neue Datei im Verzeichnis `.github/workflows` Deines Reporitorys erstellst.
{% raw %}
```yaml{:copy}
name: Java CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Set up JDK 11
uses: actions/setup-java@v2
with:
java-version: '11'
distribution: 'adopt'
- name: Build with Maven
run: mvn --batch-mode --update-snapshots verify
```
{% endraw %}
Dieser Workflow führt die folgenden Schritte aus:
1. Der Schritt `checkout` lädt eine Kopie Deines Repositorys auf den Runner herunter.
2. The `setup-java` step configures the Java 11 JDK by Adoptium.
3. Der Schritt "Build with Maven" führt das Maven-„Target“ (Ziel) `package` im nicht-interaktiven Modus aus, um sicherzustellen, dass der Code gebaut, Tests bestanden und ein Paket erstellt werden kann.
Die Standard-Workflow-Vorlagen sind ausgezeichnete Ausgangspunkte beim Erstellen des Build- und Testworkflows, und Du kannst die Vorlage an die Anforderungen Deines Projekts anpassen.
{% data reusables.github-actions.example-github-runner %}
{% data reusables.github-actions.java-jvm-architecture %}
## Deinen Code bauen und testen
Du kannst die gleichen Befehle verwenden, die Du auch lokal verwendest, um Deinen Code zu erstellen und zu testen.
Der Starter-Workflow führt standardmäßig das „target“ (Ziel) `package` aus. In der Standard-Maven-Konfiguration lädt dieser Befehl Abhängigkeiten herunter, baut Klassen, führt Tests durch und paketiert Klassen in ihr verteilbares Format, zum Beispiel eine JAR-Datei.
Wenn Du zum Bauen Deines Projekts andere Befehle verwenden oder ein anderes Ziel auszuführen möchtest, kannst Du dies angeben. Vielleicht möchtest Du beispielsweise das Ziel `verify` ausführen, das in Deiner Datei _pom-ci.xml_ konfiguriert ist.
{% raw %}
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v2
with:
java-version: '11'
distribution: 'adopt'
- name: Run the Maven verify phase
run: mvn --batch-mode --update-snapshots verify
```
{% endraw %}
## Abhängigkeiten „cachen“ (zwischenspeichern)
When using {% data variables.product.prodname_dotcom %}-hosted runners, you can cache your dependencies to speed up your workflow runs. Nach einem erfolgreichen Lauf wird Dein lokales Maven-Repository in der Aktions-Infrastruktur auf GitHub gespeichert. Bei zukünftigen Workflow-Ausführungen wird der Cache wiederhergestellt, so dass Abhängigkeiten nicht aus entfernten Maven-Repositories heruntergeladen werden müssen. You can cache dependencies simply using the [`setup-java` action](https://github.com/marketplace/actions/setup-java-jdk) or can use [`cache` action](https://github.com/actions/cache) for custom and more advanced configuration.
{% raw %}
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Set up JDK 11
uses: actions/setup-java@v2
with:
java-version: '11'
distribution: 'adopt'
cache: maven
- name: Build with Maven
run: mvn --batch-mode --update-snapshots verify
```
{% endraw %}
Dieser Workflow speichert den Inhalt Deines lokalen Maven-Repositiorys im Verzeichnis `.m2` des Home-Verzeichnisses auf dem Runner. Der Cache-Schlüssel wird der gehashte Inhalt von _pom.xml_sein, so dass Änderungen an _pom.xml_ den Cache ungültig machen.
## Workflow-Daten als Artefakte paketieren
Nachdem sowohl Build erfolgreich war und Deine Tests bestanden hat, wirst Du die resultierenden Java-Pakete als Build-Artefakt hochladen wollen. Dies speichert die gebauten Pakete als Teil der Workflow-Ausführung und ermöglicht Dir, sie herunterzuladen. Artefakte können Dir helfen, Pull-Requests in Deiner lokalen Umgebung zu testen und zu debuggen, bevor sie zusammengeführt werden („merge“). Weitere Informationen findest Du unter „[Workflow-Daten mittels Artefakten persistieren](/actions/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)“.
Maven erstellt normalerweise Ausgabedateien wie JARs, EARs oder WARs im Verzeichnis `target`. Um diese als Artefakte hochzuladen, kannst du sie in ein neues Verzeichnis kopieren, welches Artefakte zum Hochladen enthält. Zum Beispiel kannst Du ein Verzeichnis namens `staging` erstellen. Dann kannst Du den Inhalt dieses Verzeichnisses mit der Aktion `upload-artifact` hochladen.
{% raw %}
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v2
with:
java-version: '11'
distribution: 'adopt'
- run: mvn --batch-mode --update-snapshots verify
- run: mkdir staging && cp target/*.jar staging
- uses: actions/upload-artifact@v2
with:
name: Package
path: staging
```
{% endraw %}

View File

@@ -1,259 +0,0 @@
---
title: Building and testing .NET
intro: You can create a continuous integration (CI) workflow to build and test your .NET project.
redirect_from:
- /actions/guides/building-and-testing-net
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
shortTitle: Build & test .NET
---
{% 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 build, test, and publish a .NET package.
{% ifversion ghae %} To build and test your .NET project on {% data variables.product.prodname_ghe_managed %}, you will need to create a custom operating system image that includes the .NET Core SDK. For instructions on how to make sure your {% data variables.actions.hosted_runner %} has the required software installed, see "[Creating custom images](/actions/using-github-hosted-runners/creating-custom-images)."
{% else %} {% data variables.product.prodname_dotcom %}-hosted runners have a tools cache with preinstalled software, which includes the .NET Core SDK. For a full list of up-to-date software and the preinstalled versions of .NET Core SDK, see [software installed on {% data variables.product.prodname_dotcom %}-hosted runners](/actions/reference/specifications-for-github-hosted-runners).
{% endif %}
## Vorrausetzungen
You should already be familiar with YAML syntax and how it's used with {% data variables.product.prodname_actions %}. Weitere Informationen findest Du unter „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions)“.
We recommend that you have a basic understanding of the .NET Core SDK. For more information, see [Getting started with .NET](https://dotnet.microsoft.com/learn).
## Starting with the .NET workflow template
{% data variables.product.prodname_dotcom %} provides a .NET workflow template that should work for most .NET projects, and this guide includes examples that show you how to customize this template. For more information, see the [.NET workflow template](https://github.com/actions/setup-dotnet).
Um schnell loszulegen, füge die Vorlage in das Verzeichnis `.github/workflows` Deines Repositorys ein.
{% raw %}
```yaml
name: dotnet package
on: [push]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
dotnet-version: ['3.0', '3.1.x', '5.0.x' ]
steps:
- uses: actions/checkout@v2
- name: Setup .NET Core SDK ${{ matrix.dotnet-version }}
uses: actions/setup-dotnet@v1.7.2
with:
dotnet-version: ${{ matrix.dotnet-version }}
- name: Install dependencies
run: dotnet restore
- name: Build
run: dotnet build --configuration Release --no-restore
- name: Test
run: dotnet test --no-restore --verbosity normal
```
{% endraw %}
## Specifying a .NET version
To use a preinstalled version of the .NET Core SDK on a {% data variables.product.prodname_dotcom %}-hosted runner, use the `setup-dotnet` action. This action finds a specific version of .NET from the tools cache on each runner, and adds the necessary binaries to `PATH`. These changes will persist for the remainder of the job.
The `setup-dotnet` action is the recommended way of using .NET with {% data variables.product.prodname_actions %}, because it ensures consistent behavior across different runners and different versions of .NET. If you are using a self-hosted runner, you must install .NET and add it to `PATH`. For more information, see the [`setup-dotnet`](https://github.com/marketplace/actions/setup-net-core-sdk) action.
### Using multiple .NET versions
{% raw %}
```yaml
name: dotnet package
on: [push]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
dotnet: [ '3.0', '3.1.x', '5.0.x' ]
steps:
- uses: actions/checkout@v2
- name: Setup dotnet ${{ matrix.dotnet-version }}
uses: actions/setup-dotnet@v1
with:
dotnet-version: ${{ matrix.dotnet-version }}
# You can test your matrix by printing the current dotnet version
- name: Display dotnet version
run: dotnet --version
```
{% endraw %}
### Using a specific .NET version
You can configure your job to use a specific version of .NET, such as `3.1.3`. Alternatively, you can use semantic version syntax to get the latest minor release. This example uses the latest minor release of .NET 3.
{% raw %}
```yaml
- name: Setup .NET 3.x
uses: actions/setup-dotnet@v1
with:
# Semantic version range syntax or exact version of a dotnet version
dotnet-version: '3.x'
```
{% endraw %}
## Abhängigkeiten installieren
{% data variables.product.prodname_dotcom %}-hosted runners have the NuGet package manager installed. You can use the dotnet CLI to install dependencies from the NuGet package registry before building and testing your code. For example, the YAML below installs the `Newtonsoft` package.
{% raw %}
```yaml
steps:
- uses: actions/checkout@v2
- name: Setup dotnet
uses: actions/setup-dotnet@v1
with:
dotnet-version: '3.1.x'
- name: Install dependencies
run: dotnet add package Newtonsoft.Json --version 12.0.1
```
{% endraw %}
{% ifversion fpt or ghec %}
### Abhängigkeiten „cachen“ (zwischenspeichern)
You can cache NuGet dependencies using a unique key, which allows you to restore the dependencies for future workflows with the [`cache`](https://github.com/marketplace/actions/cache) action. For example, the YAML below installs the `Newtonsoft` package.
Weitere Informationen findest Du unter „[Abhängigkeiten zur Beschleunigung von Workflows im Cache zwischenspeichern](/actions/guides/caching-dependencies-to-speed-up-workflows)“.
{% raw %}
```yaml
steps:
- uses: actions/checkout@v2
- name: Setup dotnet
uses: actions/setup-dotnet@v1
with:
dotnet-version: '3.1.x'
- uses: actions/cache@v2
with:
path: ~/.nuget/packages
# Look to see if there is a cache hit for the corresponding requirements file
key: ${{ runner.os }}-nuget-${{ hashFiles('**/packages.lock.json') }}
restore-keys: |
${{ runner.os }}-nuget
- name: Install dependencies
run: dotnet add package Newtonsoft.Json --version 12.0.1
```
{% endraw %}
{% note %}
**Note:** Depending on the number of dependencies, it may be faster to use the dependency cache. Projects with many large dependencies should see a performance increase as it cuts down the time required for downloading. Projects with fewer dependencies may not see a significant performance increase and may even see a slight decrease due to how NuGet installs cached dependencies. The performance varies from project to project.
{% endnote %}
{% endif %}
## Deinen Code bauen und testen
Du kannst die gleichen Befehle verwenden, die Du auch lokal verwendest, um Deinen Code zu erstellen und zu testen. This example demonstrates how to use `dotnet build` and `dotnet test` in a job:
{% raw %}
```yaml
steps:
- uses: actions/checkout@v2
- name: Setup dotnet
uses: actions/setup-dotnet@v1
with:
dotnet-version: '3.1.x'
- name: Install dependencies
run: dotnet restore
- name: Build
run: dotnet build
- name: Test with the dotnet CLI
run: dotnet test
```
{% endraw %}
## Workflow-Daten als Artefakte paketieren
After a workflow completes, you can upload the resulting artifacts for analysis. Zum Beispiel kann es notwendig sein, Logdateien, Core Dumps, Testergebnisse oder Screenshots zu speichern. The following example demonstrates how you can use the `upload-artifact` action to upload test results.
Weitere Informationen findest Du unter "[Workflow-Daten mittels Artefakten persistieren](/github/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)."
{% raw %}
```yaml
name: dotnet package
on: [push]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
dotnet-version: [ '3.0', '3.1.x', '5.0.x' ]
steps:
- uses: actions/checkout@v2
- name: Setup dotnet
uses: actions/setup-dotnet@v1
with:
dotnet-version: ${{ matrix.dotnet-version }}
- name: Install dependencies
run: dotnet restore
- name: Test with dotnet
run: dotnet test --logger trx --results-directory "TestResults-${{ matrix.dotnet-version }}"
- name: Upload dotnet test results
uses: actions/upload-artifact@v2
with:
name: dotnet-results-${{ matrix.dotnet-version }}
path: TestResults-${{ matrix.dotnet-version }}
# Use always() to always run this step to publish test results when there are test failures
if: ${{ always() }}
```
{% endraw %}
## In Paket-Registries veröffentlichen
You can configure your workflow to publish your Dotnet package to a package registry when your CI tests pass. You can use repository secrets to store any tokens or credentials needed to publish your binary. The following example creates and publishes a package to {% data variables.product.prodname_registry %} using `dotnet core cli`.
```yaml
name: Upload dotnet package
on:
release:
types: [created]
jobs:
deploy:
runs-on: ubuntu-latest{% ifversion fpt or ghes > 3.1 or ghae-next or ghec %}
permissions:
packages: write
contents: read{% endif %}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-dotnet@v1
with:
dotnet-version: '3.1.x' # SDK Version to use.
source-url: https://nuget.pkg.github.com/<owner>/index.json
env:
NUGET_AUTH_TOKEN: {% raw %}${{secrets.GITHUB_TOKEN}}{% endraw %}
- run: dotnet build --configuration Release <my project>
- name: Create the package
run: dotnet pack --configuration Release <my project>
- name: Publish the package to GPR
run: dotnet nuget push <my project>/bin/Release/*.nupkg
```

View File

@@ -1,19 +0,0 @@
---
title: Building and testing Node.js or Python
shortTitle: Build & test Node.js or Python
intro: You can create a continuous integration (CI) workflow to build and test your project. Use the language selector to show examples for your language of choice.
redirect_from:
- /actions/guides/building-and-testing-nodejs-or-python
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: tutorial
topics:
- CI
---
{% data reusables.actions.ae-beta %}
<!-- This article is specially rendered via the pages/ directory -->

View File

@@ -1,315 +0,0 @@
---
title: Building and testing Node.js
intro: 'Du kannst einen Workflow für kontinuierliche Integration (CI) erstellen, um Dein Node.js-Projekt zu bauen und zu testen.'
redirect_from:
- /actions/automating-your-workflow-with-github-actions/using-nodejs-with-github-actions
- /actions/language-and-framework-guides/using-nodejs-with-github-actions
- /actions/guides/building-and-testing-nodejs
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: tutorial
hidden: true
topics:
- CI
- Node
- JavaScript
shortTitle: Build & test Node.js
hasExperimentalAlternative: true
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
## Einführung
Diese Anleitung zeigt Dir, wie Du einen Workflow für fortlaufende Integration (CI) erstellen kannst, der Node.js-Code baut und testet. Wenn Deine CI-Tests erfolgreich durchlaufen, kannst Du Deinen Code deployen (bereitstellen) oder ein Paket veröffentlichen.
## Vorrausetzungen
Wir empfehlen, dass Du ein grundlegendes Verständnis von Node.js, YAML, Workflowkonfigurations-Optionen und die Erstellung einer Workflow-Datei hast. Weitere Informationen findest Du unter:
- "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)"
- "[Getting started with Node.js](https://nodejs.org/en/docs/guides/getting-started-guide/)"
{% data reusables.actions.enterprise-setup-prereq %}
## Einstieg mit einer Node.js-Workflow-Vorlage
{% data variables.product.prodname_dotcom %} bietet eine Node.js-Workflow-Vorlage, die für die meisten Node.js-basierten Projekte funktionieren wird. Diese Anleitung enthält npm und Yarn Beispiele, mit denen Du die Vorlage anpassen kannst. Weitere Informationen findest Du in der [Node.js-Workflow-Vorlage](https://github.com/actions/starter-workflows/blob/main/ci/node.js.yml).
Um schnell loszulegen, füge die Vorlage in das Verzeichnis `.github/workflows` Deines Repositorys ein. The workflow shown below assumes that the default branch for your repository is `main`.
{% raw %}
```yaml{:copy}
name: Node.js CI
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [10.x, 12.x, 14.x, 15.x]
steps:
- uses: actions/checkout@v2
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v2
with:
node-version: ${{ matrix.node-version }}
- run: npm ci
- run: npm run build --if-present
- run: npm test
```
{% endraw %}
{% data reusables.github-actions.example-github-runner %}
## Die Node.js-Version angeben
Der einfachste Weg, eine Node.js-Version anzugeben, ist die Aktion `setup-node` von {% data variables.product.prodname_dotcom %} zu verwenden. Weitere Informationen findest Du unter [`setup-node`](https://github.com/actions/setup-node/).
Die Aktion `setup-node` nimmt eine Node.js-Version als Eingabe und konfiguriert diese Version auf dem Runner. Die Aktion `setup-node` findet auf jedem Runner eine bestimmte Version von Node.js aus dem Tools-Cache und legt die notwendigen Binärdateien im `PATH` ab, wo sie für den Rest des Jobs bestehen bleiben. Für Node.js mit {% data variables.product.prodname_actions %} wird empfohlen, die Aktion `setup-node` zu verwenden, weil dadurch über verschiedenen Runner und verschiedenen Versionen von Node.js hinweg ein konsistentes Verhalten sicherstellt wird. Wenn Du einen selbst gehosteten Runner verwendest, musst Du Node.js installieren und zum `PATH` hinzufügen.
The template includes a matrix strategy that builds and tests your code with four Node.js versions: 10.x, 12.x, 14.x, and 15.x. The 'x' is a wildcard character that matches the latest minor and patch release available for a version. Jede Version von Node.js, die im Array `node-version` festgelegt ist, erstellt einen Job, der die gleichen Schritte ausführt.
Jeder Job in der Matrix kann mithilfe des `Matrix`-Kontexts auf den im Array `node-version` definierten Wert zugreifen. Die Aktion `setup-node` verwendet den Kontext als Eingabe für `node-version`. Die Aktion `setup-node` konfiguriert jeden Job mit einer anderen Node.js-Version bevor sie den Code baut und testet. For more information about matrix strategies and contexts, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix)" and "[Contexts](/actions/learn-github-actions/contexts)."
{% raw %}
```yaml{:copy}
strategy:
matrix:
node-version: [10.x, 12.x, 14.x, 15.x]
steps:
- uses: actions/checkout@v2
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v2
with:
node-version: ${{ matrix.node-version }}
```
{% endraw %}
Alternativ kannnst Du auch mit genauen Node.js-Versionen bauen und testen.
```yaml{:copy}
strategy:
matrix:
node-version: [8.16.2, 10.17.0]
```
Oder Du kannst auch mithilfe einer einzelnen Version von Node.js bauen und testen.
{% raw %}
```yaml{:copy}
name: Node.js CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Use Node.js
uses: actions/setup-node@v2
with:
node-version: '12.x'
- run: npm ci
- run: npm run build --if-present
- run: npm test
```
{% endraw %}
Wenn Du keine Node.js Version festlegst, verwendet {% data variables.product.prodname_dotcom %} die standardmäßige Node.js Version der Umgebung.
{% ifversion ghae %} For instructions on how to make sure your {% data variables.actions.hosted_runner %} has the required software installed, see "[Creating custom images](/actions/using-github-hosted-runners/creating-custom-images)."
{% else %} For more information, see "[Specifications for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/reference/specifications-for-github-hosted-runners/#supported-software)".
{% endif %}
## Abhängigkeiten installieren
Auf {% data variables.product.prodname_dotcom %}-gehosteten Runnern sind die Abhängigkeitsmanager npm und Yarn installiert. Du kannst npm und Yarn verwenden, um in Ihrem Workflow Abhängigkeiten zu installieren, bevor Du Deinen Code baust und testest. Die auf {% data variables.product.prodname_dotcom %} gehosteten Windows- und Linux-Runner haben auch Grunt, Gulp und Bower installiert.
When using {% data variables.product.prodname_dotcom %}-hosted runners, you can also cache dependencies to speed up your workflow. Weitere Informationen findest Du unter „<a href="/actions/guides/caching-dependencies-to-speed-up-workflows" class="dotcom-only">Abhängigkeiten zur Beschleunigung von Workflows im Cache zwischenspeichern</a>“.
### Beispiel mit npm
Dieses Beispiel installiert die Abhängigkeiten, die in der Datei *package.json* definiert sind. Weitere Informationen findest Du unter [`npm install`](https://docs.npmjs.com/cli/install).
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Use Node.js
uses: actions/setup-node@v2
with:
node-version: '12.x'
- name: Install dependencies
run: npm install
```
Du kannst mithilfe `npm ci` die Versionen in der Datei *package-lock.json* oder *npm-shrinkwrap.json* installieren und Aktualisierungen der Sperrdatei verhindern. `npm ci` zu verwenden ist gewöhnlich schneller als `npm install` laufen zu lassen. Weitere Informationen findest Du unter [`npm ci`](https://docs.npmjs.com/cli/ci.html) und „[Einführung in `npm ci` für schnellere und zuverlässigere Builds](https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable)“.
{% raw %}
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Use Node.js
uses: actions/setup-node@v2
with:
node-version: '12.x'
- name: Install dependencies
run: npm ci
```
{% endraw %}
### Beispiel mit Yarn
Dieses Beispiel installiert die Abhängigkeiten, die in der Datei *package.json* definiert sind. Weitere Informationen findest Du unter [`Yarn-Installation`](https://yarnpkg.com/en/docs/cli/install).
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Use Node.js
uses: actions/setup-node@v2
with:
node-version: '12.x'
- name: Install dependencies
run: yarn
```
Alternativ kannst Du `--frozen-lockfile` übergeben, um die Versionen in der Datei *yarn.lock* zu installieren und Aktualisierungen der Datei *yarn.lock* zu verhindern.
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Use Node.js
uses: actions/setup-node@v2
with:
node-version: '12.x'
- name: Install dependencies
run: yarn --frozen-lockfile
```
### Beispiel mit einer privaten Registry und Erstellung der Datei .npmrc
{% data reusables.github-actions.setup-node-intro %}
To authenticate to your private registry, you'll need to store your npm authentication token as a secret. For example, create a repository secret called `NPM_TOKEN`. Weitere Informationen findest Du unter „[Verschlüsselte Geheimnisse erstellen und verwenden](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)“.
Im folgenden Beispiel enthält das Geheimnis `NPM_TOKEN` den npm-Authentifizierungs-Token. Die Aktion `setup-node` konfiguriert die Datei *.npmrc*, um den npm-Authentifizierung-Token aus der Umgebungsvariablen `NODE_AUTH_TOKEN` zu lesen. When using the `setup-node` action to create an *.npmrc* file, you must set the `NODE_AUTH_TOKEN` environment variable with the secret that contains your npm authentication token.
Bevor Du Abhängigkeiten installierst, verwende die Aktion `setup-node`, um die Datei *.npmrc* zu erstellen. Die Aktion hat zwei Eingabeparameter. Der Parameter `node-version` legt die Version von Node.js fest und der Parameter `registry-url` bestimmt die Standard-Registry. Wenn Deine Paket-Registry Geltungsbereiche verwendet, musst Du den Parameter `scope` verwenden. Weitere Informationen findest Du unter [`npm-scope`](https://docs.npmjs.com/misc/scope).
{% raw %}
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Use Node.js
uses: actions/setup-node@v2
with:
always-auth: true
node-version: '12.x'
registry-url: https://registry.npmjs.org
scope: '@octocat'
- name: Install dependencies
run: npm ci
env:
NODE_AUTH_TOKEN: ${{secrets.NPM_TOKEN}}
```
{% endraw %}
Das obige Beispiel erzeugt eine *.npmrc* Datei mit folgendem Inhalt:
```ini
//registry.npmjs.org/:_authToken=${NODE_AUTH_TOKEN}
@octocat:registry=https://registry.npmjs.org/
always-auth=true
```
### Beispiel zum Zwischenspeichern von Abhängigkeiten im Cache
When using {% data variables.product.prodname_dotcom %}-hosted runners, you can cache and restore the dependencies using the [`setup-node` action](https://github.com/actions/setup-node).
The following example caches dependencies for npm.
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v2
with:
node-version: '14'
cache: 'npm'
- run: npm install
- run: npm test
```
The following example caches dependencies for Yarn.
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v2
with:
node-version: '14'
cache: 'yarn'
- run: yarn
- run: yarn test
```
The following example caches dependencies for pnpm (v6.10+).
```yaml{:copy}
{% data reusables.actions.actions-not-certified-by-github-comment %}
# NOTE: pnpm caching support requires pnpm version >= 6.10.0
steps:
- uses: actions/checkout@v2
- uses: pnpm/action-setup@646cdf48217256a3d0b80361c5a50727664284f2
with:
version: 6.10.0
- uses: actions/setup-node@v2
with:
node-version: '14'
cache: 'pnpm'
- run: pnpm install
- run: pnpm test
```
To cache dependencies, you must have a `package-lock.json`, `yarn.lock`, or `pnpm-lock.yaml` file in the root of the repository. If you need more flexible customization, you can use the [`cache` action](https://github.com/marketplace/actions/cache). For more information, see "<a href="/actions/guides/caching-dependencies-to-speed-up-workflows" class="dotcom-only">Caching dependencies to speed up workflows</a>".
## Deinen Code bauen und testen
Du kannst die gleichen Befehle verwenden, die Du auch lokal verwendest, um Deinen Code zu erstellen und zu testen. Wenn Du beispielsweise `npm run build` ausführst, um die in Deinem *package.json* definierten Build-Schritte zu durchlaufen, und `npm test`, um Deine Testsuite laufen zu lassen, dann fügst Di diese Befehle in Deine Workflow-Datei ein.
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Use Node.js
uses: actions/setup-node@v2
with:
node-version: '12.x'
- run: npm install
- run: npm run build --if-present
- run: npm test
```
## Workflow-Daten als Artefakte paketieren
Du kannst Artefakte aus deinen Build- und Testschritten speichern, um sie nach dem Abschluss eines Jobs anzuzeigen. Zum Beispiel kann es notwendig sein, Logdateien, Core Dumps, Testergebnisse oder Screenshots zu speichern. Weitere Informationen findest Du unter „[Workflow-Daten mittels Artefakten persistieren](/actions/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)“.
## In Paket-Registries veröffentlichen
Du kannst Deinen Workflow so konfigurieren, dass Dein Node.js-Paket nach Bestehen Deiner CI-Tests in einer Paket-Registry veröffentlicht wird. Weitere Informationen zum Veröffentlichen in npm und {% data variables.product.prodname_registry %} findest Du unter „[Node.js Pakete veröffentlichen](/actions/automating-your-workflow-with-github-actions/publishing-nodejs-packages)“.

View File

@@ -1,255 +0,0 @@
---
title: Building and testing PowerShell
intro: You can create a continuous integration (CI) workflow to build and test your PowerShell project.
redirect_from:
- /actions/guides/building-and-testing-powershell
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
authors:
- potatoqualitee
type: tutorial
topics:
- CI
- Powershell
shortTitle: Build & test PowerShell
---
{% 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 use PowerShell for CI. It describes how to use Pester, install dependencies, test your module, and publish to the PowerShell Gallery.
{% data variables.product.prodname_dotcom %}-hosted runners have a tools cache with pre-installed software, which includes PowerShell and Pester.
{% ifversion ghae %}For instructions on how to make sure your {% data variables.actions.hosted_runner %} has the required software installed, see "[Creating custom images](/actions/using-github-hosted-runners/creating-custom-images)."
{% else %}For a full list of up-to-date software and the pre-installed versions of PowerShell and Pester, see "[Specifications for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/reference/specifications-for-github-hosted-runners/#supported-software)".
{% endif %}
## Vorrausetzungen
Du solltest mit YAML und der Syntax für {% data variables.product.prodname_actions %} vertraut sein. For more information, see "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)."
We recommend that you have a basic understanding of PowerShell and Pester. Weitere Informationen findest Du unter:
- [Getting started with PowerShell](https://docs.microsoft.com/powershell/scripting/learn/ps101/01-getting-started)
- [Pester](https://pester.dev)
{% data reusables.actions.enterprise-setup-prereq %}
## Adding a workflow for Pester
To automate your testing with PowerShell and Pester, you can add a workflow that runs every time a change is pushed to your repository. In the following example, `Test-Path` is used to check that a file called `resultsfile.log` is present.
This example workflow file must be added to your repository's `.github/workflows/` directory:
{% raw %}
```yaml
name: Test PowerShell on Ubuntu
on: push
jobs:
pester-test:
name: Pester test
runs-on: ubuntu-latest
steps:
- name: Check out repository code
uses: actions/checkout@v2
- name: Perform a Pester test from the command-line
shell: pwsh
run: Test-Path resultsfile.log | Should -Be $true
- name: Perform a Pester test from the Tests.ps1 file
shell: pwsh
run: |
Invoke-Pester Unit.Tests.ps1 -Passthru
```
{% endraw %}
* `shell: pwsh` - Configures the job to use PowerShell when running the `run` commands.
* `run: Test-Path resultsfile.log` - Check whether a file called `resultsfile.log` is present in the repository's root directory.
* `Should -Be $true` - Uses Pester to define an expected result. If the result is unexpected, then {% data variables.product.prodname_actions %} flags this as a failed test. Ein Beispiel:
{% ifversion fpt or ghes > 3.0 or ghae or ghec %}
![Failed Pester test](/assets/images/help/repository/actions-failed-pester-test-updated.png)
{% else %}
![Failed Pester test](/assets/images/help/repository/actions-failed-pester-test.png)
{% endif %}
* `Invoke-Pester Unit.Tests.ps1 -Passthru` - Uses Pester to execute tests defined in a file called `Unit.Tests.ps1`. For example, to perform the same test described above, the `Unit.Tests.ps1` will contain the following:
```
Describe "Check results file is present" {
It "Check results file is present" {
Test-Path resultsfile.log | Should -Be $true
}
}
```
## PowerShell module locations
The table below describes the locations for various PowerShell modules in each {% data variables.product.prodname_dotcom %}-hosted runner.
| | Ubuntu | macOS | Windows |
| ----------------------------- | ------------------------------------------------ | ------------------------------------------------- | ------------------------------------------------------------ |
| **PowerShell system modules** | `/opt/microsoft/powershell/7/Modules/*` | `/usr/local/microsoft/powershell/7/Modules/*` | `C:\program files\powershell\7\Modules\*` |
| **PowerShell add-on modules** | `/usr/local/share/powershell/Modules/*` | `/usr/local/share/powershell/Modules/*` | `C:\Modules\*` |
| **User-installed modules** | `/home/runner/.local/share/powershell/Modules/*` | `/Users/runner/.local/share/powershell/Modules/*` | `C:\Users\runneradmin\Documents\PowerShell\Modules\*` |
## Abhängigkeiten installieren
{% data variables.product.prodname_dotcom %}-hosted runners have PowerShell 7 and Pester installed. You can use `Install-Module` to install additional dependencies from the PowerShell Gallery before building and testing your code.
{% note %}
**Note:** The pre-installed packages (such as Pester) used by {% data variables.product.prodname_dotcom %}-hosted runners are regularly updated, and can introduce significant changes. As a result, it is recommended that you always specify the required package versions by using `Install-Module` with `-MaximumVersion`.
{% endnote %}
When using {% data variables.product.prodname_dotcom %}-hosted runners, you can also cache dependencies to speed up your workflow. Weitere Informationen findest Du unter „<a href="/actions/guides/caching-dependencies-to-speed-up-workflows" class="dotcom-only">Abhängigkeiten zur Beschleunigung von Workflows im Cache zwischenspeichern</a>“.
For example, the following job installs the `SqlServer` and `PSScriptAnalyzer` modules:
{% raw %}
```yaml
jobs:
install-dependencies:
name: Install dependencies
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Install from PSGallery
shell: pwsh
run: |
Set-PSRepository PSGallery -InstallationPolicy Trusted
Install-Module SqlServer, PSScriptAnalyzer
```
{% endraw %}
{% note %}
**Note:** By default, no repositories are trusted by PowerShell. When installing modules from the PowerShell Gallery, you must explicitly set the installation policy for `PSGallery` to `Trusted`.
{% endnote %}
### Abhängigkeiten „cachen“ (zwischenspeichern)
When using {% data variables.product.prodname_dotcom %}-hosted runners, you can cache PowerShell dependencies using a unique key, which allows you to restore the dependencies for future workflows with the [`cache`](https://github.com/marketplace/actions/cache) action. Weitere Informationen findest Du unter „<a href="/actions/guides/caching-dependencies-to-speed-up-workflows" class="dotcom-only">Abhängigkeiten zur Beschleunigung von Workflows im Cache zwischenspeichern</a>“.
PowerShell caches its dependencies in different locations, depending on the runner's operating system. For example, the `path` location used in the following Ubuntu example will be different for a Windows operating system.
{% raw %}
```yaml
steps:
- uses: actions/checkout@v2
- name: Setup PowerShell module cache
id: cacher
uses: actions/cache@v2
with:
path: "~/.local/share/powershell/Modules"
key: ${{ runner.os }}-SqlServer-PSScriptAnalyzer
- name: Install required PowerShell modules
if: steps.cacher.outputs.cache-hit != 'true'
shell: pwsh
run: |
Set-PSRepository PSGallery -InstallationPolicy Trusted
Install-Module SqlServer, PSScriptAnalyzer -ErrorAction Stop
```
{% endraw %}
## Deinen Code testen
Du kannst die gleichen Befehle verwenden, die Du auch lokal verwendest, um Deinen Code zu erstellen und zu testen.
### Using PSScriptAnalyzer to lint code
The following example installs `PSScriptAnalyzer` and uses it to lint all `ps1` files in the repository. For more information, see [PSScriptAnalyzer on GitHub](https://github.com/PowerShell/PSScriptAnalyzer).
{% raw %}
```yaml
lint-with-PSScriptAnalyzer:
name: Install and run PSScriptAnalyzer
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Install PSScriptAnalyzer module
shell: pwsh
run: |
Set-PSRepository PSGallery -InstallationPolicy Trusted
Install-Module PSScriptAnalyzer -ErrorAction Stop
- name: Lint with PSScriptAnalyzer
shell: pwsh
run: |
Invoke-ScriptAnalyzer -Path *.ps1 -Recurse -Outvariable issues
$errors = $issues.Where({$_.Severity -eq 'Error'})
$warnings = $issues.Where({$_.Severity -eq 'Warning'})
if ($errors) {
Write-Error "There were $($errors.Count) errors and $($warnings.Count) warnings total." -ErrorAction Stop
} else {
Write-Output "There were $($errors.Count) errors and $($warnings.Count) warnings total."
}
```
{% endraw %}
## Workflow-Daten als Artefakte paketieren
You can upload artifacts to view after a workflow completes. Zum Beispiel kann es notwendig sein, Logdateien, Core Dumps, Testergebnisse oder Screenshots zu speichern. Weitere Informationen findest Du unter "[Workflow-Daten mittels Artefakten persistieren](/github/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)."
The following example demonstrates how you can use the `upload-artifact` action to archive the test results received from `Invoke-Pester`. For more information, see the [`upload-artifact` action](https://github.com/actions/upload-artifact).
{% raw %}
```yaml
name: Upload artifact from Ubuntu
on: [push]
jobs:
upload-pester-results:
name: Run Pester and upload results
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Test with Pester
shell: pwsh
run: Invoke-Pester Unit.Tests.ps1 -Passthru | Export-CliXml -Path Unit.Tests.xml
- name: Upload test results
uses: actions/upload-artifact@v2
with:
name: ubuntu-Unit-Tests
path: Unit.Tests.xml
if: ${{ always() }}
```
{% endraw %}
The `always()` function configures the job to continue processing even if there are test failures. For more information, see "[always](/actions/reference/context-and-expression-syntax-for-github-actions#always)."
## Publishing to PowerShell Gallery
You can configure your workflow to publish your PowerShell module to the PowerShell Gallery when your CI tests pass. You can use secrets to store any tokens or credentials needed to publish your package. Weitere Informationen findest Du unter "[Verschlüsselte Geheimnisse erstellen und verwenden](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)".
The following example creates a package and uses `Publish-Module` to publish it to the PowerShell Gallery:
{% raw %}
```yaml
name: Publish PowerShell Module
on:
release:
types: [created]
jobs:
publish-to-gallery:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Build and publish
env:
NUGET_KEY: ${{ secrets.NUGET_KEY }}
shell: pwsh
run: |
./build.ps1 -Path /tmp/samplemodule
Publish-Module -Path /tmp/samplemodule -NuGetApiKey $env:NUGET_KEY -Verbose
```
{% endraw %}

View File

@@ -1,443 +0,0 @@
---
title: Building and testing Python
intro: 'Du kannst einen Workflow für kontinuierliche Integration (CI) erstellen, um Dein Python-Projekt zu bauen und zu testen.'
redirect_from:
- /actions/automating-your-workflow-with-github-actions/using-python-with-github-actions
- /actions/language-and-framework-guides/using-python-with-github-actions
- /actions/guides/building-and-testing-python
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: tutorial
hidden: true
topics:
- CI
- Python
shortTitle: Build & test Python
hasExperimentalAlternative: true
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
## Einführung
Diese Anleitung zeigt Dir, wie Du ein Python-Paket baust, testest und veröffentlichst.
{% ifversion ghae %} For instructions on how to make sure your {% data variables.actions.hosted_runner %} has the required software installed, see "[Creating custom images](/actions/using-github-hosted-runners/creating-custom-images)."
{% else %} {% data variables.product.prodname_dotcom %}-hosted runners have a tools cache with pre-installed software, which includes Python and PyPy. Du brauchst nichts zu installieren! For a full list of up-to-date software and the pre-installed versions of Python and PyPy, see "[Specifications for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/reference/specifications-for-github-hosted-runners/#supported-software)".
{% endif %}
## Vorrausetzungen
Du solltest mit YAML und der Syntax für {% data variables.product.prodname_actions %} vertraut sein. For more information, see "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)."
Du solltest ein grundlegendes Verständnis von Python, PyPy und pip haben. Weitere Informationen findest Du unter:
- [Erste Schritte mit Python](https://www.python.org/about/gettingstarted/)
- [PyPy](https://pypy.org/)
- [Paketmanager pip](https://pypi.org/project/pip/)
{% data reusables.actions.enterprise-setup-prereq %}
## Einstieg mit der Python-Workflow-Vorlage
{% data variables.product.prodname_dotcom %} bietet eine Python-Workflow-Vorlage, die für die meisten Python-Projekte funktionieren sollte. Diese Anleitung enthält Beispiele, mit denen Du die Vorlage anpassen kannst. For more information, see the [Python workflow template](https://github.com/actions/starter-workflows/blob/main/ci/python-package.yml).
Um schnell loszulegen, füge die Vorlage in das Verzeichnis `.github/workflows` Deines Repositorys ein.
{% raw %}
```yaml{:copy}
name: Python package
on: [push]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
python-version: [3.6, 3.7, 3.8, 3.9]
steps:
- uses: actions/checkout@v2
- name: Set up Python ${{ matrix.python-version }}
uses: actions/setup-python@v2
with:
python-version: ${{ matrix.python-version }}
- name: Install dependencies
run: |
python -m pip install --upgrade pip
pip install flake8 pytest
if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
- name: Lint with flake8
run: |
# stop the build if there are Python syntax errors or undefined names
flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics
# exit-zero treats all errors as warnings. The GitHub editor is 127 chars wide
flake8 . --count --exit-zero --max-complexity=10 --max-line-length=127 --statistics
- name: Test with pytest
run: |
pytest
```
{% endraw %}
## Eine Python-Version angeben
Benutze die Aktion `setup-python`, um eine vorinstallierte Version von Python oder PyPy auf einem {% data variables.product.prodname_dotcom %}-gehosteten Runner zu verwenden. Diese Aktion findet aus dem Tool-Cache auf jedem Runner eine bestimmte Version von Python oder PyPy und fügt die benötigten Binärdateien zum `PATH`hinzu, der für den Rest des Jobs bestehen bleibt. Wenn eine bestimmte Version von Python nicht im Tools-Cache vorinstalliert ist, lädt die Aktion `setup-python` die entsprechende Version vom [Repository `python-versions`](https://github.com/actions/python-versions) herunter und richtet sie ein.
Die `setup-action` ist die empfohlene Methode, Python mit {% data variables.product.prodname_actions %} zu verwenden, da dadurch ein einheitliches Verhalten der verschiedenen Runner und verschiedenen Versionen von Python gewährleistet wird. Wenn Du einen selbst gehosteten Runner verwendest, musst Du Python installieren und zum `PATH` hinzufügen. Weitere Informationen findest Du in der [Aktion `setup-python`](https://github.com/marketplace/actions/setup-python).
Die folgende Tabelle zeigt für jeden {% data variables.product.prodname_dotcom %}-gehosteten Runner, wo der Tools-Cache liegt.
| | Ubuntu | Mac | Windows |
| -------------------------- | ------------------------------- | ---------------------------------------- | ------------------------------------------ |
| **Tool-Cache-Verzeichnis** | `/opt/hostedtoolcache/*` | `/Users/runner/hostedtoolcache/*` | `C:\hostedtoolcache\windows\*` |
| **Tool-Cache für Python** | `/opt/hostedtoolcache/Python/*` | `/Users/runner/hostedtoolcache/Python/*` | `C:\hostedtoolcache\windows\Python\*` |
| **Tool-Cache für PyPy** | `/opt/hostedtoolcache/PyPy/*` | `/Users/runner/hostedtoolcache/PyPy/*` | `C:\hostedtoolcache\windows\PyPy\*` |
Wenn Du einen selbst gehosteten Runner verwendest, kannst Du den Runner so konfigurieren, dass er mithilfe der Aktion `setup-python` Deine Abhängigkeiten verwaltet. Weitere Informationen findest Du unter [setup-python mit einem selbst-gehosteten Runner verwenden](https://github.com/actions/setup-python#using-setup-python-with-a-self-hosted-runner) in der README von `setup-python`.
{% data variables.product.prodname_dotcom %} unterstützt dir Syntax für semantische Versionierung. Weitere Informationen findest Du unter „[Semantische Versionierung verwenden](https://docs.npmjs.com/about-semantic-versioning#using-semantic-versioning-to-specify-update-types-your-package-can-accept)“ und „[Spezifikation für semantische Versionierung](https://semver.org/)“.
### Mehrere Python-Versionen verwenden
{% raw %}
```yaml{:copy}
name: Python package
on: [push]
jobs:
build:
runs-on: ubuntu-latest
strategy:
# Du kannst in python-version die PyPy-Versionen angeben,
# For example, pypy2 and pypy3
matrix:
python-version: [2.7, 3.6, 3.7, 3.8, 3.9]
steps:
- uses: actions/checkout@v2
- name: Set up Python ${{ matrix.python-version }}
uses: actions/setup-python@v2
with:
python-version: ${{ matrix.python-version }}
# You can test your matrix by printing the current Python version
- name: Display Python version
run: python -c "import sys; print(sys.version)"
```
{% endraw %}
### Eine bestimmten Python-Version verwenden
Du kannst eine bestimmte Version von Python konfigurieren, For example, 3.8. Alternatively, you can use semantic version syntax to get the latest minor release. Dieses Beispiel verwendet das neueste Minor Release von Python 3.
{% raw %}
```yaml{:copy}
name: Python package
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Set up Python 3.x
uses: actions/setup-python@v2
with:
# Semantic version range syntax or exact version of a Python version
python-version: '3.x'
# Optional - x64 or x86 architecture, defaults to x64
architecture: 'x64'
# You can test your matrix by printing the current Python version
- name: Display Python version
run: python -c "import sys; print(sys.version)"
```
{% endraw %}
### Eine Version ausschließen
Wenn du eine Version von Python angibst, die nicht verfügbar ist, schlägt `setup-python` fehl und meldet in etwa: `##[error]Version 3.4 with arch x64 not found`. Die Fehlermeldung enthält die verfügbaren Versionen.
Du kannst in Deinem Workflow auch das Schlüsselwort `exclude` verwenden, wenn Du eine bestimmte Konfiguration von Python nicht laufen lassen möchtest. Weitere Informationen findest Du unter „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategy)“.
{% raw %}
```yaml{:copy}
name: Python package
on: [push]
jobs:
build:
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [ubuntu-latest, macos-latest, windows-latest]
python-version: [3.6, 3.7, 3.8, 3.9, pypy2, pypy3]
exclude:
- os: macos-latest
python-version: 3.6
- os: windows-latest
python-version: 3.6
```
{% endraw %}
### Die Standard-Version von Python verwenden
Wir empfehlen, `setup-python` zu verwenden, um die Version von Python zu konfigurieren, die in deinen Workflows verwendet wird, da es hilft, deine Abhängigkeiten explizit zu machen. Wenn du `setup-python` nicht verwendest, wird in jeder Shell, wenn Du `python` aufrufst, die Standardversion von Python verwendet, die in `PATH` gesetzt wurde. Die Standardversion von Python variiert zwischen den {% data variables.product.prodname_dotcom %}-gehosteten Runnern. Dies kann zu unerwarteten Abweichungen führen oder es kann unerwartet eine ältere Version verwendet werden.
| {% data variables.product.prodname_dotcom %}-gehostete Runner | Beschreibung |
| ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Ubuntu | Auf Ubuntu-Runnern sind mehrere Versionen von System-Python unter `/usr/bin/python` und `/usr/bin/python3` installiert. Die Python-Versionen, die mit Ubuntu mitgeliefert werden, sind zusätzlich zu den Versionen, die {% data variables.product.prodname_dotcom %} im Tools-Cache installiert. |
| Windows | Neben den Python-Versionen, die sich im Tools-Cache befinden, kommt Windows nicht mit einer entsprechenden Version von System-Python. Um das mit anderen Runnern konsistente Verhalten sicherzustellen und um Python „out-of-the-box“ ohne die Aktion `setup-python` nutzen zu können fügt {% data variables.product.prodname_dotcom %} ein paar Versionen aus dem Tools-Cache zum `PATH` hinzu. |
| macOS | Auf macOS-Runnern sind zusätzlich zu den Versionen im Tool-Cache noch mehrere Versionen von System-Python installiert. Die Python-Versionen des Systems befinden sich im Verzeichnis `/usr/local/Cellar/python/*`. |
## Abhängigkeiten installieren
Auf {% data variables.product.prodname_dotcom %}-gehosteten Runnern ist der Paketmanager pip installiert. Du kannst pip verwenden, um Abhängigkeiten von der PyPI-Paket-Registry zu installieren, bevor Du Deinen Code baust und testest. Zum Beispiel installiert oder aktualisiert der folgende YAML den Paket-Installierer `pip` sowie die Pakete `setuptools` und `wheel`.
When using {% data variables.product.prodname_dotcom %}-hosted runners, you can also cache dependencies to speed up your workflow. Weitere Informationen findest Du unter „<a href="/actions/guides/caching-dependencies-to-speed-up-workflows" class="dotcom-only">Abhängigkeiten zur Beschleunigung von Workflows im Cache zwischenspeichern</a>“.
{% raw %}
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: '3.x'
- name: Install dependencies
run: python -m pip install --upgrade pip setuptools wheel
```
{% endraw %}
### Datei für „Requirements“ (Anforderungen)
Nach dem Update von `pip` werden üblicherweise im nächsten Schritt die Abhängigkeiten aus *requirements.txt* installiert. For more information, see [pip](https://pip.pypa.io/en/stable/cli/pip_install/#example-requirements-file).
{% raw %}
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: '3.x'
- name: Install dependencies
run: |
python -m pip install --upgrade pip
pip install -r requirements.txt
```
{% endraw %}
### Abhängigkeiten im Cache zwischenspeichern
When using {% data variables.product.prodname_dotcom %}-hosted runners, you can cache pip dependencies using a unique key, and restore the dependencies when you run future workflows using the [`cache`](https://github.com/marketplace/actions/cache) action. Weitere Informationen findest Du unter „<a href="/actions/guides/caching-dependencies-to-speed-up-workflows" class="dotcom-only">Abhängigkeiten zur Beschleunigung von Workflows im Cache zwischenspeichern</a>“.
Pip caches dependencies in different locations, depending on the operating system of the runner. The path you'll need to cache may differ from the Ubuntu example below depending on the operating system you use. For more information, see [Python caching examples](https://github.com/actions/cache/blob/main/examples.md#python---pip).
{% raw %}
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Setup Python
uses: actions/setup-python@v2
with:
python-version: '3.x'
- name: Cache pip
uses: actions/cache@v2
with:
# This path is specific to Ubuntu
path: ~/.cache/pip
# Look to see if there is a cache hit for the corresponding requirements file
key: ${{ runner.os }}-pip-${{ hashFiles('requirements.txt') }}
restore-keys: |
${{ runner.os }}-pip-
${{ runner.os }}-
- name: Install dependencies
run: pip install -r requirements.txt
```
{% endraw %}
{% note %}
**Note:** Depending on the number of dependencies, it may be faster to use the dependency cache. Projects with many large dependencies should see a performance increase as it cuts down the time required for downloading. Projects with fewer dependencies may not see a significant performance increase and may even see a slight decrease due to how pip installs cached dependencies. The performance varies from project to project.
{% endnote %}
## Deinen Code testen
Du kannst die gleichen Befehle verwenden, die Du auch lokal verwendest, um Deinen Code zu erstellen und zu testen.
### Mit pytest und pytest-cov testen
This example installs or upgrades `pytest` and `pytest-cov`. Tests are then run and output in JUnit format while code coverage results are output in Cobertura. For more information, see [JUnit](https://junit.org/junit5/) and [Cobertura](https://cobertura.github.io/cobertura/).
{% raw %}
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: '3.x'
- name: Install dependencies
run: |
python -m pip install --upgrade pip
pip install -r requirements.txt
- name: Test with pytest
run: |
pip install pytest
pip install pytest-cov
pytest tests.py --doctest-modules --junitxml=junit/test-results.xml --cov=com --cov-report=xml --cov-report=html
```
{% endraw %}
### Mit Flake8 den Code von „Fusseln“ reinigen
The following example installs or upgrades `flake8` and uses it to lint all files. For more information, see [Flake8](http://flake8.pycqa.org/en/latest/).
{% raw %}
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: '3.x'
- name: Install dependencies
run: |
python -m pip install --upgrade pip
pip install -r requirements.txt
- name: Lint with flake8
run: |
pip install flake8
flake8 .
continue-on-error: true
```
{% endraw %}
The linting step has `continue-on-error: true` set. This will keep the workflow from failing if the linting step doesn't succeed. Once you've addressed all of the linting errors, you can remove this option so the workflow will catch new issues.
### Tests mit Tox ausführen
With {% data variables.product.prodname_actions %}, you can run tests with tox and spread the work across multiple jobs. You'll need to invoke tox using the `-e py` option to choose the version of Python in your `PATH`, rather than specifying a specific version. For more information, see [tox](https://tox.readthedocs.io/en/latest/).
{% raw %}
```yaml{:copy}
name: Python package
on: [push]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
python: [3.7, 3.8, 3.9]
steps:
- uses: actions/checkout@v2
- name: Setup Python
uses: actions/setup-python@v2
with:
python-version: ${{ matrix.python }}
- name: Install tox and any other packages
run: pip install tox
- name: Run tox
# Run tox using the version of Python in `PATH`
run: tox -e py
```
{% endraw %}
## Workflow-Daten als Artefakte paketieren
You can upload artifacts to view after a workflow completes. Zum Beispiel kann es notwendig sein, Logdateien, Core Dumps, Testergebnisse oder Screenshots zu speichern. Weitere Informationen findest Du unter "[Workflow-Daten mittels Artefakten persistieren](/github/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)."
The following example demonstrates how you can use the `upload-artifact` action to archive test results from running `pytest`. For more information, see the [`upload-artifact` action](https://github.com/actions/upload-artifact).
{% raw %}
```yaml{:copy}
name: Python package
on: [push]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
python-version: [3.6, 3.7, 3.8, 3.9]
steps:
- uses: actions/checkout@v2
- name: Setup Python # Set Python version
uses: actions/setup-python@v2
with:
python-version: ${{ matrix.python-version }}
# Install pip and pytest
- name: Install dependencies
run: |
python -m pip install --upgrade pip
pip install pytest
- name: Test with pytest
run: pytest tests.py --doctest-modules --junitxml=junit/test-results-${{ matrix.python-version }}.xml
- name: Upload pytest test results
uses: actions/upload-artifact@v2
with:
name: pytest-results-${{ matrix.python-version }}
path: junit/test-results-${{ matrix.python-version }}.xml
# Use always() to always run this step to publish test results when there are test failures
if: ${{ always() }}
```
{% endraw %}
## In Paket-Registries veröffentlichen
You can configure your workflow to publish your Python package to a package registry once your CI tests pass. This section demonstrates how you can use {% data variables.product.prodname_actions %} to upload your package to PyPI each time you [publish a release](/github/administering-a-repository/managing-releases-in-a-repository).
For this example, you will need to create two [PyPI API tokens](https://pypi.org/help/#apitoken). You can use secrets to store the access tokens or credentials needed to publish your package. Weitere Informationen findest Du unter "[Verschlüsselte Geheimnisse erstellen und verwenden](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)".
```yaml{:copy}
{% data reusables.actions.actions-not-certified-by-github-comment %}
name: Upload Python Package
on:
release:
types: [published]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: '3.x'
- name: Install dependencies
run: |
python -m pip install --upgrade pip
pip install build
- name: Build package
run: python -m build
- name: Publish package
uses: pypa/gh-action-pypi-publish@27b31702a0e7fc50959f5ad993c78deac1bdfc29
with:
user: __token__
password: {% raw %}${{ secrets.PYPI_API_TOKEN }}{% endraw %}
```
For more information about the template workflow, see [`python-publish`](https://github.com/actions/starter-workflows/blob/main/ci/python-publish.yml).

View File

@@ -1,322 +0,0 @@
---
title: Building and testing Ruby
intro: You can create a continuous integration (CI) workflow to build and test your Ruby project.
redirect_from:
- /actions/guides/building-and-testing-ruby
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: tutorial
topics:
- CI
- Ruby
shortTitle: Build & test Ruby
---
{% 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 create a continuous integration (CI) workflow that builds and tests a Ruby application. If your CI tests pass, you may want to deploy your code or publish a gem.
## Vorrausetzungen
We recommend that you have a basic understanding of Ruby, YAML, workflow configuration options, and how to create a workflow file. Weitere Informationen findest Du unter:
- [Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)
- [Ruby in 20 minutes](https://www.ruby-lang.org/en/documentation/quickstart/)
## Starting with the Ruby workflow template
{% data variables.product.prodname_dotcom %} provides a Ruby workflow template that will work for most Ruby projects. For more information, see the [Ruby workflow template](https://github.com/actions/starter-workflows/blob/master/ci/ruby.yml).
Um schnell loszulegen, füge die Vorlage in das Verzeichnis `.github/workflows` Deines Repositorys ein. The workflow shown below assumes that the default branch for your repository is `main`.
```yaml
{% data reusables.actions.actions-not-certified-by-github-comment %}
name: Ruby
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Set up Ruby
uses: ruby/setup-ruby@477b21f02be01bcb8030d50f37cfec92bfa615b6
with:
ruby-version: 2.6
- name: Install dependencies
run: bundle install
- name: Run tests
run: bundle exec rake
```
## Specifying the Ruby version
The easiest way to specify a Ruby version is by using the `ruby/setup-ruby` action provided by the Ruby organization on GitHub. The action adds any supported Ruby version to `PATH` for each job run in a workflow. For more information see, the [`ruby/setup-ruby`](https://github.com/ruby/setup-ruby).
Using Ruby's `ruby/setup-ruby` action is the recommended way of using Ruby with GitHub Actions because it ensures consistent behavior across different runners and different versions of Ruby.
The `setup-ruby` action takes a Ruby version as an input and configures that version on the runner.
{% raw %}
```yaml
steps:
- uses: actions/checkout@v2
- uses: ruby/setup-ruby@477b21f02be01bcb8030d50f37cfec92bfa615b6
with:
ruby-version: 2.6 # Not needed with a .ruby-version file
- run: bundle install
- run: bundle exec rake
```
{% endraw %}
Alternatively, you can check a `.ruby-version` file into the root of your repository and `setup-ruby` will use the version defined in that file.
## Testing with multiple versions of Ruby
You can add a matrix strategy to run your workflow with more than one version of Ruby. For example, you can test your code against the latest patch releases of versions 2.7, 2.6, and 2.5. The 'x' is a wildcard character that matches the latest patch release available for a version.
{% raw %}
```yaml
strategy:
matrix:
ruby-version: [2.7.x, 2.6.x, 2.5.x]
```
{% endraw %}
Each version of Ruby specified in the `ruby-version` array creates a job that runs the same steps. The {% raw %}`${{ matrix.ruby-version }}`{% endraw %} context is used to access the current job's version. For more information about matrix strategies and contexts, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/learn-github-actions/workflow-syntax-for-github-actions)" and "[Contexts](/actions/learn-github-actions/contexts)."
The full updated workflow with a matrix strategy could look like this:
```yaml
{% data reusables.actions.actions-not-certified-by-github-comment %}
name: Ruby CI
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix:
ruby-version: [2.7.x, 2.6.x, 2.5.x]
steps:
- uses: actions/checkout@v2
- name: {% raw %}Set up Ruby ${{ matrix.ruby-version }}{% endraw %}
uses: ruby/setup-ruby@477b21f02be01bcb8030d50f37cfec92bfa615b6
with:
ruby-version: {% raw %}${{ matrix.ruby-version }}{% endraw %}
- name: Install dependencies
run: bundle install
- name: Run tests
run: bundle exec rake
```
## Installing dependencies with Bundler
The `setup-ruby` action will automatically install bundler for you. The version is determined by your `gemfile.lock` file. If no version is present in your lockfile, then the latest compatible version will be installed.
{% raw %}
```yaml
steps:
- uses: actions/checkout@v2
- uses: ruby/setup-ruby@477b21f02be01bcb8030d50f37cfec92bfa615b6
with:
ruby-version: 2.6
- run: bundle install
```
{% endraw %}
### Abhängigkeiten „cachen“ (zwischenspeichern)
If you are using {% data variables.product.prodname_dotcom %}-hosted runners, the `setup-ruby` actions provides a method to automatically handle the caching of your gems between runs.
To enable caching, set the following.
{% raw %}
```yaml
steps:
- uses: ruby/setup-ruby@477b21f02be01bcb8030d50f37cfec92bfa615b6
with:
bundler-cache: true
```
{% endraw %}
This will configure bundler to install your gems to `vendor/cache`. For each successful run of your workflow, this folder will be cached by Actions and re-downloaded for subsequent workflow runs. A hash of your gemfile.lock and the Ruby version are used as the cache key. If you install any new gems, or change a version, the cache will be invalidated and bundler will do a fresh install.
**Caching without setup-ruby**
For greater control over caching, if you are using {% data variables.product.prodname_dotcom %}-hosted runners, you can use the `actions/cache` Action directly. Weitere Informationen findest Du unter „<a href="/actions/guides/caching-dependencies-to-speed-up-workflows" class="dotcom-only">Abhängigkeiten zur Beschleunigung von Workflows im Cache zwischenspeichern</a>“.
{% raw %}
```yaml
steps:
- uses: actions/cache@v2
with:
path: vendor/bundle
key: ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }}
restore-keys: |
${{ runner.os }}-gems-
- name: Bundle install
run: |
bundle config path vendor/bundle
bundle install --jobs 4 --retry 3
```
{% endraw %}
If you're using a matrix build, you will want to include the matrix variables in your cache key. For example, if you have a matrix strategy for different ruby versions (`matrix.ruby-version`) and different operating systems (`matrix.os`), your workflow steps might look like this:
{% raw %}
```yaml
steps:
- uses: actions/cache@v2
with:
path: vendor/bundle
key: bundle-use-ruby-${{ matrix.os }}-${{ matrix.ruby-version }}-${{ hashFiles('**/Gemfile.lock') }}
restore-keys: |
bundle-use-ruby-${{ matrix.os }}-${{ matrix.ruby-version }}-
- name: Bundle install
run: |
bundle config path vendor/bundle
bundle install --jobs 4 --retry 3
```
{% endraw %}
## Matrix testing your code
The following example matrix tests all stable releases and head versions of MRI, JRuby and TruffleRuby on Ubuntu and macOS.
```yaml
{% data reusables.actions.actions-not-certified-by-github-comment %}
name: Matrix Testing
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
test:
runs-on: {% raw %}${{ matrix.os }}-latest{% endraw %}
strategy:
fail-fast: false
matrix:
os: [ubuntu, macos]
ruby: [2.5, 2.6, 2.7, head, debug, jruby, jruby-head, truffleruby, truffleruby-head]
continue-on-error: {% raw %}${{ endsWith(matrix.ruby, 'head') || matrix.ruby == 'debug' }}{% endraw %}
steps:
- uses: actions/checkout@v2
- uses: ruby/setup-ruby@477b21f02be01bcb8030d50f37cfec92bfa615b6
with:
ruby-version: {% raw %}${{ matrix.ruby }}{% endraw %}
- run: bundle install
- run: bundle exec rake
```
## Linting your code
The following example installs `rubocop` and uses it to lint all files. For more information, see [Rubocop](https://github.com/rubocop-hq/rubocop). You can [configure Rubocop](https://docs.rubocop.org/rubocop/configuration.html) to decide on the specific linting rules.
```yaml
{% data reusables.actions.actions-not-certified-by-github-comment %}
name: Linting
on: [push]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: ruby/setup-ruby@477b21f02be01bcb8030d50f37cfec92bfa615b6
with:
ruby-version: 2.6
- run: bundle install
- name: Rubocop
run: rubocop
```
## Publishing Gems
You can configure your workflow to publish your Ruby package to any package registry you'd like when your CI tests pass.
You can store any access tokens or credentials needed to publish your package using repository secrets. The following example creates and publishes a package to `GitHub Package Registry` and `RubyGems`.
```yaml
{% data reusables.actions.actions-not-certified-by-github-comment %}
name: Ruby Gem
on:
# Manually publish
workflow_dispatch:
# Alternatively, publish whenever changes are merged to the `main` branch.
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
name: Build + Publish
runs-on: ubuntu-latest{% ifversion fpt or ghes > 3.1 or ghae-next or ghec %}
permissions:
packages: write
contents: read{% endif %}
steps:{% raw %}
- uses: actions/checkout@v2
- name: Set up Ruby 2.6
uses: ruby/setup-ruby@477b21f02be01bcb8030d50f37cfec92bfa615b6
with:
ruby-version: 2.6
- run: bundle install
- name: Publish to GPR
run: |
mkdir -p $HOME/.gem
touch $HOME/.gem/credentials
chmod 0600 $HOME/.gem/credentials
printf -- "---\n:github: ${GEM_HOST_API_KEY}\n" > $HOME/.gem/credentials
gem build *.gemspec
gem push --KEY github --host https://rubygems.pkg.github.com/${OWNER} *.gem
env:
GEM_HOST_API_KEY: "Bearer ${{secrets.GITHUB_TOKEN}}"
OWNER: ${{ github.repository_owner }}
- name: Publish to RubyGems
run: |
mkdir -p $HOME/.gem
touch $HOME/.gem/credentials
chmod 0600 $HOME/.gem/credentials
printf -- "---\n:rubygems_api_key: ${GEM_HOST_API_KEY}\n" > $HOME/.gem/credentials
gem build *.gemspec
gem push *.gem
env:
GEM_HOST_API_KEY: "${{secrets.RUBYGEMS_AUTH_TOKEN}}"{% endraw %}
```

View File

@@ -1,130 +0,0 @@
---
title: Building and testing Swift
intro: You can create a continuous integration (CI) workflow to build and test your Swift project.
redirect_from:
- /actions/guides/building-and-testing-swift
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: tutorial
topics:
- CI
- Swift
shortTitle: Build & test Swift
---
{% 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 build and test a Swift package.
{% ifversion ghae %} To build and test your Swift project on {% data variables.product.prodname_ghe_managed %}, you will need to create a custom operating system image that includes the necessary Swift dependencies. For instructions on how to make sure your {% data variables.actions.hosted_runner %} has the required software installed, see "[Creating custom images](/actions/using-github-hosted-runners/creating-custom-images)."
{% else %}{% data variables.product.prodname_dotcom %}-hosted runners have a tools cache with preinstalled software, and the Ubuntu and macOS runners include the dependencies for building Swift packages. For a full list of up-to-date software and the preinstalled versions of Swift and Xcode, see "[About GitHub-hosted runners](/actions/using-github-hosted-runners/about-github-hosted-runners#supported-software)."{% endif %}
## Vorrausetzungen
You should already be familiar with YAML syntax and how it's used with {% data variables.product.prodname_actions %}. Weitere Informationen findest Du unter „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions)“.
We recommend that you have a basic understanding of Swift packages. For more information, see "[Swift Packages](https://developer.apple.com/documentation/swift_packages)" in the Apple developer documentation.
## Starting with the Swift workflow template
{% data variables.product.prodname_dotcom %} provides a Swift workflow template that should work for most Swift projects, and this guide includes examples that show you how to customize this template. For more information, see the [Swift workflow template](https://github.com/actions/starter-workflows/blob/main/ci/swift.yml).
Um schnell loszulegen, füge die Vorlage in das Verzeichnis `.github/workflows` Deines Repositorys ein.
{% raw %}
```yaml{:copy}
name: Swift
on: [push]
jobs:
build:
runs-on: macos-latest
steps:
- uses: actions/checkout@v2
- name: Build
run: swift build
- name: Run tests
run: swift test
```
{% endraw %}
## Specifying a Swift version
To use a specific preinstalled version of Swift on a {% data variables.product.prodname_dotcom %}-hosted runner, use the `fwal/setup-swift` action. This action finds a specific version of Swift from the tools cache on the runner and adds the necessary binaries to `PATH`. These changes will persist for the remainder of a job. For more information, see the [`fwal/setup-swift`](https://github.com/marketplace/actions/setup-swift) action.
If you are using a self-hosted runner, you must install your desired Swift versions and add them to `PATH`.
The examples below demonstrate using the `fwal/setup-swift` action.
### Using multiple Swift versions
You can configure your job to use a multiple versions of Swift in a build matrix.
```yaml{:copy}
{% data reusables.actions.actions-not-certified-by-github-comment %}
name: Swift
on: [push]
jobs:
build:
name: {% raw %}Swift ${{ matrix.swift }} on ${{ matrix.os }}{% endraw %}
strategy:
matrix:
os: [ubuntu-latest, macos-latest]
swift: ["5.2", "5.3"]
runs-on: {% raw %}${{ matrix.os }}{% endraw %}
steps:
- uses: fwal/setup-swift@d43a564349d1341cd990cfbd70d94d63b8899475
with:
swift-version: {% raw %}${{ matrix.swift }}{% endraw %}
- uses: actions/checkout@
- name: Build
run: swift build
- name: Run tests
run: swift test
```
### Using a single specific Swift version
You can configure your job to use a single specific version of Swift, such as `5.3.3`.
{% raw %}
```yaml{:copy}
steps:
- uses: fwal/setup-swift@d43a564349d1341cd990cfbd70d94d63b8899475
with:
swift-version: "5.3.3"
- name: Get swift version
run: swift --version # Swift 5.3.3
```
{% endraw %}
## Deinen Code bauen und testen
You can use the same commands that you use locally to build and test your code using Swift. This example demonstrates how to use `swift build` and `swift test` in a job:
{% raw %}
```yaml{:copy}
steps:
- uses: actions/checkout@v2
- uses: fwal/setup-swift@d43a564349d1341cd990cfbd70d94d63b8899475
with:
swift-version: "5.3.3"
- name: Build
run: swift build
- name: Run tests
run: swift test
```
{% endraw %}

View File

@@ -1,123 +0,0 @@
---
title: Building and testing Xamarin applications
intro: You can create a continuous integration (CI) workflow in GitHub Actions to build and test your Xamarin application.
redirect_from:
- /actions/guides/building-and-testing-xamarin-applications
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: tutorial
topics:
- CI
- Xamarin
- Xamarin.iOS
- Xamarin.Android
- Android
- iOS
shortTitle: Build & test Xamarin apps
---
{% 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 create a workflow that performs continuous integration (CI) for your Xamarin project. Der Workflow, den Du erstellst, zeigt Dir, wenn Commits zu einem Pull-Request zu Build- oder Testfehlern für deinen Standard-Zweig führen. Dieser Ansatz kann dazu beitragen, dass Dein Code immer brauchbar ist.
For a full list of available Xamarin SDK versions on the {% data variables.product.prodname_actions %}-hosted macOS runners, see the documentation:
* [macOS 10.15](https://github.com/actions/virtual-environments/blob/main/images/macos/macos-10.15-Readme.md#xamarin-bundles)
* [macOS 11](https://github.com/actions/virtual-environments/blob/main/images/macos/macos-11-Readme.md#xamarin-bundles)
{% data reusables.github-actions.macos-runner-preview %}
## Vorrausetzungen
We recommend that you have a basic understanding of Xamarin, .NET Core SDK, YAML, workflow configuration options, and how to create a workflow file. Weitere Informationen findest Du unter:
- „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions)“
- "[Getting started with .NET](https://dotnet.microsoft.com/learn)"
- "[Learn Xamarin](https://dotnet.microsoft.com/learn/xamarin)"
## Building Xamarin.iOS apps
The example below demonstrates how to change the default Xamarin SDK versions and build a Xamarin.iOS application.
{% raw %}
```yaml
name: Build Xamarin.iOS app
on: [push]
jobs:
build:
runs-on: macos-latest
steps:
- uses: actions/checkout@v2
- name: Set default Xamarin SDK versions
run: |
$VM_ASSETS/select-xamarin-sdk-v2.sh --mono=6.12 --ios=14.10
- name: Set default Xcode 12.3
run: |
XCODE_ROOT=/Applications/Xcode_12.3.0.app
echo "MD_APPLE_SDK_ROOT=$XCODE_ROOT" >> $GITHUB_ENV
sudo xcode-select -s $XCODE_ROOT
- name: Setup .NET Core SDK 5.0.x
uses: actions/setup-dotnet@v1
with:
dotnet-version: '5.0.x'
- name: Install dependencies
run: nuget restore <sln_file_path>
- name: Build
run: msbuild <csproj_file_path> /p:Configuration=Debug /p:Platform=iPhoneSimulator /t:Rebuild
```
{% endraw %}
## Building Xamarin.Android apps
The example below demonstrates how to change default Xamarin SDK versions and build a Xamarin.Android application.
{% raw %}
```yaml
name: Build Xamarin.Android app
on: [push]
jobs:
build:
runs-on: macos-latest
steps:
- uses: actions/checkout@v2
- name: Set default Xamarin SDK versions
run: |
$VM_ASSETS/select-xamarin-sdk-v2.sh --mono=6.10 --android=10.2
- name: Setup .NET Core SDK 5.0.x
uses: actions/setup-dotnet@v1
with:
dotnet-version: '5.0.x'
- name: Install dependencies
run: nuget restore <sln_file_path>
- name: Build
run: msbuild <csproj_file_path> /t:PackageForAndroid /p:Configuration=Debug
```
{% endraw %}
## Specifying a .NET version
To use a preinstalled version of the .NET Core SDK on a {% data variables.product.prodname_dotcom %}-hosted runner, use the `setup-dotnet` action. This action finds a specific version of .NET from the tools cache on each runner, and adds the necessary binaries to `PATH`. These changes will persist for the remainder of the job.
The `setup-dotnet` action is the recommended way of using .NET with {% data variables.product.prodname_actions %}, because it ensures consistent behavior across different runners and different versions of .NET. If you are using a self-hosted runner, you must install .NET and add it to `PATH`. For more information, see the [`setup-dotnet`](https://github.com/marketplace/actions/setup-net-core-sdk) action.

View File

@@ -1,32 +0,0 @@
---
title: Automating builds and tests
shortTitle: Build and test
intro: 'You can automatically build and test your projects with {% data variables.product.prodname_actions %}.'
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
redirect_from:
- /actions/building-and-testing-code-with-continuous-integration
- /actions/language-and-framework-guides
- /actions/language-and-framework-guides/github-actions-for-docker
- /actions/language-and-framework-guides/github-actions-for-java
- /actions/language-and-framework-guides/github-actions-for-javascript-and-typescript
- /actions/language-and-framework-guides/github-actions-for-python
children:
- /about-continuous-integration
- /building-and-testing-java-with-ant
- /building-and-testing-java-with-gradle
- /building-and-testing-java-with-maven
- /building-and-testing-net
- /building-and-testing-nodejs-or-python
- /building-and-testing-nodejs
- /building-and-testing-powershell
- /building-and-testing-python
- /building-and-testing-ruby
- /building-and-testing-swift
- /building-and-testing-xamarin-applications
---
{% data reusables.actions.ae-beta %}

View File

@@ -1,173 +0,0 @@
---
title: Informationen zu Aktionen
intro: 'Aktionen sind einzelne Aufgaben, die Du kombinieren kannst, um Aufträge zu erstellen und Deinen Workflow anzupassen. You can create your own actions, or use and customize actions shared by the {% data variables.product.prodname_dotcom %} community.'
product: '{% data reusables.gated-features.actions %}'
redirect_from:
- /articles/about-actions
- /github/automating-your-workflow-with-github-actions/about-actions
- /actions/automating-your-workflow-with-github-actions/about-actions
- /actions/building-actions/about-actions
versions:
free-pro-team: '*'
enterprise-server: '>=2.22'
github-ae: '*'
type: overview
topics:
- Action development
- Fundamentals
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
### Informationen zu Aktionen
Zum Erstellen von Aktionen Kannst Du benutzerdefinierten Code schreiben, der mit Deinem Repository auf die gewünschte Weise interagiert und sich dabei beispielsweise in die APIs von {% data variables.product.prodname_dotcom %} und in öffentlich zugängliche Drittanbieter-APIs integriert. Mit einer Aktion können Sie beispielsweise npm-Module veröffentlichen, SMS-Nachrichten bei dringenden Problemen senden oder produktionsreifen Code bereitstellen.
{% if currentVersion == "free-pro-team@latest" %}
You can write your own actions to use in your workflow or share the actions you build with the
{% data variables.product.prodname_dotcom %} community. Die erstellten Aktionen können nur dann freigegeben werden, wenn das Repository öffentlich ist.
{% endif %}
Aktionen können direkt auf einem Computer oder in einem Docker-Container laufen. Sie können die Eingabe, die Ausgabe und die Umgebungsvariablen für eine Aktion definieren.
### Arten von Aktionen
Sie können Docker-Container- und JavaScript-Aktionen erstellen. Für Aktionen wird eine Metadaten-Datei benötigt, in der die Eingaben, Ausgaben und der Haupteinstiegspunkt für die Aktion definiert werden. Der Dateiname für die Metadaten muss entweder `action.yml` oder `action.yaml` sein. Weitere Informationen findest Du unter „[Metadatensyntax für {% data variables.product.prodname_actions %}](/articles/metadata-syntax-for-github-actions)“.
| Typ | Betriebssystem |
| ------------------------------------ | --------------------- |
| Docker-Container | Linux |
| JavaScript | Linux, macOS, Windows |
| Zusammengesetzte Ausführungsschritte | Linux, macOS, Windows |
#### Docker-Containeraktionen
Docker-Container paketieren die Umgebung mit dem {% data variables.product.prodname_actions %}-Code. So entsteht eine konsistentere, zuverlässigere Arbeitseinheit, da der Aktionsbenutzer sich nicht um Tools oder Abhängigkeiten kümmern muss.
Mit einem Docker-Container können Sie bestimmte Versionen eines Betriebssystems sowie bestimmte Abhängigkeiten, Tools und Code verwenden. Bei Aktionen, die in einer bestimmten Umgebungskonfiguration ausgeführt werden müssen, ist Docker eine ideale Option, da Sie das Betriebssystem und die Tools anpassen können. Wegen der Latenz für das Erstellen und Abrufen des Containers sind Docker-Container-Aktionen langsamer als JavaScript-Aktionen.
Docker Container-Aktionen können nur auf Runnern mit einem Linux-Betriebssystem ausgeführt werden. {% data reusables.github-actions.self-hosted-runner-reqs-docker %}
#### JavaScript-Aktionen
JavaScript-Aktionen können direkt auf einem Runner-Rechner laufen und den Aktions-Code von der Umgebung trennen, in der der Code läuft. Eine JavaScript-Aktion umfasst einfacheren Aktionscode und lässt sich schneller ausführen als eine Docker-Container-Aktion.
{% data reusables.github-actions.pure-javascript %}
Wenn Sie ein Node.js Projekt entwickeln, bietet das {% data variables.product.prodname_actions %} Toolkit Pakete, die Sie in Ihrem Projekt verwenden können, um die Entwicklung zu beschleunigen. Weitere Informationen findest Du im Repository [actions/toolkit](https://github.com/actions/toolkit).
#### Zusammengesetzte Ausführungsschritte Aktionen
A _composite run steps_ action allows you to combine multiple workflow run steps within one action. For example, you can use this feature to bundle together multiple run commands into an action, and then have a workflow that executes the bundled commands a single step using that action. To see an example, check out "[Creating a composite run steps action](/actions/creating-actions/creating-a-composite-run-steps-action)".
### Ort für eine Aktion auswählen
Wenn Du eine Aktion entwickelst, die von anderen Personen genutzt werden soll, empfehlen wir, die Aktion in ihrem eigenen Repository zu belassen, also nicht mit anderem Anwendungscode zu einem Bundle zusammenzufassen. Damit kannst Du die Aktion wie jede andere Software versionieren, nachverfolgen und veröffentlichen.
{% if currentVersion == "free-pro-team@latest" %}
Storing an action in its own repository makes it easier for the
{% data variables.product.prodname_dotcom %} community to discover the action, narrows the scope of the code base for developers fixing issues and extending the action, and decouples the action's versioning from the versioning of other application code.
{% endif %}
{% if currentVersion == "free-pro-team@latest" %}If you're building an action that you don't plan to make available to the public, you {% else %} You{% endif %} can store the action's files in any location in your repository. Wenn der Aktions-, der Workflow- und der Anwendungscode in einem einzigen Repository abgelegt werden sollen, empfehlen wir, die Aktionen im Verzeichnis `.github` zu speichern. Beispiel: `.github/actions/action-a` und `.github/actions/action-b`.
### Compatibility with {% data variables.product.prodname_ghe_server %}
To ensure that your action is compatible with {% data variables.product.prodname_ghe_server %}, you should make sure that you do not use any hard-coded references to {% data variables.product.prodname_dotcom %} API URLs. You should instead use environment variables to refer to the {% data variables.product.prodname_dotcom %} API:
- Verwenden Sie für die REST-API die `GITHUB_API_URL` -Umgebungsvariable.
- Verwenden Sie für GraphQL die Umgebungsvariable `GITHUB_GRAPHQL_URL` .
For more information, see "[Default environment variables](/actions/configuring-and-managing-workflows/using-environment-variables#default-environment-variables)."
### Verwenden der Releaseverwaltung für Aktionen
This section explains how you can use release management to distribute updates to your actions in a predictable way.
#### Bewährte Verfahren für das Release-Management
If you're developing an action for other people to use, we recommend using release management to control how you distribute updates. Users can expect an action's major version to include necessary critical fixes and security patches, while still remaining compatible with their existing workflows. You should consider releasing a new major version whenever your changes affect compatibility.
Bei diesem Releaseverwaltungsansatz sollten Benutzer nicht auf den `Master` Zweig einer Aktion verweisen, da dieser wahrscheinlich den neuesten Code enthält und daher möglicherweise instabil ist. Instead, you can recommend that your users specify a major version when using your action, and only direct them to a more specific version if they encounter issues.
To use a specific action version, users can configure their {% data variables.product.prodname_actions %} workflow to target a tag, a commit's SHA, or a branch named for a release.
#### Verwenden von Tags für die Releaseverwaltung
We recommend using tags for actions release management. Using this approach, your users can easily distinguish between major and minor versions:
- Erstellen und überprüfen Sie eine Version auf einem Release-Zweig (z. B. `release/v1`), bevor Sie das Release-Tag erstellen (z. B. `v1.0.2`).
- Erstellen Sie eine Version mit semantischer Versionierung. Weitere Informationen finden Sie unter „[Veröffentlichungen erstellen](/articles/creating-releases)“.
- Verschieben Sie das Hauptversions-Tag (z. B. `v1`, `v2`), um auf die Git-Ref der aktuellen Version zu verweisen. Weitere Informationen findest Du unter „[Git-Grundlagen - Tagging](https://git-scm.com/book/en/v2/Git-Basics-Tagging)“.
- Führen Sie ein neues Hauptversions-Tag (`v2`) für Änderungen ein, die vorhandene Workflows unterbrechen. Eine störende Änderung liegt beispielsweise vor, wenn die Eingabe einer Aktion geändert wird.
- Hauptversionen können zunächst mit einem `Beta-` -Tag veröffentlicht werden, um ihren Status anzugeben, z. B. `v2-beta`. Das `-beta-` -Tag kann dann entfernt werden, wenn es fertig ist.
This example demonstrates how a user can reference a major release tag:
```yaml
Schritte:
- verwendet: actions/javascript-action@v1
```
This example demonstrates how a user can reference a specific patch release tag:
```yaml
Schritte:
- verwendet: actions/javascript-action@v1.0.1
```
#### Verwenden von Zweigen für die Releaseverwaltung
If you prefer to use branch names for release management, this example demonstrates how to reference a named branch:
```yaml
Schritte:
- verwendet: actions/javascript-action@v1-beta
```
#### Verwenden des SHA eines Commits für die Releaseverwaltung
Each Git commit receives a calculated SHA value, which is unique and immutable. Your action's users might prefer to rely on a commit's SHA value, as this approach can be more reliable than specifying a tag, which could be deleted or moved. However, this means that users will not receive further updates made to the action. {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" or currentVersion == "github-ae@latest" %}You must use a commit's full SHA value, and not an abbreviated value.{% else %}Using a commit's full SHA value instead of the abbreviated value can help prevent people from using a malicious commit that uses the same abbreviation.{% endif %}
```yaml
Schritte:
- verwendet: actions/javascript-action@172239021f7ba04fe7327647b213799853a9eb89
```
### Eine README-Datei für die Aktion erstellen
Wenn Du Deine Aktion öffentlich bereitstellen möchten, empfehlen wir, eine README-Datei zu erstellen, damit andere Benutzer verstehen, wie die Aktion zu verwenden ist. Du kannst die folgenden Informationen in Ihre `README.md`-Datei aufnehmen:
- eine ausführliche Beschreibung, was die Aktion bewirkt
- erforderliche Eingabe- und Ausgabeargumente
- optionale Eingabe- und Ausgabeargumente
- Geheimnisse, die in der Aktion verwendet werden
- Umgebungsvariablen, die in der Aktion verwendet werden
- ein Beispiel für die Verwendung der Aktion in einem Workflow
### Unterschiede zwischen {% data variables.product.prodname_actions %} und {% data variables.product.prodname_github_apps %}
{% data variables.product.prodname_marketplace %} bietet Tools, um Deinen Workflow zu verbessern. Wenn Du die Unterschiede und die Vorteile der einzelnen Tools verstehst, kannst Du das beste Tool für Deinen Auftrag auswählen. For more information about building apps, see "[About apps](/apps/about-apps/)."
#### Stärken von GitHub Aktionen und GitHub Apps
Beide, sowohl {% data variables.product.prodname_actions %} als auch {% data variables.product.prodname_github_app %}s unterstützen die Erstellung von Automatisierungs- und Workflow-Tools. Dennoch haben beide ihre unterschiedlichen nützlichen Stärken.
{% data variables.product.prodname_github_apps %}:
* Laufen dauerhaft und können schnell auf Ereignisse reagieren.
* Funktionieren hervorragend, wenn persistente Daten benötigt werden.
* Funktionieren am besten mit API-Anforderungen, die nicht zeitaufwändig sind.
* Laufen auf Deinem Server oder auf Deiner Rechner-Infrastruktur.
{% data variables.product.prodname_actions %}:
* Bieten Automatisierung für eine kontinuierliche Integration und kontinuierliche Bereitstellung.
* Können direkt auf Runner-Maschinen oder in Docker-Containern laufen.
* Können auch Zugriff auf einen Clone Ihres Repositorys einschließen und dadurch Bereitstellungs- und Veröffentlichungs-Tools, Code-Formatierer und Befehlszeilen-Tools den Zugriff auf Ihren Code erlauben.
* Erfordern weder, dass Du Code noch eine App bereitstellst.
* Verfügen Sie über eine einfache Schnittstelle zum Erstellen und Verwenden von Geheimnissen. Dadurch können die Aktionen mit Diensten von Drittanbietern interagieren, ohne die Anmelde-Informationen des Aktions-Benutzers speichern zu müssen.
### Weiterführende Informationen
- „[Entwicklungstools für {% data variables.product.prodname_actions %}](/articles/development-tools-for-github-actions)“

View File

@@ -1,172 +0,0 @@
---
title: About custom actions
intro: 'Aktionen sind einzelne Aufgaben, die Du kombinieren kannst, um Aufträge zu erstellen und Deinen Workflow anzupassen. You can create your own actions, or use and customize actions shared by the {% data variables.product.prodname_dotcom %} community.'
redirect_from:
- /articles/about-actions
- /github/automating-your-workflow-with-github-actions/about-actions
- /actions/automating-your-workflow-with-github-actions/about-actions
- /actions/building-actions/about-actions
- /actions/creating-actions/about-actions
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: overview
topics:
- Action development
- Fundamentals
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
## About custom actions
Zum Erstellen von Aktionen Kannst Du benutzerdefinierten Code schreiben, der mit Deinem Repository auf die gewünschte Weise interagiert und sich dabei beispielsweise in die APIs von {% data variables.product.prodname_dotcom %} und in öffentlich zugängliche Drittanbieter-APIs integriert. Mit einer Aktion können Sie beispielsweise npm-Module veröffentlichen, SMS-Nachrichten bei dringenden Problemen senden oder produktionsreifen Code bereitstellen.
{% ifversion fpt or ghec %}
Sie können eigene Aktionen schreiben und ausschließlich in Ihrem Workflow verwenden oder auch Ihre erstellten Aktionen mit der {% data variables.product.prodname_dotcom %}-Community schreiben. Die erstellten Aktionen können nur dann freigegeben werden, wenn das Repository öffentlich ist.
{% endif %}
Aktionen können direkt auf einem Computer oder in einem Docker-Container laufen. Sie können die Eingabe, die Ausgabe und die Umgebungsvariablen für eine Aktion definieren.
## Arten von Aktionen
Sie können Docker-Container- und JavaScript-Aktionen erstellen. Für Aktionen wird eine Metadaten-Datei benötigt, in der die Eingaben, Ausgaben und der Haupteinstiegspunkt für die Aktion definiert werden. Der Dateiname für die Metadaten muss entweder `action.yml` oder `action.yaml` sein. Weitere Informationen findest Du unter „[Metadatensyntax für {% data variables.product.prodname_actions %}](/articles/metadata-syntax-for-github-actions)“.
| Typ | Betriebssystem |
| ----------------- | --------------------- |
| Docker-Container | Linux |
| JavaScript | Linux, macOS, Windows |
| Composite Actions | Linux, macOS, Windows |
### Docker-Containeraktionen
Docker-Container paketieren die Umgebung mit dem {% data variables.product.prodname_actions %}-Code. So entsteht eine konsistentere, zuverlässigere Arbeitseinheit, da der Aktionsbenutzer sich nicht um Tools oder Abhängigkeiten kümmern muss.
Mit einem Docker-Container können Sie bestimmte Versionen eines Betriebssystems sowie bestimmte Abhängigkeiten, Tools und Code verwenden. Bei Aktionen, die in einer bestimmten Umgebungskonfiguration ausgeführt werden müssen, ist Docker eine ideale Option, da Sie das Betriebssystem und die Tools anpassen können. Wegen der Latenz für das Erstellen und Abrufen des Containers sind Docker-Container-Aktionen langsamer als JavaScript-Aktionen.
Docker Container-Aktionen können nur auf Runnern mit einem Linux-Betriebssystem ausgeführt werden. {% data reusables.github-actions.self-hosted-runner-reqs-docker %}
### JavaScript-Aktionen
JavaScript-Aktionen können direkt auf einem Runner-Rechner laufen und den Aktions-Code von der Umgebung trennen, in der der Code läuft. Eine JavaScript-Aktion umfasst einfacheren Aktionscode und lässt sich schneller ausführen als eine Docker-Container-Aktion.
{% data reusables.github-actions.pure-javascript %}
Wenn Sie ein Node.js Projekt entwickeln, bietet das {% data variables.product.prodname_actions %} Toolkit Pakete, die Sie in Ihrem Projekt verwenden können, um die Entwicklung zu beschleunigen. Weitere Informationen findest Du im Repository [actions/toolkit](https://github.com/actions/toolkit).
### Composite Actions
A _composite_ action allows you to combine multiple workflow steps within one action. For example, you can use this feature to bundle together multiple run commands into an action, and then have a workflow that executes the bundled commands as a single step using that action. To see an example, check out "[Creating a composite action](/actions/creating-actions/creating-a-composite-action)".
## Ort für eine Aktion auswählen
Wenn Du eine Aktion entwickelst, die von anderen Personen genutzt werden soll, empfehlen wir, die Aktion in ihrem eigenen Repository zu belassen, also nicht mit anderem Anwendungscode zu einem Bundle zusammenzufassen. Damit kannst Du die Aktion wie jede andere Software versionieren, nachverfolgen und veröffentlichen.
{% ifversion fpt or ghec %}
Wenn Sie eine Aktion in einem eigenen Repository speichern, kann die {% data variables.product.prodname_dotcom %}-Community die Aktion eher entdecken. Außerdem wird damit die Codebasis begrenzt, auf die die Entwickler bei der Fehlerbehebung und bei der Erweiterung der Aktion angewiesen sind, und die Versionierung der Aktion wird von der Versionierung des anderen Anwendungscodes getrennt.
{% endif %}
{% ifversion fpt or ghec %}If you're building an action that you don't plan to make available to the public, you {% else %} You{% endif %} can store the action's files in any location in your repository. Wenn der Aktions-, der Workflow- und der Anwendungscode in einem einzigen Repository abgelegt werden sollen, empfehlen wir, die Aktionen im Verzeichnis `.github` zu speichern. Beispiel: `.github/actions/action-a` und `.github/actions/action-b`.
## Compatibility with {% data variables.product.prodname_ghe_server %}
To ensure that your action is compatible with {% data variables.product.prodname_ghe_server %}, you should make sure that you do not use any hard-coded references to {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API URLs. You should instead use environment variables to refer to the {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API:
- Verwenden Sie für die REST-API die `GITHUB_API_URL` -Umgebungsvariable.
- Verwenden Sie für GraphQL die Umgebungsvariable `GITHUB_GRAPHQL_URL` .
For more information, see "[Default environment variables](/actions/configuring-and-managing-workflows/using-environment-variables#default-environment-variables)."
## Using release management for actions
This section explains how you can use release management to distribute updates to your actions in a predictable way.
### Good practices for release management
If you're developing an action for other people to use, we recommend using release management to control how you distribute updates. Users can expect an action's major version to include necessary critical fixes and security patches, while still remaining compatible with their existing workflows. You should consider releasing a new major version whenever your changes affect compatibility.
Bei diesem Releaseverwaltungsansatz sollten Benutzer nicht auf den `Master` Zweig einer Aktion verweisen, da dieser wahrscheinlich den neuesten Code enthält und daher möglicherweise instabil ist. Instead, you can recommend that your users specify a major version when using your action, and only direct them to a more specific version if they encounter issues.
To use a specific action version, users can configure their {% data variables.product.prodname_actions %} workflow to target a tag, a commit's SHA, or a branch named for a release.
### Using tags for release management
We recommend using tags for actions release management. Using this approach, your users can easily distinguish between major and minor versions:
- Erstellen und überprüfen Sie eine Version auf einem Release-Zweig (z. B. `release/v1`), bevor Sie das Release-Tag erstellen (z. B. `v1.0.2`).
- Erstellen Sie eine Version mit semantischer Versionierung. Weitere Informationen finden Sie unter „[Veröffentlichungen erstellen](/articles/creating-releases)“.
- Verschieben Sie das Hauptversions-Tag (z. B. `v1`, `v2`), um auf die Git-Ref der aktuellen Version zu verweisen. Weitere Informationen findest Du unter „[Git-Grundlagen - Tagging](https://git-scm.com/book/en/v2/Git-Basics-Tagging)“.
- Führen Sie ein neues Hauptversions-Tag (`v2`) für Änderungen ein, die vorhandene Workflows unterbrechen. Eine störende Änderung liegt beispielsweise vor, wenn die Eingabe einer Aktion geändert wird.
- Hauptversionen können zunächst mit einem `Beta-` -Tag veröffentlicht werden, um ihren Status anzugeben, z. B. `v2-beta`. Das `-beta-` -Tag kann dann entfernt werden, wenn es fertig ist.
This example demonstrates how a user can reference a major release tag:
```yaml
Schritte:
- verwendet: actions/javascript-action@v1
```
This example demonstrates how a user can reference a specific patch release tag:
```yaml
Schritte:
- verwendet: actions/javascript-action@v1.0.1
```
### Using branches for release management
If you prefer to use branch names for release management, this example demonstrates how to reference a named branch:
```yaml
Schritte:
- verwendet: actions/javascript-action@v1-beta
```
### Using a commit's SHA for release management
Each Git commit receives a calculated SHA value, which is unique and immutable. Your action's users might prefer to rely on a commit's SHA value, as this approach can be more reliable than specifying a tag, which could be deleted or moved. However, this means that users will not receive further updates made to the action. {% ifversion fpt or ghes > 3.0 or ghae or ghec %}You must use a commit's full SHA value, and not an abbreviated value.{% else %}Using a commit's full SHA value instead of the abbreviated value can help prevent people from using a malicious commit that uses the same abbreviation.{% endif %}
```yaml
Schritte:
- verwendet: actions/javascript-action@172239021f7ba04fe7327647b213799853a9eb89
```
## Eine README-Datei für die Aktion erstellen
Wenn Du Deine Aktion öffentlich bereitstellen möchten, empfehlen wir, eine README-Datei zu erstellen, damit andere Benutzer verstehen, wie die Aktion zu verwenden ist. Du kannst die folgenden Informationen in Ihre `README.md`-Datei aufnehmen:
- eine ausführliche Beschreibung, was die Aktion bewirkt
- erforderliche Eingabe- und Ausgabeargumente
- optionale Eingabe- und Ausgabeargumente
- Geheimnisse, die in der Aktion verwendet werden
- Umgebungsvariablen, die in der Aktion verwendet werden
- ein Beispiel für die Verwendung der Aktion in einem Workflow
## Unterschiede zwischen {% data variables.product.prodname_actions %} und {% data variables.product.prodname_github_apps %}
{% data variables.product.prodname_marketplace %} bietet Tools, um Deinen Workflow zu verbessern. Wenn Du die Unterschiede und die Vorteile der einzelnen Tools verstehst, kannst Du das beste Tool für Deinen Auftrag auswählen. For more information about building apps, see "[About apps](/apps/about-apps/)."
### Stärken von GitHub Aktionen und GitHub Apps
While both {% data variables.product.prodname_actions %} and {% data variables.product.prodname_github_apps %} provide ways to build automation and workflow tools, they each have strengths that make them useful in different ways.
{% data variables.product.prodname_github_apps %}:
* Laufen dauerhaft und können schnell auf Ereignisse reagieren.
* Funktionieren hervorragend, wenn persistente Daten benötigt werden.
* Funktionieren am besten mit API-Anforderungen, die nicht zeitaufwändig sind.
* Laufen auf Deinem Server oder auf Deiner Rechner-Infrastruktur.
{% data variables.product.prodname_actions %}:
* Bieten Automatisierung für eine kontinuierliche Integration und kontinuierliche Bereitstellung.
* Können direkt auf Runner-Maschinen oder in Docker-Containern laufen.
* Können auch Zugriff auf einen Clone Ihres Repositorys einschließen und dadurch Bereitstellungs- und Veröffentlichungs-Tools, Code-Formatierer und Befehlszeilen-Tools den Zugriff auf Ihren Code erlauben.
* Erfordern weder, dass Du Code noch eine App bereitstellst.
* Verfügen Sie über eine einfache Schnittstelle zum Erstellen und Verwenden von Geheimnissen. Dadurch können die Aktionen mit Diensten von Drittanbietern interagieren, ohne die Anmelde-Informationen des Aktions-Benutzers speichern zu müssen.
## Weiterführende Informationen
- „[Entwicklungstools für {% data variables.product.prodname_actions %}](/articles/development-tools-for-github-actions)“

View File

@@ -1,139 +0,0 @@
---
title: Creating a composite action
intro: 'In this guide, you''ll learn how to build a composite action.'
redirect_from:
- /actions/creating-actions/creating-a-composite-run-steps-action
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: tutorial
topics:
- Action development
shortTitle: Composite action
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
## Einführung
In this guide, you'll learn about the basic components needed to create and use a packaged composite action. Diese Anleitung fokussiert jene Komponenten, welche zum Paketieren der Aktion benötigt werden. Daher hat der Aktions-Code nur minimale Funktionalität. The action prints "Hello World" and then "Goodbye", or if you provide a custom name, it prints "Hello [who-to-greet]" and then "Goodbye". The action also maps a random number to the `random-number` output variable, and runs a script named `goodbye.sh`.
Once you complete this project, you should understand how to build your own composite action and test it in a workflow.
{% data reusables.github-actions.context-injection-warning %}
## Vorrausetzungen
Before you begin, you'll create a repository on {% ifversion ghae %}{% data variables.product.product_name %}{% else %}{% data variables.product.product_location %}{% endif %}.
1. Create a new public repository on {% data variables.product.product_location %}. You can choose any repository name, or use the following `hello-world-composite-action` example. Du kannst diese Dateien hinzufügen, nachdem Dein Projekt per Push an {% data variables.product.product_name %} übergeben wurde. Weitere Informationen finden Sie unter „[Neues Repository erstellen](/articles/creating-a-new-repository)“.
1. Clone Dein Repository auf Deinen Computer. Weitere Informationen findest Du unter „[Ein Repository clonen](/articles/cloning-a-repository)“.
1. Gehe in Deinem Terminal zum Verzeichnisse Deines neuen Repositorys.
```shell
cd hello-world-composite-action
```
2. In the `hello-world-composite-action` repository, create a new file called `goodbye.sh`, and add the following example code:
```bash
echo "Auf Wiedersehen"
```
3. From your terminal, make `goodbye.sh` executable.
```shell
chmod +x goodbye.sh
```
1. Checken Sie von Ihrem Terminal aus Ihre `goodbye.sh` Datei ein.
```shell
git add goodbye.sh
git commit -m "Add goodbye script"
git push
```
## Eine Datei für die Metadaten der Aktion erstellen
1. In the `hello-world-composite-action` repository, create a new file called `action.yml` and add the following example code. For more information about this syntax, see "[`runs` for a composite actions](/actions/creating-actions/metadata-syntax-for-github-actions#runs-for-composite-actions)".
{% raw %}
**action.yml**
```yaml
name: 'Hello World'
description: 'Greet someone'
inputs:
who-to-greet: # id of input
description: 'Who to greet'
required: true
default: 'World'
outputs:
random-number:
description: "Random number"
value: ${{ steps.random-number-generator.outputs.random-id }}
runs:
using: "composite"
steps:
- run: echo Hello ${{ inputs.who-to-greet }}.
shell: bash
- id: random-number-generator
run: echo "::set-output name=random-id::$(echo $RANDOM)"
shell: bash
- run: ${{ github.action_path }}/goodbye.sh
shell: bash
```
{% endraw %}
Diese Datei definiert die `Who-to-Greet-` Eingabe, ordnet die zuzufällig generierte Zahl der `Zufallszahl` Ausgabevariablen zu und führt das `goodbye.sh` Skript aus. It also tells the runner how to execute the composite action.
For more information about managing outputs, see "[`outputs` for a composite action](/actions/creating-actions/metadata-syntax-for-github-actions#outputs-for-composite-actions)".
Weitere Informationen zur Verwendung von `github.action_path`finden Sie unter "[`github context`](/actions/reference/context-and-expression-syntax-for-github-actions#github-context)".
1. From your terminal, check in your `action.yml` file.
```shell
git add action.yml
git commit -m "Add action"
git push
```
1. From your terminal, add a tag. This example uses a tag called `v1`. Weitere Informationen finden Sie unter „[Informationen zu Aktionen](/actions/creating-actions/about-actions#using-release-management-for-actions)“.
```shell
git tag -a -m "Description of this release" v1
git push --follow-tags
```
## Deine Aktion in einem Workflow testen
The following workflow code uses the completed hello world action that you made in "[Creating an action metadata file](/actions/creating-actions/creating-a-composite-action#creating-an-action-metadata-file)".
Copy the workflow code into a `.github/workflows/main.yml` file in another repository, but replace `actions/hello-world-composite-action@v1` with the repository and tag you created. Darüber hinaus können Sie die Eingabe `who-to-greet` durch Ihren Namen ersetzen.
{% raw %}
**.github/workflows/main.yml**
```yaml
on: [push]
jobs:
hello_world_job:
runs-on: ubuntu-latest
name: A job to say hello
steps:
- uses: actions/checkout@v2
- id: foo
uses: actions/hello-world-composite-action@v1
with:
who-to-greet: 'Mona the Octocat'
- run: echo random-number ${{ steps.foo.outputs.random-number }}
shell: bash
```
{% endraw %}
Klicke in Deinem Repository auf die Registerkarte **Actions** (Aktionen), und wähle die neueste Workflow-Ausführung aus. The output should include: "Hello Mona the Octocat", the result of the "Goodbye" script, and a random number.

View File

@@ -1,136 +0,0 @@
---
title: Erstellen einer zusammengesetzten Ausführungsschritteaktion
intro: 'In diesem Handbuch erfahren Sie, wie Sie eine Aktion für zusammengesetzte Ausführungsschritte erstellen.'
product: '{% data reusables.gated-features.actions %}'
versions:
free-pro-team: '*'
enterprise-server: '>=2.22'
github-ae: '*'
type: tutorial
topics:
- Action development
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
### Einführung
In this guide, you'll learn about the basic components needed to create and use a packaged composite run steps action. Diese Anleitung fokussiert jene Komponenten, welche zum Paketieren der Aktion benötigt werden. Daher hat der Aktions-Code nur minimale Funktionalität. The action prints "Hello World" and then "Goodbye", or if you provide a custom name, it prints "Hello [who-to-greet]" and then "Goodbye". The action also maps a random number to the `random-number` output variable, and runs a script named `goodbye.sh`.
Once you complete this project, you should understand how to build your own composite run steps action and test it in a workflow.
{% data reusables.github-actions.context-injection-warning %}
### Vorrausetzungen
Before you begin, you'll create a {% data variables.product.product_name %} repository.
1. Create a new public repository on {% data variables.product.product_location %}. Sie können einen beliebigen Repository-Namen auswählen oder die folgenden `hello-world-composite-run-steps-action` Beispiel verwenden. Du kannst diese Dateien hinzufügen, nachdem Dein Projekt per Push an {% data variables.product.product_name %} übergeben wurde. Weitere Informationen finden Sie unter „[Neues Repository erstellen](/articles/creating-a-new-repository)“.
1. Clone Dein Repository auf Deinen Computer. Weitere Informationen findest Du unter „[Ein Repository clonen](/articles/cloning-a-repository)“.
1. Gehe in Deinem Terminal zum Verzeichnisse Deines neuen Repositorys.
```shell
cd hello-world-composite-run-steps-action
```
2. Erstellen Sie im `hello-world-composite-run-steps-action` -Repository eine neue Datei mit dem Namen `goodbye.sh`, und fügen Sie den folgenden Beispielcode hinzu:
```bash
echo "Auf Wiedersehen"
```
3. From your terminal, make `goodbye.sh` executable.
```shell
chmod +x goodbye.sh
```
1. Checken Sie von Ihrem Terminal aus Ihre `goodbye.sh` Datei ein.
```shell
git add goodbye.sh
git commit -m "Add goodbye script"
git push
```
### Eine Datei für die Metadaten der Aktion erstellen
1. Erstellen Sie im `hello-world-composite-run-steps-action` -Repository eine neue Datei mit dem Namen `action.yml` und fügen Sie den folgenden Beispielcode hinzu. Weitere Informationen zu dieser Syntax finden Sie unter "[`` für eine zusammengesetzte Ausführungsschritte](/actions/creating-actions/metadata-syntax-for-github-actions#runs-for-composite-run-steps-actions)ausgeführt wird."
{% raw %}
**action.yml**
```yaml
name: 'Hello World'
description: 'Greet someone'
inputs:
who-to-greet: # id of input
description: 'Who to greet'
required: true
default: 'World'
outputs:
random-number:
description: "Random number"
value: ${{ steps.random-number-generator.outputs.random-id }}
runs:
using: "composite"
steps:
- run: echo Hello ${{ inputs.who-to-greet }}.
shell: bash
- id: random-number-generator
run: echo "::set-output name=random-id::$(echo $RANDOM)"
shell: bash
- run: ${{ github.action_path }}/goodbye.sh
shell: bash
```
{% endraw %}
Diese Datei definiert die `Who-to-Greet-` Eingabe, ordnet die zuzufällig generierte Zahl der `Zufallszahl` Ausgabevariablen zu und führt das `goodbye.sh` Skript aus. Außerdem wird dem Läufer erläutert, wie die Aktion "Composite-Laufschritte" ausgeführt werden soll.
Weitere Informationen zum Verwalten von Ausgaben finden Sie unter "[`Ausgaben` für eine zusammengesetzte Ausführungsschritte](/actions/creating-actions/metadata-syntax-for-github-actions#outputs-for-composite-run-steps-actions)".
Weitere Informationen zur Verwendung von `github.action_path`finden Sie unter "[`github context`](/actions/reference/context-and-expression-syntax-for-github-actions#github-context)".
1. From your terminal, check in your `action.yml` file.
```shell
git add action.yml
git commit -m "Add action"
git push
```
1. From your terminal, add a tag. This example uses a tag called `v1`. Weitere Informationen finden Sie unter „[Informationen zu Aktionen](/actions/creating-actions/about-actions#using-release-management-for-actions)“.
```shell
git tag -a -m "Description of this release" v1
git push --follow-tags
```
### Deine Aktion in einem Workflow testen
The following workflow code uses the completed hello world action that you made in "[Creating an action metadata file](/actions/creating-actions/creating-a-composite-run-steps-action#creating-an-action-metadata-file)".
Copy the workflow code into a `.github/workflows/main.yml` file in another repository, but replace `actions/hello-world-composite-run-steps-action@v1` with the repository and tag you created. Darüber hinaus können Sie die Eingabe `who-to-greet` durch Ihren Namen ersetzen.
{% raw %}
**.github/workflows/main.yml**
```yaml
on: [push]
jobs:
hello_world_job:
runs-on: ubuntu-latest
name: A job to say hello
steps:
- uses: actions/checkout@v2
- id: foo
uses: actions/hello-world-composite-run-steps-action@v1
with:
who-to-greet: 'Mona the Octocat'
- run: echo random-number ${{ steps.foo.outputs.random-number }}
shell: bash
```
{% endraw %}
Klicke in Deinem Repository auf die Registerkarte **Actions** (Aktionen), und wähle die neueste Workflow-Ausführung aus. The output should include: "Hello Mona the Octocat", the result of the "Goodbye" script, and a random number.

View File

@@ -1,247 +0,0 @@
---
title: Eine Docker-Container-Aktion erstellen
intro: In diesem Leitfaden werden die mindestens erforderlichen Schritte zum Erstellen einer Docker-Container-Aktion beschrieben.
redirect_from:
- /articles/creating-a-docker-container-action
- /github/automating-your-workflow-with-github-actions/creating-a-docker-container-action
- /actions/automating-your-workflow-with-github-actions/creating-a-docker-container-action
- /actions/building-actions/creating-a-docker-container-action
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: tutorial
topics:
- Action development
- Docker
shortTitle: Docker container action
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
## Einführung
In dieser Anleitung erfährst Du mehr über die grundlegenden Komponenten, die benötigt werden, um eine paketierte Docker-Container-Aktion zu erstellen und zu verwenden. Diese Anleitung fokussiert jene Komponenten, welche zum Paketieren der Aktion benötigt werden. Daher hat der Aktions-Code nur minimale Funktionalität. Die Aktion schreibt „Hello World“ in die Logs oder "Hello [who-to-greet]" wenn du einen benutzerdefinierten Namen angibst.
Nach dem Abschluss dieses Projekts wirst Du verstehen, wie Du Deine eigene Docker-Containeraktion erstellen und sie in einem Workflow testen kannst.
{% data reusables.github-actions.self-hosted-runner-reqs-docker %}
{% data reusables.github-actions.context-injection-warning %}
## Vorrausetzungen
Es wir Dir vielleicht helfen, {% data variables.product.prodname_actions %} Umgebungsvariablen und das Docker-Container-Dateisystem grundlegend zu verstehen:
- "[Umgebungsvariablen verwenden](/actions/automating-your-workflow-with-github-actions/using-environment-variables)"
{% ifversion ghae %}
- "[Docker container filesystem](/actions/using-github-hosted-runners/about-ae-hosted-runners#docker-container-filesystem)."
{% else %}
- "[Virtuelle Umgebungen für {% data variables.product.prodname_dotcom %}](/actions/automating-your-workflow-with-github-actions/virtual-environments-for-github-hosted-runners#docker-container-filesystem)"
{% endif %}
Before you begin, you'll need to create a {% data variables.product.prodname_dotcom %} repository.
1. Erstellen Sie ein neues Repository auf {% data variables.product.product_location %}. Du kannst einen beliebigen Repository-Namen auswählen oder wie in diesem Beispiel „hello-world-docker-action“ verwenden. Weitere Informationen finden Sie unter „[Neues Repository erstellen](/articles/creating-a-new-repository)“.
1. Clone Dein Repository auf Deinen Computer. Weitere Informationen findest Du unter „[Ein Repository clonen](/articles/cloning-a-repository)“.
1. Gehe in Deinem Terminal zum Verzeichnisse Deines neuen Repositorys.
```shell{:copy}
cd hello-world-docker-action
```
## Eine Docker-Datei erstellen
Erstelle im neuen Verzeichnis `hello-world-docker-action` eine neue `Dockerfile`-Datei. For more information, see "[Dockerfile support for {% data variables.product.prodname_actions %}](/actions/creating-actions/dockerfile-support-for-github-actions)."
**Dockerfile**
```Dockerfile{:copy}
# Container-Image, das Deinen Code ausführt
FROM alpine:3.10
# Kopiert die Codedatei aus Deinem Aktions-Repository in den Dateisystempfad `/` des Containers
COPY entrypoint.sh /entrypoint.sh
# Codedatei, die beim Start des Docker-Containers ausgeführt werden soll (`entrypoint.sh`)
ENTRYPOINT ["/entrypoint.sh"]
```
## Eine Datei für die Metadaten der Aktion erstellen
Erstelle eine neue `action.yml`-Datei im oben von Dir erstellten Verzeichnis `hello-world-docker-action`. Weitere Informationen findest Du unter „[Metadaten-Syntax für {% data variables.product.prodname_actions %}](/actions/creating-actions/metadata-syntax-for-github-actions)“.
{% raw %}
**action.yml**
```yaml{:copy}
# action.yml
name: 'Hello World'
description: 'Greet someone and record the time'
inputs:
who-to-greet: # Eingabe-ID
description: 'Who to greet'
required: true
default: 'World'
outputs:
time: # Ausgabe-ID
description: 'The time we greeted you'
runs:
using: 'docker'
image: 'Dockerfile'
args:
- ${{ inputs.who-to-greet }}
```
{% endraw %}
Diese Metadaten definieren einen `who-to-greet`-Eingabe- und einen `time`-Ausgabeparameter. Um Eingaben an den Docker-Container weiterzugeben, musst Du die Eingabe mit `inputs` deklarieren und die Eingabe im Schlüsselwort`args` weitergeben.
{% data variables.product.prodname_dotcom %} erstellt basierend auf Ihrem `Dockerfile` ein Image und führt mithilfe dieses Images Befehle in einem neuen Container aus.
## Aktions-Code schreiben
Du kannst ein beliebiges Basis-Docker-Image und folglich auch eine beliebige Sprache für Deine Aktion auswählen. Im folgenden Shellskript-Beispiel wird die Eingabevariable `who-to-greet` verwendet, um in der Protokolldatei „Hello [who-to-greet]“ auszugeben.
Als Nächstes ruft das Skript die aktuelle Zeit ab und legt sie als eine Ausgabevariable fest, die von später in einem Auftrag ausgeführten Aktionen verwendet werden kann. Damit {% data variables.product.prodname_dotcom %} Ausgabevariablen erkennen kann, musst Du einen Workflow-Befehl in einer bestimmten Syntax verwenden: `echo "::set-output name=<output name>::<value>"`. Weitere Informationen findest Du unter „[Workflow-Befehle für {% data variables.product.prodname_actions %}](/actions/reference/workflow-commands-for-github-actions#setting-an-output-parameter)“.
1. Erstelle eine neue `entrypoint.sh`-Datei im Verzeichnis `hello-world-docker-action`.
1. Füge Deiner Datei `entrypoint.sh` den folgenden Code hinzu.
**entrypoint.sh**
```shell{:copy}
#!/bin/sh -l
echo "Hello $1"
time=$(date)
echo "::set-output name=time::$time"
```
Wenn `entrypoint.sh` ohne Fehler durchläuft, wird der Status der Aktion auf `success` (erfolgreich) festgelegt. Du kannst auch explizit Exit-Codes im Code Deiner Aktion festlegen, um einen Status der Aktion anzugeben. Weitere Informationen findest Du unter "[Exit Codes für Aktionen setzen](/actions/creating-actions/setting-exit-codes-for-actions)."
1. Make your `entrypoint.sh` file executable by running the following command on your system.
```shell{:copy}
$ chmod +x entrypoint.sh
```
## Eine README erstellen
Sie können eine README-Datei erstellen, um Person dahingehend zu informieren, wie sie Ihre Aktion verwenden sollen. Eine README ist am hilfreichsten, wenn Sie vorhaben, Ihre Aktion öffentlich freizugeben. Zudem eignet sie sich dafür, Sie oder Ihr Team dahingehend zu erinnern, wie die Aktion verwendet wird.
Erstellen Sie in Ihrem Verzeichnis `hello-world-docker-action` eine `README.md`-Datei, welche die folgenden Informationen angibt:
- Eine ausführliche Beschreibung, was die Aktion bewirkt.
- Erforderliche Eingabe- und Ausgabe-Argumente.
- Optionale Eingabe- und Ausgabe-Argumente.
- Geheimnisse, die in der Aktion benutzt werden.
- Umgebungsvariablen, die in der Aktion benutzt werden.
- Ein Beispiel für die Verwendung Deiner Aktion in einem Workflow.
**README.md**
```markdown{:copy}
# Docker-Aktion „Hello world“
Diese Aktion gibt „Hello World“ oder „Hello“ + den Namen einer Person aus, die im Protokoll gegrüßt werden soll.
## Inputs
## `who-to-greet`
**Required** The name of the person to greet. Der Standardwert lautet „World“.
## Outputs
## `time`
The time we greeted you.
## Example usage
uses: actions/hello-world-docker-action@v1
with:
who-to-greet: 'Mona the Octocat'
```
## Commit, tag, and push your action to {% data variables.product.product_name %}
Committen Sie in Ihrem Terminal Ihre Dateien `action.yml`, `entrypoint.sh`, `Dockerfile` und `README.md`.
Es hat sich bewährt, auch ein Versions-Tag für Releases Deiner Aktion hinzuzufügen. Weitere Informationen zur Versionierung Deiner Aktion findest Du unter "[Informationen zu Aktionen](/actions/automating-your-workflow-with-github-actions/about-actions#using-release-management-for-actions)."
```shell{:copy}
git add action.yml entrypoint.sh Dockerfile README.md
git commit -m "My first action is ready"
git tag -a -m "My first action release" v1
git push --follow-tags
```
## Deine Aktion in einem Workflow testen
Nun sind Sie bereit, Ihre Aktion in einem Workflow zu testen. Wenn eine Aktion in einem privaten Repository vorliegt, kann die Aktion nur in Workflows im selben Repository verwendet werden. Öffentliche Aktionen können von Workflows aus jedem Repository verwendet werden.
{% data reusables.actions.enterprise-marketplace-actions %}
### Beispiel mit einer öffentlichen Aktion
The following workflow code uses the completed _hello world_ action in the public [`actions/hello-world-docker-action`](https://github.com/actions/hello-world-docker-action) repository. Kopieren Sie den folgenden Workflow-Beispielcode in eine `.github/workflows/main.yml`-Datei. Ersetzen Sie jedoch `actions/hello-world-docker-action` durch Ihren Repository- und Aktionsnamen. Darüber hinaus können Sie die Eingabe `who-to-greet` durch Ihren Namen ersetzen. {% ifversion fpt or ghec %}Public actions can be used even if they're not published to {% data variables.product.prodname_marketplace %}. For more information, see "[Publishing an action](/actions/creating-actions/publishing-actions-in-github-marketplace#publishing-an-action)." {% endif %}
{% raw %}
**.github/workflows/main.yml**
```yaml{:copy}
on: [push]
jobs:
hello_world_job:
runs-on: ubuntu-latest
name: A job to say hello
steps:
- name: Hello world action step
id: hello
uses: actions/hello-world-docker-action@v1
with:
who-to-greet: 'Mona the Octocat'
# Use the output from the `hello` step
- name: Get the output time
run: echo "The time was ${{ steps.hello.outputs.time }}"
```
{% endraw %}
### Beispiel mit einer privaten Aktion
Kopieren Sie den folgenden Workflow-Beispielcode im Repository Ihrer Aktion in eine `.github/workflows/main.yml`-Datei. Darüber hinaus können Sie die Eingabe `who-to-greet` durch Ihren Namen ersetzen. {% ifversion fpt or ghec %}This private action can't be published to {% data variables.product.prodname_marketplace %}, and can only be used in this repository.{% endif %}
{% raw %}
**.github/workflows/main.yml**
```yaml{:copy}
zu: [push]
Jobs:
hello_world_job:
läuft auf: ubuntu-latest
Name: Ein Job, um Hallo zu sagen
Schritte:
. Um die private Aktion dieses Repositorys zu verwenden,
- Sie müssen das Repository
- Name: Checkout
verwendet: Aktionen/checkout@v2
- Name: Hallo Welt-Aktionsschritt
verwendet: ./ - Verwendet eine Aktion im Root-Verzeichnis
ID: hallo
mit:
who-to-greet: 'Mona the Octocat'
. Verwenden Sie die Ausgabe aus dem 'Hallo' Schritt
- Name: Get the output time
run:{{ steps.hello.outputs.time }}echo
```
{% endraw %}
Klicke in Deinem Repository auf die Registerkarte **Actions** (Aktionen), und wähle die neueste Workflow-Ausführung aus. {% ifversion fpt or ghes > 3.0 or ghae or ghec %}Under **Jobs** or in the visualization graph, click **A job to say hello**. {% endif %}You should see "Hello Mona the Octocat" or the name you used for the `who-to-greet` input and the timestamp printed in the log.
{% ifversion fpt or ghes > 3.0 or ghae or ghec %}
![Ein Screenshot zur Verwendung Deiner Aktion in einem Workflow](/assets/images/help/repository/docker-action-workflow-run-updated.png)
{% else %}
![Ein Screenshot zur Verwendung Deiner Aktion in einem Workflow](/assets/images/help/repository/docker-action-workflow-run.png)
{% endif %}

View File

@@ -1,275 +0,0 @@
---
title: Eine JavaScript-Aktion erstellen
intro: 'In diesem Handbuch erfährst Du, wie Du mit dem Toolkit für Aktionen eine JavaScript-Aktion erstellen kannst.'
redirect_from:
- /articles/creating-a-javascript-action
- /github/automating-your-workflow-with-github-actions/creating-a-javascript-action
- /actions/automating-your-workflow-with-github-actions/creating-a-javascript-action
- /actions/building-actions/creating-a-javascript-action
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: tutorial
topics:
- Action development
- JavaScript
shortTitle: JavaScript action
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
## Einführung
In dieser Anleitung erfährst Du mehr über die grundlegenden Komponenten, die benötigt werden, um eine paketierte Docker-Container-Aktion zu erstellen und zu verwenden. Diese Anleitung fokussiert jene Komponenten, welche zum Paketieren der Aktion benötigt werden. Daher hat der Aktions-Code nur minimale Funktionalität. Die Aktion schreibt „Hello World“ in die Logs oder "Hello [who-to-greet]" wenn du einen benutzerdefinierten Namen angibst.
Diese Anleitung verwendet das Node.js Modul des {% data variables.product.prodname_actions %}-Toolkits, um die Entwicklung zu beschleunigen. Weitere Informationen findest Du im Repository [actions/toolkit](https://github.com/actions/toolkit).
Nach dem Abschluss dieses Projekts solltest Du verstehen, wie Du Deine eigene JavaScript-Aktion erstellen und sie in einem Workflow testen kannst.
{% data reusables.github-actions.pure-javascript %}
{% data reusables.github-actions.context-injection-warning %}
## Vorrausetzungen
Before you begin, you'll need to download Node.js and create a public {% data variables.product.prodname_dotcom %} repository.
1. Lade die Anwendung Node.js 12.x, welche npm enthält, herunter, und installiere sie.
https://nodejs.org/de/download/current/
1. Create a new public repository on {% data variables.product.product_location %} and call it "hello-world-javascript-action". Weitere Informationen finden Sie unter „[Neues Repository erstellen](/articles/creating-a-new-repository)“.
1. Clone Dein Repository auf Deinen Computer. Weitere Informationen findest Du unter „[Ein Repository clonen](/articles/cloning-a-repository)“.
1. Gehe in Deinem Terminal zum Verzeichnisse Deines neuen Repositorys.
```shell
cd hello-world-javascript-action
```
1. From your terminal, initialize the directory with npm to generate a `package.json` file.
```shell
npm init -y
```
## Eine Datei für die Metadaten der Aktion erstellen
Create a new file named `action.yml` in the `hello-world-javascript-action` directory with the following example code. Weitere Informationen findest Du unter „[Metadaten-Syntax für {% data variables.product.prodname_actions %}](/actions/creating-actions/metadata-syntax-for-github-actions)“.
```yaml
name: 'Hello World'
description: 'Greet someone and record the time'
inputs:
who-to-greet: # ID der Eingabe
description: 'Who to greet'
required: true
default: 'World'
outputs:
time: # ID der Ausgabe
description: 'The time we greeted you'
runs:
using: 'node12'
main: 'index.js'
```
Diese Datei definiert die Eingabe `who-to-greet` und die Ausgabe `time`. Sie gibt dem Action-Runner auch an, wie diese JavaScript-Aktion ausgeführt werden soll.
## Toolkit-Pakete für Aktionen hinzufügen
Das Toolkit für Aktionen ist eine Node.js-Paketsammlung, mit der Sie JavaScript-Aktionen schnell und konsistenter erstellen können.
Das Toolkit-Paket [`@actions/core`](https://github.com/actions/toolkit/tree/main/packages/core) enthält eine Schnittstelle für die Workflow-Befehle, Eingabe- und Ausgabevariablen, Exit-Status und Debugging-Meldungen.
Das Toolkit enthält zudem das Paket [`@actions/github`](https://github.com/actions/toolkit/tree/main/packages/github), das einen authentifizierten Octokit REST-Client und Zugriff auf GitHub Aktions-Kontexte bietet.
Das Toolkit bietet mehr als die Pakete `core` und `github`. Weitere Informationen findest Du im Repository [actions/toolkit](https://github.com/actions/toolkit).
Installiere an Deinem Terminal die Pakete `core` und `github` des Toolkits für Aktionen.
```shell
npm install @actions/core
npm install @actions/github
```
Nun sollte das Verzeichnis `node_modules` mit den soeben von Dir installierten Modulen und die Datei `package-lock.json` mit den installierten Modulabhängigkeiten sowie die Version des jeweils installierten Moduls angezeigt werden.
## Aktions-Code schreiben
Diese Aktion verwendet das Toolkit, um die in der Metadatendatei der Aktion erforderliche Eingabevariable `who-to-greet` abzurufen, und gibt „Hello [who-to-greet]“ im Protokoll in einer Debugging-Meldung aus. Als Nächstes ruft das Skript die aktuelle Zeit ab und legt sie als eine Ausgabevariable fest, die von später in einem Auftrag ausgeführten Aktionen verwendet werden kann.
GitHub Actions stellt Kontextinformationen zum Webhook-Ereignis, zu den Git-Refs, zum Workflow, zur Aktion und zur Person bereit, die den Workflow ausgelöst hat. Um auf die Kontextinformationen zuzugreifen, kannst Du das Paket `github` verwenden. The action you'll write will print the webhook event payload to the log.
Füge eine neue Datei mit der Bezeichnung `index.js` mit dem folgenden Code hinzu.
{% raw %}
```javascript
const core = require('@actions/core');
const github = require('@actions/github');
try {
// `who-to-greet` Eingabedaten, in der Metadaten-Datei der Aktion definiert
const nameToGreet = core.getInput('who-to-greet');
console.log(`Hello ${nameToGreet}!`);
const time = (new Date()).toTimeString();
core.setOutput("time", time);
// Hole die JSON Webhook Nutzlast fuer das Ereignis, das den Workflow angestossen hat
const payload = JSON.stringify(github.context.payload, undefined, 2)
console.log(`The event payload: ${payload}`);
} catch (error) {
core.setFailed(error.message);
}
```
{% endraw %}
Wenn im o. g. `index.js`-Beispiel ein Fehler ausgegeben wird, nutzt `core.setFailed(error.message);` das Aktions-Toolkit-Paket [`@actions/core`](https://github.com/actions/toolkit/tree/main/packages/core), um eine Meldung zu protokollieren und einen Fehler-Exit-Code festzulegen. Weitere Informationen findest Du unter "[Exit Codes für Aktionen setzen](/actions/creating-actions/setting-exit-codes-for-actions)."
## Eine README erstellen
Sie können eine README-Datei erstellen, um Person dahingehend zu informieren, wie sie Ihre Aktion verwenden sollen. Eine README ist am hilfreichsten, wenn Sie vorhaben, Ihre Aktion öffentlich freizugeben. Zudem eignet sie sich dafür, Sie oder Ihr Team dahingehend zu erinnern, wie die Aktion verwendet wird.
Erstelle in Deinem Verzeichnis `hello-world-javascript-action` eine Datei `README.md` mit folgenden Informationen:
- Eine ausführliche Beschreibung, was die Aktion bewirkt.
- Erforderliche Eingabe- und Ausgabe-Argumente.
- Optionale Eingabe- und Ausgabe-Argumente.
- Geheimnisse, die in der Aktion benutzt werden.
- Umgebungsvariablen, die in der Aktion benutzt werden.
- Ein Beispiel für die Verwendung Deiner Aktion in einem Workflow.
```markdown
# JavaScript-Aktion „Hello world“
Diese Aktion gibt „Hello World“ oder „Hello“ + den Namen einer Person aus, die im Protokoll gegrüßt werden soll.
## Inputs
## `who-to-greet`
**Required** The name of the person to greet. Der Standardwert lautet „World“.
## Outputs
## `time`
The time we greeted you.
Beispielverwendung
verwendet: actions/hello-world-javascript-action@v1.1
mit:
who-to-greet: 'Mona the Octocat'
```
## Committe, tagge und pushe Deine Aktion auf GitHub
{% data variables.product.product_name %} lädt jede Aktion, die in einem Workflow während der Laufzeit ausgeführt wird, herunter und führt sie als komplettes Codepaket aus, bevor Du Workflow-Befehle wie `run` zur Interaktion mit der Runner-Maschine verwenden kannst. Folglich musst Du alle zum Ausführen des JavaScript-Codes erforderlichen Paketabhängigkeiten einschließen. Sie müssen die Pakete `core` und `github` in das Repository Ihrer Aktion einchecken.
Committen Sie in Ihrem Terminal Ihre Dateien `action.yml`, `index.js`, `node_modules`, `package.json`, `package-lock.json` und `README.md`. Falls Sie eine `.gitignore`-Datei hinzugefügt haben, die `node_modules` auflistet, müssen Sie diese Zeile entfernen, um das Verzeichnis `node_modules` zu committen.
Es hat sich bewährt, auch ein Versions-Tag für Releases Deiner Aktion hinzuzufügen. Weitere Informationen zur Versionierung Deiner Aktion findest Du unter "[Informationen zu Aktionen](/actions/automating-your-workflow-with-github-actions/about-actions#using-release-management-for-actions)."
```shell
git add action.yml index.js node_modules/* package.json package-lock.json README.md
git commit -m "My first action is ready"
git tag -a -m "My first action release" v1.1
git push --follow-tags
```
Checking in your `node_modules` directory can cause problems. As an alternative, you can use a tool called [`@vercel/ncc`](https://github.com/vercel/ncc) to compile your code and modules into one file used for distribution.
1. Install `vercel/ncc` by running this command in your terminal. `npm i -g @vercel/ncc`
1. Kompiliere die Datei `index.js`. `ncc build index.js --license licenses.txt`
Es wird die neue Datei `dist/index.js` mit Deinem Code und den kompilierten Modulen angezeigt. You will also see an accompanying `dist/licenses.txt` file containing all the licenses of the `node_modules` you are using.
1. Ändere das Schlüsselwort `main` in der Datei `action.yml` so, dass die neue Datei `dist/index.js` verwendet wird. `main: 'dist/index.js'`
1. Falls Du Dein Verzeichnis `node_modules` bereits eingecheckt hast, entferne es. `rm -rf node_modules/*`
1. Committe in Deinem Terminal die Updates für Deine Dateien `action.yml`, `dist/index.js` und `node_modules`.
```shell
git add action.yml dist/index.js node_modules/*
git commit -m "Use vercel/ncc"
git tag -a -m "My first action release" v1.1
git push --follow-tags
```
## Deine Aktion in einem Workflow testen
Nun sind Sie bereit, Ihre Aktion in einem Workflow zu testen. Wenn eine Aktion in einem privaten Repository vorliegt, kann die Aktion nur in Workflows im selben Repository verwendet werden. Öffentliche Aktionen können von Workflows aus jedem Repository verwendet werden.
{% data reusables.actions.enterprise-marketplace-actions %}
### Beispiel mit einer öffentlichen Aktion
This example demonstrates how your new public action can be run from within an external repository.
Copy the following YAML into a new file at `.github/workflows/main.yml`, and update the `uses: octocat/hello-world-javascript-action@v1.1` line with your username and the name of the public repository you created above. Darüber hinaus können Sie die Eingabe `who-to-greet` durch Ihren Namen ersetzen.
{% raw %}
```yaml
on: [push]
jobs:
hello_world_job:
runs-on: ubuntu-latest
name: A job to say hello
steps:
- name: Hello world action step
id: hello
uses: octocat/hello-world-javascript-action@v1.1
with:
who-to-greet: 'Mona the Octocat'
# Use the output from the `hello` step
- name: Get the output time
run: echo "The time was ${{ steps.hello.outputs.time }}"
```
{% endraw %}
When this workflow is triggered, the runner will download the `hello-world-javascript-action` action from your public repository and then execute it.
### Beispiel mit einer privaten Aktion
Kopieren Sie den Workflow-Code im Repository Ihrer Aktion in eine `.github/workflows/main.yml`-Datei. Darüber hinaus können Sie die Eingabe `who-to-greet` durch Ihren Namen ersetzen.
{% raw %}
**.github/workflows/main.yml**
```yaml
zu: [push]
Jobs:
hello_world_job:
läuft auf: ubuntu-latest
Name: Ein Job, um Hallo zu sagen
Schritte:
. Um die private Aktion dieses Repositorys zu verwenden,
- Sie müssen das Repository
- Name: Checkout
verwendet: Aktionen/checkout@v2
- Name: Hallo Welt-Aktionsschritt
verwendet: ./ - Verwendet eine Aktion im Root-Verzeichnis
ID: hallo
mit:
who-to-greet: 'Mona the Octocat'
. Verwenden Sie die Ausgabe aus dem 'Hallo' Schritt
- Name: Get the output time
run:{{ steps.hello.outputs.time }}echo
```
{% endraw %}
Klicke in Deinem Repository auf die Registerkarte **Actions** (Aktionen), und wähle die neueste Workflow-Ausführung aus. {% ifversion fpt or ghes > 3.0 or ghae or ghec %}Under **Jobs** or in the visualization graph, click **A job to say hello**. {% endif %}You should see "Hello Mona the Octocat" or the name you used for the `who-to-greet` input and the timestamp printed in the log.
{% ifversion fpt or ghes > 3.0 or ghae or ghec %}
![Ein Screenshot zur Verwendung Deiner Aktion in einem Workflow](/assets/images/help/repository/javascript-action-workflow-run-updated-2.png)
{% elsif ghes %}
![Ein Screenshot zur Verwendung Deiner Aktion in einem Workflow](/assets/images/help/repository/javascript-action-workflow-run-updated.png)
{% else %}
![Ein Screenshot zur Verwendung Deiner Aktion in einem Workflow](/assets/images/help/repository/javascript-action-workflow-run.png)
{% endif %}

View File

@@ -1,72 +0,0 @@
---
title: Developing a third party CLI action
shortTitle: CLI setup action
intro: 'Learn how to develop an action to set up a CLI on {% data variables.product.prodname_actions %} runners.'
redirect_from: []
versions:
fpt: '*'
ghec: '*'
type: tutorial
topics:
- Actions
---
## Einführung
You can write an action to provide a way for users to access your servers via a configured CLI environment on {% data variables.product.prodname_actions %} runners.
Your action should:
- Make it simple for users to specify the version of the CLI to install
- Support multiple operating systems
- Run in an efficient fashion to minimize run-time and associated costs
- Work across {% data variables.product.product_name %}-hosted and self-hosted runners
- Leverage community tooling when possible
This article will demonstrate how to write an action that retrieves a specific version of your CLI, installs it, adds it to the path, and (optionally) caches it. This type of action (an action that sets up a tool) is often named `setup-$TOOL`.
## Vorrausetzungen
You should have an understanding of how to write a custom action. For more information, see "[About custom actions](/actions/creating-actions/about-custom-actions)". For a more detailed guide on how to write a custom action, see "[Creating a JavaScript action](/actions/creating-actions/creating-a-javascript-action)."
## Beispiel
The following script demonstrates how you can get a user-specified version as input, download and extract the specific version of your CLI, then add the CLI to the path.
{% data variables.product.prodname_dotcom %} provides [`actions/toolkit`](https://github.com/actions/toolkit), which is a set of packages that helps you create actions. This example uses the [`actions/core`](https://github.com/actions/toolkit/tree/main/packages/core) and [`actions/tool-cache`](https://github.com/actions/toolkit/tree/main/packages/tool-cache) packages.
{% raw %}
```javascript{:copy}
const core = require('@actions/core');
const tc = require('@actions/tool-cache');
async function setup() {
// Get version of tool to be installed
const version = core.getInput('version');
// Download the specific version of the tool, e.g. as a tarball
const pathToTarball = await tc.downloadTool(getDownloadURL());
// Extract the tarball onto the runner
const pathToCLI = await tc.extractTar(pathToTarball);
// Expose the tool by adding it to the PATH
core.addPath(pathToCLI)
}
module.exports = setup
```
{% endraw %}
To use this script, replace `getDownloadURL` with a function that downloads your CLI. You will also need to create an actions metadata file (`action.yml`) that accepts a `version` input and that runs this script. For full details about how to create an action, see "[Creating a JavaScript action](/actions/creating-actions/creating-a-javascript-action)."
For a full example of how to set up this action, see [example-setup-gh](https://github.com/github-developer/example-setup-gh).
## Weiterführende Informationen
This pattern is employed in several actions. For more examples, see:
* [`ruby/setup-ruby`](https://github.com/ruby/setup-ruby)
* [`google-github-actions/setup-gcloud`](https://github.com/google-github-actions/setup-gcloud)
* [`hashicorp/setup-terraform`](https://github.com/hashicorp/setup-terraform)

View File

@@ -1,111 +0,0 @@
---
title: Dockerfile Unterstützung für GitHub Aktionen
shortTitle: Dockerfile support
intro: 'Beim Erstellen eines Dockerfiles für eine Dockercontainer-Aktion sollten Sie sich darüber im Klaren sein, wie einige Docker-Anweisungen mit GitHub-Aktionen und der Metadaten-Datei einer Aktion interagieren.'
redirect_from:
- /actions/building-actions/dockerfile-support-for-github-actions
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: reference
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
## Informationen zu Dockerfile-Anweisungen
Ein `Dockerfile` enthält Anweisungen und Argumente, die den Inhalt und das Startverhalten eines Docker-Containers definieren. Weitere Informationen zu den Anweisungen findest Du unter "[Dockerfile-Referenz](https://docs.docker.com/engine/reference/builder/)" in der Docker-Dokumentation.
## Dockerfile Anweisungen und Overrides (Überschreibungen)
Einige Docker-Anweisungen interagieren mit GitHub-Aktionen, und die Metadaten-Datei einer Aktion kann einige Docker-Anweisungen überschreiben. Vergewissere Dich, dass Dir klar ist, wie Dein Dockerfile mit {% data variables.product.prodname_actions %} interagiert, um unerwartetes Verhalten zu verhindern.
### USER
Docker-Aktionen müssen vom Standard-Benutzer (root) des Dockers ausgeführt werden. Verwende nicht die `USER` Anweisung in Deinem `Dockerfile`, weil Du nicht auf den `GITHUB_WORKSPACE` zugreifen kannst. Weitere Informationen findest Du unter "[Umgebungsvariablen](/actions/configuring-and-managing-workflows/using-environment-variables)" und [USER-Referenz](https://docs.docker.com/engine/reference/builder/#user) in der Docker-Dokumentation.
### FROM
Die erste Anweisung im `Dockerfile` muss `FROM` sein. Sie wählt das Docker-Basisabbild aus. Weitere Informationen findest Du unter [FROM-Referenz](https://docs.docker.com/engine/reference/builder/#from) in der Docker-Dokumentation.
Dies sind einige bewährte Methoden, das Argument `FROM` zu setzen:
- Es wird empfohlen, offizielle Docker-Images (Abbilder) zu verwenden. Zum Beispiel `python` oder `ruby`.
- Verwende ein Versions-Tag, falls vorhanden, vorzugsweise mit einer Hauptversion. Verwende beispielsweise `node:10` anstelle von `node:latest`.
- Es wird empfohlen, Docker-Images basierend auf dem Betriebssystem [Debian](https://www.debian.org/) zu verwenden.
### WORKDIR
{% data variables.product.product_name %} setzt den Pfad zum Arbeitsverzeichnis in der `GITHUB_WORKSPACE` Umgebungsvariable. Es wird empfohlen, die `WORKDIR` Anweisung in Ihrem `Dockerfile` zu vermeiden. Bevor die Aktion ausgeführt wird, mountet {% data variables.product.product_name %} das Verzeichnis `GITHUB_WORKSPACE` auf was auch immer sich an dieser Stelle im Docker-Image befindet, und setzt `GITHUB_WORKSPACE` als Arbeitsverzeichnis. Weitere Informationen findest Du unter "[Umgebungsvariablen verwenden](/actions/configuring-and-managing-workflows/using-environment-variables)" und [WORKDIR-Referenz](https://docs.docker.com/engine/reference/builder/#workdir) in der Docker-Dokumentation.
### ENTRYPOINT
Wenn Du `Einstiegspunkt` in der Metadaten-Datei einer Aktion definierst, wird der `ENTRYPOINT` im `Dockerfile` überschrieben. Weitere Informationen findest Du unter „[Metadaten-Syntax für {% data variables.product.prodname_actions %}](/actions/creating-actions/metadata-syntax-for-github-actions/#runsentrypoint)“.
Für die Docker-Anweisung `ENTRYPOINT` gibt es sowohl eine _shell_-Form als auch eine _exec_-Form. Die Docker-Dokumentation für `ENTRYPOINT` empfiehlt die _exec_-Form der `ENTRYPOINT`-Anweisung. Weitere Informationen über _exec_- und _shell_-Form findest Du unter [ENTRYPOINT-Referenz](https://docs.docker.com/engine/reference/builder/#entrypoint) in der Docker-Dokumentation.
Wenn Du Deinen Container so konfigurierst, dass er die _exec_-Form der Anweisung `ENTRYPOINT` verwendet, können die in der Metadaten-Datei der Aktion konfigurierten `args` (Argumente) nicht in einer Kommando-Shell genutzt werden. Wenn die `Args` der Aktion eine Umgebungsvariable enthalten, wird die Variable nicht ersetzt. Wenn Du zum Beispiel das folgende _exec_-Format verwendest, wird nicht der in `$GITHUB_SHA` gespeicherte Wert ausgegeben, sondern stattdessen „`$GITHUB_SHA`“.
```dockerfile
ENTRYPOINT ["echo $GITHUB_SHA"]
```
Wenn Du Variablensubstitution willst, verwende entweder die _Shell_-Form oder führe direkt eine Shell aus. Zum Beispiel kannst Du mit dem folgenden _exec_-Format eine Shell ausführen, um den Wert auszugeben, der in der Umgebungsvariable `GITHUB_SHA` gespeichert ist.
```dockerfile
ENTRYPOINT ["sh", "-c", "echo $GITHUB_SHA"]
```
Um `args` aus der Metadaten-Datei der Aktion an einen Docker Container zu übergeben, der die _exec_-Form im `ENTRYPOINT` verwendet, empfehlen wir, ein Shell-Skript namens `entrypoint.sh` zu erstellen und dieses von der `ENTRYPOINT`-Anweisung aus anrufen:
#### Beispiel *Dockerfile*
```dockerfile
# Container image that runs your code
FROM debian:9.5-slim
# Copies your code file from your action repository to the filesystem path `/` of the container
COPY entrypoint.sh /entrypoint.sh
# Executes `entrypoint.sh` when the Docker container starts up
ENTRYPOINT ["/entrypoint.sh"]
```
#### Beispiel für die Datei *entrypoint.sh*
Mit dem obigen Dockerfile-Beispiel sendet {% data variables.product.product_name %} die Metadaten-Datei der Aktion konfigurierten `args` als Argumente an `entrypoint.sh`. Füge `#!/bin/sh` [shebang](https://en.wikipedia.org/wiki/Shebang_(Unix)) oben in die Datei `entrypoint.sh` ein, um explizit die [POSIX](https://en.wikipedia.org/wiki/POSIX)-konforme Shell des Systems zu verwenden.
``` sh
#!/bin/sh
# `$*` expands the `args` supplied in an `array` individually
# or splits `args` in a string separated by whitespace.
sh -c "echo $*"
```
Dein Code muss ausführbar sein. Stelle sicher, dass die Datei `entrypoint.sh` die Berechtigunge `execute` hat, bevor Du sie in einem Workflow verwendest. Du kannst die Berechtigung von Deinem Terminal aus mit diesem Befehl ändern:
``` sh
chmod +x entrypoint.sh
```
Wenn ein `ENTRYPOINT`-Shell-Skript nicht ausführbar ist, erhältst Du einen Fehler, der ungefähr so aussieht:
``` sh
Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"/entrypoint.sh\": permission denied": unknown
```
### CMD
Wenn Du in der Metadaten-Datei der Aktion `args` definierst, dann überschreibt `args` die Anweisung `CMD`, welche im `Dockerfile` angegeben wurde. Weitere Informationen findest Du unter „[Metadaten-Syntax für {% data variables.product.prodname_actions %}](/actions/creating-actions/metadata-syntax-for-github-actions#runsargs)“.
Falls Du `CMD` in Deinem `Dockerfile` verwendest, solltest Du Dich an diese Richtlinien halten:
{% data reusables.github-actions.dockerfile-guidelines %}
## Unterstützte Linux-Funktionen
{% data variables.product.prodname_actions %} unterstützt die standardmäßigen Linux-Funktionen, die auch Docker unterstützt. Funktionen können weder hinzugefügt noch entfernt werden. Weitere Informationen über die standardmäßigen Linux-Funktionen, die Docker unterstützt, findest Du unter "[Laufzeit-Privilegien und Linux-Funktionen](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)" in der Docker-Dokumentation. Weitere Informationen zu Linux-Funktionen findest Du unter "[Überblick über die Linux-Funktionen](http://man7.org/linux/man-pages/man7/capabilities.7.html)" in den Linux-Man-Pages.

View File

@@ -1,30 +0,0 @@
---
title: Erstellen von Aktionen
intro: 'Du kannst deine eigenen Aktionen erstellen sowie Aktionen verwenden und anpassen, die von der {% data variables.product.prodname_dotcom %}-Community bereitgestellt werden, oder Deine eigenen Aktionen der Communitz bereitstellen.'
redirect_from:
- /articles/building-actions
- /github/automating-your-workflow-with-github-actions/building-actions
- /actions/automating-your-workflow-with-github-actions/building-actions
- /actions/building-actions
- /articles/creating-a-github-action/
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
children:
- /about-custom-actions
- /creating-a-docker-container-action
- /creating-a-javascript-action
- /creating-a-composite-action
- /metadata-syntax-for-github-actions
- /dockerfile-support-for-github-actions
- /setting-exit-codes-for-actions
- /publishing-actions-in-github-marketplace
- /releasing-and-maintaining-actions
- /developing-a-third-party-cli-action
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}

View File

@@ -1,834 +0,0 @@
---
title: Metadaten-Syntax für GitHub-Aktionen
shortTitle: Metadaten-Syntax
intro: 'Du kannst Aktionen erstellen, um Aufgaben in Ihrem Repository zu erledigen. Für Aktionen ist eine Metadaten-Datei erforderlich, welche die YAML-Syntax verwendet.'
redirect_from:
- /articles/metadata-syntax-for-github-actions
- /github/automating-your-workflow-with-github-actions/metadata-syntax-for-github-actions
- /actions/automating-your-workflow-with-github-actions/metadata-syntax-for-github-actions
- /actions/building-actions/metadata-syntax-for-github-actions
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: reference
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
## Informationen zur YAML-Syntax für {% data variables.product.prodname_actions %}
Für Docker- und JavaScript-Aktionen ist eine Metadatendatei erforderlich. Der Dateiname für die Metadaten muss entweder `action.yml` oder `action.yaml` sein. Die Daten in der Metadaten-Datei definieren die Eingaben, Ausgaben und der Haupteinstiegspunkt für die Aktion.
Aktionsmetadatendateien verwenden die YAML-Syntax. Wenn YAML für Dich Neuland ist, lies den Artikel „[YAML in fünf Minuten lernen](https://www.codeproject.com/Articles/1214409/Learn-YAML-in-five-minutes)“.
## `name`
**Required** (Erforderlich): Der Name Deiner Aktion. {% data variables.product.prodname_dotcom %} zeigt den `name` auf der Registerkarte **Actions** an, damit Du die Aktionen in jedem Auftrag visuell identifizieren kannst.
## `Autor`
**Optional** The name of the action's author.
## `Beschreibung`
**Erforderlich** Eine kurze Beschreibung der Aktion.
## `inputs`
**Optional** Input parameters allow you to specify data that the action expects to use during runtime. {% data variables.product.prodname_dotcom %} speichert Eingabeparameter als Umgebungsvariablen. Eingabe-IDs in Großbuchstaben werden während der Laufzeit in Kleinbuchstaben umgewandelt. Du solltest Eingabe-IDs in Kleinbuchstaben verwenden.
### Beispiel
In diesem Beispiel werden zwei Eingaben konfiguriert: „numOctocats“ und „octocatEyeColor“. Die Eingabe „numOctocats“ ist nicht erforderlich und hat standardmäßig den Wert 1. Die Eingabe „octocatEyeColor“ ist erforderlich und hat keinen Standardwert. Workflow-Dateien, die diese Aktion nutzen, müssen das Schlüsselwort `with` verwenden, um für „octocatEyeColor“ einen Eingabewert festzulegen. Weitere Informationen zu `with`-Syntax finden Sie unter „[Workflow-Syntax für {% data variables.product.prodname_actions %}](/articles/workflow-syntax-for-github-actions/#jobsjob_idstepswith)“.
```yaml
inputs:
numOctocats:
description: 'Number of Octocats'
required: false
default: '1'
octocatEyeColor:
description: 'Eye color of the Octocats'
required: true
```
When you specify an input in a workflow file or use a default input value, {% data variables.product.prodname_dotcom %} creates an environment variable for the input with the name `INPUT_<VARIABLE_NAME>`. Der Name der aus dem Eingabenamen erstellten Umgebungsvariablen wird in Großbuchstaben umgewandelt und Leerzeichen werden durch das Zeichen `_` ersetzt.
If the action is written using a [composite](/actions/creating-actions/creating-a-composite-action), then it will not automatically get `INPUT_<VARIABLE_NAME>`. If the conversion doesn't occur, you can change these inputs manually.
To access the environment variable in a Docker container action, you must pass the input using the `args` keyword in the action metadata file. For more information about the action metadata file for Docker container actions, see "[Creating a Docker container action](/articles/creating-a-docker-container-action#creating-an-action-metadata-file)."
For example, if a workflow defined the `numOctocats` and `octocatEyeColor` inputs, the action code could read the values of the inputs using the `INPUT_NUMOCTOCATS` and `INPUT_OCTOCATEYECOLOR` environment variables.
### `inputs.<input_id>`
**Erforderlich** Ein Kennzeichner, der die Eingabe identifiziert, als `string`. The value of `<input_id>` is a map of the input's metadata. Die `<input_id>` muss im Objekt `inputs` als ein eindeutiger Kennzeichner vorhanden sein. Die `<input_id>` muss mit einem Buchstaben oder `_` beginnen und darf nur alphanumerische Zeichen, `-` oder `_` enthalten.
### `inputs.<input_id>.description`
**Erforderlich** Eine Beschreibung des Eingabeparameters als `String`.
### `inputs.<input_id>.required`
**Erforderlich**: Ein `boolescher` Wert, um anzugeben, ob für die Aktion der Eingabeparameter erforderlich ist. Legen Sie den Wert `true` fest, wenn der Parameter erforderlich ist.
### `inputs.<input_id>.default`
**Optional** A `string` representing the default value. Der Standardwert wird verwendet, wenn ein Eingabeparameter in einer Workflow-Datei nicht angegeben ist.
### `inputs.<input_id>.deprecationMessage`
**Optional** If the input parameter is used, this `string` is logged as a warning message. You can use this warning to notify users that the input is deprecated and mention any alternatives.
## `outputs`
**Optional**: Ausgabeparameter erlauben Dir, Daten zu deklarieren, die eine Aktion setzt. Aktionen, die in einem Workflow später ausgeführt werden, können die Ausgabedaten der zuvor ausgeführten Aktionen verwenden. Wenn beispielsweise eine Aktion vorliegt, die zwei Eingaben addiert hat (x + y = z), kann die Aktion die Summe (z) für andere Aktionen ausgeben, damit sie dort als Eingabe verwendet wird.
Auch wenn Du in der Metadaten-Datei Deiner Aktion keine Ausgabe deklarierst, kannst Du dennoch Ausgaben festlegen und in einem Workflow verwenden. Weitere Informationen zum Festlegen von Ausgaben in einer Aktion findest Du unter "[Workflow-Befehle für {% data variables.product.prodname_actions %}](/actions/reference/workflow-commands-for-github-actions/#setting-an-output-parameter)."
### Beispiel
```yaml
outputs:
sum: # ID der Ausgabe
description: 'Die Summe der Eingaben'
```
### `outputs.<output_id>`
**Erforderlich** Ein Kennzeichner, der die Ausgabe identifiziert, als `String`. Der Wert von `<output_id>` ist eine Übersicht zu den Metadaten der Ausgabe. Die `<output_id>` muss im Objekt `outputs` als ein eindeutiger Kennzeichner vorhanden sein. Die `<output_id>` muss mit einem Buchstaben oder `_` beginnen und darf nur alphanumerische Zeichen, `-` oder `_` enthalten.
### `outputs.<output_id>.description`
**Erforderlich** Eine Beschreibung des Ausgabeparameters als `String`.
## `outputs` for composite actions
**Optional** `outputs` use the same parameters as `outputs.<output_id>` and `outputs.<output_id>.description` (see "[`outputs` for {% data variables.product.prodname_actions %}](/actions/creating-actions/metadata-syntax-for-github-actions#outputs)"), but also includes the `value` token.
### Beispiel
{% raw %}
```yaml
outputs:
random-number:
description: "Random number"
value: ${{ steps.random-number-generator.outputs.random-id }}
runs:
using: "composite"
steps:
- id: random-number-generator
run: echo "::set-output name=random-id::$(echo $RANDOM)"
shell: bash
```
{% endraw %}
### `outputs.<output_id>.value`
**Required** The value that the output parameter will be mapped to. You can set this to a `string` or an expression with context. For example, you can use the `steps` context to set the `value` of an output to the output value of a step.
For more information on how to use context syntax, see "[Contexts](/actions/learn-github-actions/contexts)."
## `runs` for JavaScript actions
**Erforderlich** Konfiguriert den Pfad zum Code der Aktion und zu der Anwendung, die den Code ausführen soll.
### Beispiel für die Verwendung von Node.js
```yaml
runs:
using: 'node12'
main: 'main.js'
```
### `runs.using`
**Erforderlich** Die Anwendung, welche den in [`main`](#runsmain) angegebenen Code ausführen soll.
### `runs.main`
**Erforderlich** Die Datei, die den Code Deiner Aktion enthält. Die in [`using`](#runsusing) angegebene Anwendung führt diese Datei aus.
### `pre`
**Optional** Erlaubt es Dir, ein Skript am Anfang eines Jobs auszuführen, bevor die `main:`-Aktion startet. Du kannst `pre:` zum Beispiel verwenden, um mit einem Setup-Skript die Voraussetzungen zu schaffen. Die mit der Syntax [`using`](#runsusing) angegebene Anwendung wird diese Datei ausführen. Die `pre:`-Aktion wird normalerweise immer ausgeführt, aber Du kannst dies mit [`pre-if`](#pre-if) ändern.
In diesem Beispiel führt die `pre:`-Aktion ein Skript namens `setup.js` aus:
```yaml
runs:
using: 'node12'
pre: 'setup.js'
main: 'index.js'
post: 'cleanup.js'
```
### `pre-if`
**Optional** Erlaubt Dir, Bedingungen für die Ausführung der `pre:`-Aktion festzulegen. Die `pre:`-Aktion läuft nur, wenn die Bedingungen in `pre-if` erfüllt sind. Wenn `pre-if` nicht definiert ist, gilt `always()` als Standardwert. Beachte, dass der `step`-Kontext nicht verfügbar ist, da noch keine Schritte ausgeführt wurden.
In diesem Beispiel läuft `cleanup.js` nur auf Linux-basierten Runnern:
```yaml
pre: 'cleanup.js'
pre-if: runner.os == 'linux'
```
### `Beitrag`
**Optional** Erlaubt es Dir, ein Skript am Ende eines Jobs auszuführen, sobald die `main:`-Aktion abgeschlossen ist. Zum Beispiel kannst Du `post:` verwenden, um bestimmte Prozesse zu beenden oder unnötige Dateien zu entfernen. Die mit der Syntax [`using`](#runsusing) angegebene Anwendung wird diese Datei ausführen.
In diesem Beispiel führt die `post:`-Aktion ein Skript namens `cleanup.js` aus:
```yaml
runs:
using: 'node12'
main: 'index.js'
post: 'cleanup.js'
```
Die `post:`-Aktion wird normalerweise immer ausgeführt, aber Du kannst dies mit `post-if` ändern.
### `post-if`
**Optional** Erlaubt Dir, Bedingungen für die Ausführung der `post:`-Aktion festzulegen. Die `post:`-Aktion läuft nur, wenn die Bedingungen in `post-if` erfüllt sind. Wenn `post-if` nicht definiert ist, gilt `always()` als Standardwert.
In diesem Beispiel läuft `cleanup.js` nur auf Linux-basierten Runnern:
```yaml
post: 'cleanup.js'
post-if: runner.os == 'linux'
```
## `runs` for composite actions
**Required** Configures the path to the composite action, and the application used to execute the code.
### `runs.using`
**Required** To use a composite action, set this to `"composite"`.
### `runs.steps`
{% ifversion fpt or ghes > 3.2 or ghae-issue-4853 or ghec %}
**Required** The steps that you plan to run in this action. These can be either `run` steps or `uses` steps.
{% else %}
**Required** The steps that you plan to run in this action.
{% endif %}
#### `runs.steps[*].run`
{% ifversion fpt or ghes > 3.2 or ghae-issue-4853 or ghec %}
**Optional** The command you want to run. This can be inline or a script in your action repository:
{% else %}
**Required** The command you want to run. This can be inline or a script in your action repository:
{% endif %}
{% raw %}
```yaml
runs:
using: "composite"
steps:
- run: ${{ github.action_path }}/test/script.sh
shell: bash
```
{% endraw %}
Alternatively, you can use `$GITHUB_ACTION_PATH`:
```yaml
runs:
using: "composite"
steps:
- run: $GITHUB_ACTION_PATH/script.sh
shell: bash
```
For more information, see "[`github context`](/actions/reference/context-and-expression-syntax-for-github-actions#github-context)".
#### `runs.steps[*].shell`
{% ifversion fpt or ghes > 3.2 or ghae-issue-4853 or ghec %}
**Optional** The shell where you want to run the command. You can use any of the shells listed [here](/actions/reference/workflow-syntax-for-github-actions#using-a-specific-shell). Required if `run` is set.
{% else %}
**Required** The shell where you want to run the command. You can use any of the shells listed [here](/actions/reference/workflow-syntax-for-github-actions#using-a-specific-shell). Required if `run` is set.
{% endif %}
#### `runs.steps[*].name`
**Optional** The name of the composite step.
#### `runs.steps[*].id`
**Optional** A unique identifier for the step. Anhand der `id` können Sie in Kontexten auf den Schritt verweisen. Weitere Informationen finden Sie unter „[Kontexte](/actions/learn-github-actions/contexts)“.
#### `runs.steps[*].env`
**Optional** Sets a `map` of environment variables for only that step. If you want to modify the environment variable stored in the workflow, use `echo "{name}={value}" >> $GITHUB_ENV` in a composite step.
#### `runs.steps[*].working-directory`
**Optional** Specifies the working directory where the command is run.
{% ifversion fpt or ghes > 3.2 or ghae-issue-4853 or ghec %}
#### `runs.steps[*].uses`
**Optional** Selects an action to run as part of a step in your job. Eine Aktion ist eine wiederverwendbare Code-Einheit. Du kannst eine Aktion verwenden, die im selben Repository wie der Workflow, in einem öffentlichen Repository oder in einem [veröffentlichten Docker-Container-Image](https://hub.docker.com/) definiert ist.
Es wird dringend empfohlen, die verwendete Version der Aktion zu nennen (Git-Ref, SHA oder Docker-Tag-Nummer angeben). Wenn Du keine Version angibst, könnten damit die Workflows gestört werden, oder es wird ein unerwartetes Verhalten hervorgerufen, wenn der Inhaber der Aktion eine Aktualisierung veröffentlicht.
- Am besten in Hinblick auf Stabilität und Sicherheit ist es, die Commit-SHA einer freigegebenen Version einer Aktion zu verwenden.
- Wenn Du Dich auf die Hauptversion der Aktion beziehst, kannst Du kritische Fehlerbehebungen und Sicherheits-Patches erhalten und gleichzeitig die Kompatibilität wahren. Außerdem ist damit sichergestellt, dass der Workflow weiterhin problemlos arbeiteten sollte.
- Using the default branch of an action may be convenient, but if someone releases a new major version with a breaking change, your workflow could break.
Some actions require inputs that you must set using the [`with`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepswith) keyword. Die erforderlichen Eingaben findest Du in der README-Datei der Aktion.
```yaml
runs:
using: "composite"
steps:
# Reference a specific commit
- uses: actions/checkout@a81bbbf8298c0fa03ea29cdc473d45769f953675
# Reference the major version of a release
- uses: actions/checkout@v2
# Reference a specific version
- uses: actions/checkout@v2.2.0
# Reference a branch
- uses: actions/checkout@main
# References a subdirectory in a public GitHub repository at a specific branch, ref, or SHA
- uses: actions/aws/ec2@main
# References a local action
- uses: ./.github/actions/my-action
# References a docker public registry action
- uses: docker://gcr.io/cloud-builders/gradle
# Reference a docker image published on docker hub
- uses: docker://alpine:3.8
```
#### `runs.steps[*].with`
**Optional** A `map` of the input parameters defined by the action. Jeder Eingabeparameter ist ein Schlüssel-Wert-Paar. Eingabeparameter werden als Umgebungsvariablen festgelegt. The variable is prefixed with INPUT_ and converted to upper case.
```yaml
runs:
using: "composite"
steps:
- name: My first step
uses: actions/hello_world@main
with:
first_name: Mona
middle_name: The
last_name: Octocat
```
{% endif %}
## `runs` for Docker actions
**Erforderlich** Konfiguriert das Image, welches für die Docker-Aktion verwendet wird.
### Beispiel für die Nutzung eines Dockerfiles in Deinem Repository
```yaml
runs:
using: 'docker'
image: 'Dockerfile'
```
### Beispiel zur Nutzung des öffentlichen Docker-Registry-Containers
```yaml
runs:
using: 'docker'
image: 'docker://debian:stretch-slim'
```
### `runs.using`
**Erforderlich** Du musst diesen Wert auf `'docker'` setzen.
### `pre-entrypoint`
**Optional** Erlaubt Dir, ein Skript auszuführen, bevor die Aktion `entrypoint` beginnt. Du kannst `pre-entrypoint:` zum Beispiel verwenden, um mit einem Setup-Skript die Voraussetzungen zu schaffen. {% data variables.product.prodname_actions %} verwendet `docker run`, um diese Aktion zu starten, und führt das Skript in einem neuen Container aus, der das gleiche Basis-Image verwendet. Das bedeutet, dass sich der Laufzeitstatus vom Container des Haupt-`entrypoint` unterscheidet, und alle benötigten Zustände müssen entweder im Arbeitsbereich, `HOME`, oder als `STATE_`-Variable verwendet werden. Die `pre-entrypoint:`-Aktion wird normalerweise immer ausgeführt, aber Du kannst dies mit [`pre-if`](#pre-if) ändern.
Die mit der Syntax [`using`](#runsusing) angegebene Anwendung wird diese Datei ausführen.
In diesem Beispiel führt die `pre-entrypoint:`-Aktion ein Skript namens `setup.sh` aus:
```yaml
runs:
using: 'docker'
image: 'Dockerfile'
args:
- 'bzz'
pre-entrypoint: 'setup.sh'
entrypoint: 'main.sh'
```
### `runs.image`
**Erforderlich** Das Docker-Image, das als Container zum Ausführen der Aktion verwendet werden soll. Der Wert kann der Name des Docker-Basis-Images sein, eine lokale `Dockerdatei` in Deinem Repository, oder ein öffentliches Image im Docker-Hub oder in einer anderen Registry. To reference a `Dockerfile` local to your repository, the file must be named `Dockerfile` and you must use a path relative to your action metadata file. Die `Docker`-Anwendung wird diese Datei ausführen.
### `runs.env`
**Optional** Gibt eine Schlüssel-Wert-Zuordnung von Umgebungsvariablen an, die in der Containerumgebung festgelegt werden sollen.
### `runs.entrypoint`
**Optional** Überschreibt den `ENTRYPOINT` des Dockers in der `Dockerdatei`oder setzt ihn, falls nicht bereits angegeben. Verwende `Entrypoint`, wenn die `Dockerdatei` gibt keinen `Entrypoint` angibt, oder wenn Du die Anweisung `Entrypoint` überschreiben willst. Wenn Du `Entrypoint` weglässt, werden jene Befehle ausgeführt, welche Du in der Anweisung `Entrypoint` des Dockers angibst. Für die Docker-Anweisung `ENTRYPOINT` gibt es sowohl eine _shell_-Form als auch eine _exec_-Form. Die Docker-Dokumentation für `ENTRYPOINT` empfiehlt die _exec_-Form der `ENTRYPOINT`-Anweisung.
Weitere Informationen dazu, wie die `Entrypoint` ausgeführt wird, findest Du unter "[Dockerdatei-Unterstützung für {% data variables.product.prodname_actions %}](/actions/creating-actions/dockerfile-support-for-github-actions/#entrypoint)."
### `post-entrypoint`
**Optional** Erlaubt Dir, ein Aufräumskript auszuführen, sobald die Aktion `runs.entrypoint` abgeschlossen ist. {% data variables.product.prodname_actions %} verwendet `docker run` um diese Aktion zu starten. Da {% data variables.product.prodname_actions %} das Skript in einem neuen Container mit dem glaichen Basis-Image ausführt, unterscheidet sich der Laufzeitstatus vom Container des Haupt-`entrypoint`. Du kannst auf jeden benötigten Zustand, entweder im Arbeitsbereich, `HOME`, oder als `STATE_`-Variable zugreifen. Die `post-entrypoint:`-Aktion wird normalerweise immer ausgeführt, aber Du kannst dies mit [`post-if`](#post-if) ändern.
```yaml
runs:
using: 'docker'
image: 'Dockerfile'
args:
- 'bzz'
entrypoint: 'main.sh'
post-entrypoint: 'cleanup.sh'
```
### `runs.args`
**Optional** Ein Array von Strings, welche die Eingaben für einen Docker-Container definieren. Eingaben können hartcodierte Strings enthalten. Beim Start des Containers übergibt {% data variables.product.prodname_dotcom %} die `args`-Anweisung an den `ENTRYPOINT` des Containers.
Die `args`-Anweisungen werden anstelle der `CMD`-Anweisung in einem `Dockerfile` verwendet. Falls Sie `CMD` in Ihrem `Dockerfile` verwenden, sollten Sie sich an die nach Präferenz angeordneten Richtlinien halten:
{% data reusables.github-actions.dockerfile-guidelines %}
Wenn Du Umgebungsvariablen an eine Aktion übergeben musst, stelle sicher, dass Deine Aktion eine Kommando-Shell ausführt, damit die Variablen ausgewertet werden. Wenn z. B. Dein `Entrypoint`-Attribut auf `"sh -c"` gesetzt ist, werden die `args` an eine Kommando-Shell übergeben. Oder wenn Deine `Dockerdatei` einen `Entrypoint` verwendet, um denselben Befehl (`"sh -c"`) auszuführen, werden die `args` ebenfalls an eine Kommando-Shell übergeben.
Weitere Informationen zur Verwendung der Anweisung `CMD` mit {% data variables.product.prodname_actions %}findest Du unter "[Dockerdate-Unterstützung für {% data variables.product.prodname_actions %}](/actions/creating-actions/dockerfile-support-for-github-actions/#cmd)."
#### Beispiel
{% raw %}
```yaml
runs:
using: 'docker'
image: 'Dockerfile'
args:
- ${{ inputs.greeting }}
- 'foo'
- 'bar'
```
{% endraw %}
## `branding`
Du kannst mit einer Farbe und [Feder](https://feathericons.com/) ein Badge zu erstellen, um Deine Aktion zu personalisieren und von anderen zu unterscheiden. Badges werden neben Deinem Aktionsnamen in [{% data variables.product.prodname_marketplace %}](https://github.com/marketplace?type=actions) angezeigt.
### Beispiel
```yaml
branding:
icon: 'award'
color: 'green'
```
### `branding.color`
Die Hintergrundfarbe des Badges. Kann eine der folgenden sein: `white`, `yellow`, `blue`, `green`, `orange`, `red`, `purple` oder `gray-dark`.
### `branding.icon`
Der Name des zu verwendenden [Federsymbols](https://feathericons.com/).
<table>
<tr>
<td>Aktivität</td>
<td>airplay</td>
<td>alert-circle</td>
<td>alert-octagon</td>
</tr>
<tr>
<td>alert-triangle</td>
<td>align-center</td>
<td>align-justify</td>
<td>align-left</td>
</tr>
<tr>
<td>align-right</td>
<td>anchor</td>
<td>aperture</td>
<td>archivieren</td>
</tr>
<tr>
<td>arrow-down-circle</td>
<td>arrow-down-left</td>
<td>arrow-down-right</td>
<td>arrow-down</td>
</tr>
<tr>
<td>arrow-left-circle</td>
<td>arrow-left</td>
<td>arrow-right-circle</td>
<td>arrow-right</td>
</tr>
<tr>
<td>arrow-up-circle</td>
<td>arrow-up-left</td>
<td>arrow-up-right</td>
<td>arrow-up</td>
</tr>
<tr>
<td>at-sign</td>
<td>award</td>
<td>bar-chart-2</td>
<td>bar-chart</td>
</tr>
<tr>
<td>battery-charging</td>
<td>battery</td>
<td>bell-off</td>
<td>bell</td>
</tr>
<tr>
<td>bluetooth</td>
<td>bold</td>
<td>book-open</td>
<td>book</td>
</tr>
<tr>
<td>bookmark</td>
<td>box</td>
<td>briefcase</td>
<td>calendar</td>
</tr>
<tr>
<td>camera-off</td>
<td>camera</td>
<td>cast</td>
<td>check-circle</td>
</tr>
<tr>
<td>check-square</td>
<td>check</td>
<td>chevron-down</td>
<td>chevron-left</td>
</tr>
<tr>
<td>chevron-right</td>
<td>chevron-up</td>
<td>chevrons-down</td>
<td>chevrons-left</td>
</tr>
<tr>
<td>chevrons-right</td>
<td>chevrons-up</td>
<td>circle</td>
<td>clipboard</td>
</tr>
<tr>
<td>clock</td>
<td>cloud-drizzle</td>
<td>cloud-lightning</td>
<td>cloud-off</td>
</tr>
<tr>
<td>cloud-rain</td>
<td>cloud-snow</td>
<td>cloud</td>
<td>Code</td>
</tr>
<tr>
<td>Befehl</td>
<td>compass</td>
<td>copy</td>
<td>corner-down-left</td>
</tr>
<tr>
<td>corner-down-right</td>
<td>corner-left-down</td>
<td>corner-left-up</td>
<td>corner-right-down</td>
</tr>
<tr>
<td>corner-right-up</td>
<td>corner-up-left</td>
<td>corner-up-right</td>
<td>cpu</td>
</tr>
<tr>
<td>credit-card</td>
<td>crop</td>
<td>crosshair</td>
<td>database</td>
</tr>
<tr>
<td>delete</td>
<td>disc</td>
<td>dollar-sign</td>
<td>download-cloud</td>
</tr>
<tr>
<td>download</td>
<td>droplet</td>
<td>edit-2</td>
<td>edit-3</td>
</tr>
<tr>
<td>edit</td>
<td>external-link</td>
<td>eye-off</td>
<td>eye</td>
</tr>
<tr>
<td>facebook</td>
<td>Fast-Forward</td>
<td>feather</td>
<td>file-minus</td>
</tr>
<tr>
<td>file-plus</td>
<td>file-text</td>
<td>Datei</td>
<td>film</td>
</tr>
<tr>
<td>filter</td>
<td>Flag</td>
<td>folder-minus</td>
<td>folder-plus</td>
</tr>
<tr>
<td>folder</td>
<td>gift</td>
<td>git-branch</td>
<td>git-commit</td>
</tr>
<tr>
<td>git-merge</td>
<td>git-pull-request</td>
<td>globe</td>
<td>grid</td>
</tr>
<tr>
<td>hard-drive</td>
<td>Hash</td>
<td>headphones</td>
<td>heart</td>
</tr>
<tr>
<td>help-circle</td>
<td>home</td>
<td>image</td>
<td>inbox</td>
</tr>
<tr>
<td>info</td>
<td>italic</td>
<td>layers</td>
<td>layout</td>
</tr>
<tr>
<td>life-buoy</td>
<td>link-2</td>
<td>link</td>
<td>list</td>
</tr>
<tr>
<td>loader</td>
<td>lock</td>
<td>log-in</td>
<td>log-out</td>
</tr>
<tr>
<td>mail</td>
<td>map-pin</td>
<td>map</td>
<td>maximize-2</td>
</tr>
<tr>
<td>maximize</td>
<td>menu</td>
<td>message-circle</td>
<td>message-square</td>
</tr>
<tr>
<td>mic-off</td>
<td>mic</td>
<td>minimize-2</td>
<td>minimize</td>
</tr>
<tr>
<td>minus-circle</td>
<td>minus-square</td>
<td>minus</td>
<td>monitor</td>
</tr>
<tr>
<td>moon</td>
<td>more-horizontal</td>
<td>more-vertical</td>
<td>move</td>
</tr>
<tr>
<td>music</td>
<td>navigation-2</td>
<td>navigation</td>
<td>octagon</td>
</tr>
<tr>
<td>paketieren</td>
<td>paperclip</td>
<td>pause-circle</td>
<td>pause</td>
</tr>
<tr>
<td>percent</td>
<td>phone-call</td>
<td>phone-forwarded</td>
<td>phone-incoming</td>
</tr>
<tr>
<td>phone-missed</td>
<td>phone-off</td>
<td>phone-outgoing</td>
<td>phone</td>
</tr>
<tr>
<td>pie-chart</td>
<td>play-circle</td>
<td>play</td>
<td>plus-circle</td>
</tr>
<tr>
<td>plus-square</td>
<td>plus</td>
<td>pocket</td>
<td>power</td>
</tr>
<tr>
<td>printer</td>
<td>radio</td>
<td>refresh-ccw</td>
<td>refresh-cw</td>
</tr>
<tr>
<td>repeat</td>
<td>zurücksetzen</td>
<td>rotate-ccw</td>
<td>rotate-cw</td>
</tr>
<tr>
<td>rss</td>
<td>save</td>
<td>scissors</td>
<td>search</td>
</tr>
<tr>
<td>send</td>
<td>server</td>
<td>settings</td>
<td>share-2</td>
</tr>
<tr>
<td>share</td>
<td>shield-off</td>
<td>shield</td>
<td>shopping-bag</td>
</tr>
<tr>
<td>shopping-cart</td>
<td>shuffle</td>
<td>Seitenleiste</td>
<td>skip-back</td>
</tr>
<tr>
<td>skip-forward</td>
<td>slash</td>
<td>sliders</td>
<td>smartphone</td>
</tr>
<tr>
<td>speaker</td>
<td>square</td>
<td>Stern</td>
<td>stop-circle</td>
</tr>
<tr>
<td>sun</td>
<td>sunrise</td>
<td>sunset</td>
<td>tablet</td>
</tr>
<tr>
<td>Tag</td>
<td>target</td>
<td>terminal</td>
<td>thermometer</td>
</tr>
<tr>
<td>thumbs-down</td>
<td>thumbs-up</td>
<td>toggle-left</td>
<td>toggle-right</td>
</tr>
<tr>
<td>trash-2</td>
<td>trash</td>
<td>trending-down</td>
<td>trending-up</td>
</tr>
<tr>
<td>triangle</td>
<td>truck</td>
<td>tv</td>
<td>type</td>
</tr>
<tr>
<td>umbrella</td>
<td>underline</td>
<td>unlock</td>
<td>upload-cloud</td>
</tr>
<tr>
<td>hochladen</td>
<td>user-check</td>
<td>user-minus</td>
<td>user-plus</td>
</tr>
<tr>
<td>user-x</td>
<td>Benutzer</td>
<td>benutzer</td>
<td>video-off</td>
</tr>
<tr>
<td>video</td>
<td>voicemail</td>
<td>volume-1</td>
<td>volume-2</td>
</tr>
<tr>
<td>volume-x</td>
<td>volume</td>
<td>beobachten</td>
<td>wifi-off</td>
</tr>
<tr>
<td>wifi</td>
<td>wind</td>
<td>x-circle</td>
<td>x-square</td>
</tr>
<tr>
<td>x</td>
<td>zap-off</td>
<td>zap</td>
<td>zoom-in</td>
</tr>
<tr>
<td>zoom-out</td>
<td></td>
<td></td>
<td></td>
</table>

View File

@@ -1,57 +0,0 @@
---
title: Aktionen auf dem GitHub-Marktplatz veröffentlichen
intro: 'Du kannst Aktionen auf dem {% data variables.product.prodname_marketplace %} veröffentlichen und der {% data variables.product.prodname_dotcom %}-Gemeinschaft zur Verfügung stellen.'
redirect_from:
- /github/automating-your-workflow-with-github-actions/publishing-actions-in-github-marketplace
- /actions/automating-your-workflow-with-github-actions/publishing-actions-in-github-marketplace
- /actions/building-actions/publishing-actions-in-github-marketplace
versions:
fpt: '*'
ghec: '*'
type: how_to
shortTitle: Publish in GitHub Marketplace
---
You must accept the terms of service to publish actions in {% data variables.product.prodname_marketplace %}.
## Informationen zum Veröffentlichen von Aktionen
Bevor Du eine Aktion veröffentlichen kannst, musst Du eine Aktion in Deinem Repository erstellen. For more information, see "[Creating actions](/actions/creating-actions)."
Wenn Du vorhast, Deine Aktion auf dem {% data variables.product.prodname_marketplace %} zu veröffentlichen, musst Du sicherstellen, dass das Repository nur jene Metadaten-, Code- und andere Dateien enthält, welche für die Aktion notwendig sind. Creating a single repository for the action allows you to tag, release, and package the code in a single unit. {% data variables.product.prodname_dotcom %} verwendet auch die Metadaten der Aktion auf Deiner {% data variables.product.prodname_marketplace %}-Seite.
Aktionen werden ohne Überprüfung durch {% data variables.product.prodname_dotcom %} sofort auf dem {% data variables.product.prodname_marketplace %} veröffentlicht, sofern sie folgende Anforderungen erfüllen:
- Die Aktion muss in einem öffentlichen Repository liegen.
- Jedes Repository muss eine einzelne Aktion enthalten.
- Die Metadaten-Datei (`action.yml` oder `action.yaml`) der Aktion muss im Stammverzeichnis (root) des Repositorys liegen.
- Der `name` in der Metadaten-Datei der Aktion muss eindeutig sein.
- Der `name` darf nicht mit irgend einem existierenden Aktionsnamen übereinstimmen, der auf dem {% data variables.product.prodname_marketplace %} veröffentlicht wurde.
- Der `name` darf nicht mit einem Benutzer oder einer Organisation auf {% data variables.product.prodname_dotcom %}übereinstimmen, es sei denn, eben dieser Benutzer oder Organisationsinhaber veröffentlicht die Aktion. Beispielsweise kann nur die Organisation {% data variables.product.prodname_dotcom %} eine Aktion namens `github` veröffentlichen.
- Der `name` darf nicht mit einer existierenden Kategorie des {% data variables.product.prodname_marketplace %} übereinstimmen.
- {% data variables.product.prodname_dotcom %} behält sich die Namen von {% data variables.product.prodname_dotcom %}-Funktionen vor.
## Eine Aktion veröffentlichen
Du kannst die von Dir erstellte Aktion auf den {% data variables.product.prodname_marketplace %} stellen, indem Du sie als neue Version markierst und publizierst.
Um ein neues Release zu entwerfen und die Aktion auf dem {% data variables.product.prodname_marketplace %} zu veröffentlichen, folge diesen Anweisungen:
{% data reusables.repositories.navigate-to-repo %}
1. Wenn ein Repository für eine Aktion eine Metadaten-Datei (`action.yml` oder `Aktion. aml`) enthält, siehst Du ein Banner, um die Aktion auf dem {% data variables.product.prodname_marketplace %} zu veröffentlichen. Klicke auf **Draft a release** (Ein neues Release entwerfen). ![Schaltfläche um diese Aktion auf dem Marktplatz zu veröffentlichen](/assets/images/help/repository/publish-github-action-to-markeplace-button.png)
1. Wähle **Publish this action to the {% data variables.product.prodname_marketplace %}** (Diese Aktion auf dem {% data variables.product.prodname_marketplace %} veröffentlichen). Wenn Du das Ankreuzfeld **Publish this action to the {% data variables.product.prodname_marketplace %}** nicht auswählen kannst, musst Du zuerst die {% data variables.product.prodname_marketplace %}-Vereinbarung lesen und akzeptieren. ![Veröffentlichung auf dem Marktplatz auswählen](/assets/images/help/repository/marketplace_actions_publish.png)
1. Wenn die Bezeichnungen in Deiner Metadaten-Datei irgendwelche Probleme verursachen, wird Dir eine Fehlermeldung angezeigt. ![Siehe Benachrichtigung](/assets/images/help/repository/marketplace_actions_fixerrors.png)
1. Wenn Vorschläge auf dem Bildschirm angezeigt werden, setze diese um, indemDu Deine Metadaten-Datei aktualisierst. Sobald Du fertig bist, siehst Du eine Nachricht „Everything looks good!“ (Alles sieht gut aus). ![Fehler beheben](/assets/images/help/repository/marketplace_actions_looksgood.png)
1. Wähle eine „Primary Category“ (Haupt-Kategorie) und optional „Another Category“ (Eine weitere Kategorie), die den Leuten hilft, Deine Aktion auf dem {% data variables.product.prodname_marketplace %} zu finden. ![Kategorie wählen](/assets/images/help/repository/marketplace_actions_categories.png)
1. Tagge eine Aktion mit einer Version und fügen Sie einen Titel für das Release hinzu. Dies zeigt den Leuten, welche Änderungen oder Funktionen das Release umfasst. Die Leute werden die Version auf der dedizierten {% data variables.product.prodname_marketplace %}-Seite der Aktion sehen. ![Version taggen](/assets/images/help/repository/marketplace_actions_version.png)
1. Fülle alle anderen Felder aus und klicke auf **Publish release** (Release veröffentlichen). Zum Veröffentlichen brauchst Du die Zwei-Faktor-Authentifizierung. Weitere Informationen findest Du unter „[Zwei-Faktor-Authentifizierung konfigurieren](/articles/configuring-two-factor-authentication/)“. ![Release veröffentlichen](/assets/images/help/repository/marketplace_actions_publishrelease.png)
## Eine Aktion vom {% data variables.product.prodname_marketplace %} entfernen
Um eine veröffentlichte Aktion vom {% data variables.product.prodname_marketplace %} zu entfernen, musst Du jedes veröffentlichte Release aktualisieren. Führe die folgenden Schritte für jedes auf dem {% data variables.product.prodname_marketplace %} veröffentlichte Release der Aktion aus.
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.releases %}
3. Klicke auf der Seite „Releases“ (Veröffentlichungen) rechts neben dem zu bearbeitenden Release auf **Edit** (Bearbeiten). ![Schaltfläche um das Release zu bearbeiten](/assets/images/help/releases/release-edit-btn.png)
4. Klicke auf **Publish this action to the {% data variables.product.prodname_marketplace %}** (...veröffentlichen) um die Markierung aus dem Kontrollkästchen zu entfernen. ![Schaltfläche um diese Aktion zu verröffentlichen](/assets/images/help/repository/actions-marketplace-unpublish.png)
5. Klicke auf **Update release** (Release aktualisieren) am Ende der Seite. ![Schaltfläche um das Release zu aktualisieren](/assets/images/help/repository/actions-marketplace-update-release.png)

View File

@@ -1,95 +0,0 @@
---
title: Releasing and maintaining actions
shortTitle: Releasing and maintaining actions
intro: You can leverage automation and open source best practices to release and maintain actions.
type: tutorial
topics:
- Action development
- Actions
- Community
versions:
fpt: '*'
ghes: '*'
ghae: '*'
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## Einführung
After you create an action, you'll want to continue releasing new features while working with community contributions. This tutorial describes an example process you can follow to release and maintain actions in open source. The example:
* Leverages {% data variables.product.prodname_actions %} for continuous integration, dependency updates, release management, and task automation.
* Provides confidence through automated tests and build badges.
* Indicates how the action can be used, ideally as part of a broader workflow.
* Signal what type of community contributions you welcome. (For example, issues, pull requests, or vulnerability reports.)
For an applied example of this process, see [github-developer/javascript-action](https://github.com/github-developer/javascript-action).
## Developing and releasing actions
In this section, we discuss an example process for developing and releasing actions and show how to use {% data variables.product.prodname_actions %} to automate the process.
### About JavaScript actions
JavaScript actions are Node.js repositories with metadata. However, JavaScript actions have additional properties compared to traditional Node.js projects:
* Dependent packages are committed alongside the code, typically in a compiled and minified form. This means that automated builds and secure community contributions are important.
{% ifversion fpt %}
* Tagged releases can be published directly to {% data variables.product.prodname_marketplace %} and consumed by workflows across {% data variables.product.prodname_dotcom %}.
{% endif %}
* Many actions make use of {% data variables.product.prodname_dotcom %}'s APIs and third party APIs, so we encourage robust end-to-end testing.
### Setting up {% data variables.product.prodname_actions %} workflows
To support the developer process in the next section, add two {% data variables.product.prodname_actions %} workflows to your repository:
1. Add a workflow that triggers when a commit is pushed to a feature branch or to `main` or when a pull request is created. Configure the workflow to run your unit and integration tests. For an example, see [this workflow](https://github.com/github-developer/javascript-action/blob/963a3b9a9c662fd499419a240ed8c49411ff5add/.github/workflows/test.yml).
2. Add a workflow that triggers when a release is published or edited. Configure the workflow to ensure semantic tags are in place. You can use an action like [JasonEtco/build-and-tag-action](https://github.com/JasonEtco/build-and-tag-action) to compile and bundle the JavaScript and metadata file and force push semantic major, minor, and patch tags. For an example, see [this workflow](https://github.com/github-developer/javascript-action/blob/963a3b9a9c662fd499419a240ed8c49411ff5add/.github/workflows/publish.yml). For more information about semantic tags, see "[About semantic versioning](https://docs.npmjs.com/about-semantic-versioning)."
### Example developer process
Here is an example process that you can follow to automatically run tests, create a release{% ifversion fpt%} and publish to {% data variables.product.prodname_marketplace %}{% endif %}, and publish your action.
1. Do feature work in branches per GitHub flow. For more information, see "[GitHub flow](/get-started/quickstart/github-flow)."
* Whenever a commit is pushed to the feature branch, your testing workflow will automatically run the tests.
2. Create pull requests to the `main` branch to initiate discussion and review, merging when ready.
* When a pull request is opened, either from a branch or a fork, your testing workflow will again run the tests, this time with the merge commit.
* **Note:** for security reasons, workflows triggered by `pull_request` from forks have restricted `GITHUB_TOKEN` permissions and do not have access to secrets. If your tests or other workflows triggered upon pull request require access to secrets, consider using a different event like a [manual trigger](/actions/reference/events-that-trigger-workflows#manual-events) or a [`pull_request_target`](/actions/reference/events-that-trigger-workflows#pull_request_target). Read more [here](/actions/reference/events-that-trigger-workflows#pull-request-events-for-forked-repositories).
3. Create a semantically tagged release. {% ifversion fpt %} You may also publish to {% data variables.product.prodname_marketplace %} with a simple checkbox. {% endif %} For more information, see "[Managing releases in a repository](/github/administering-a-repository/managing-releases-in-a-repository#creating-a-release)"{% ifversion fpt %} and "[Publishing actions in {% data variables.product.prodname_marketplace %}](/actions/creating-actions/publishing-actions-in-github-marketplace#publishing-an-action)"{% endif %}.
* When a release is published or edited, your release workflow will automatically take care of compilation and adjusting tags.
* We recommend creating releases using semantically versioned tags for example, `v1.1.3` and keeping major (`v1`) and minor (`v1.1`) tags current to the latest appropriate commit. For more information, see "[About custom actions](/actions/creating-actions/about-custom-actions#using-release-management-for-actions)" and "[About semantic versioning](https://docs.npmjs.com/about-semantic-versioning).
### Results
Unlike some other automated release management strategies, this process intentionally does not commit dependencies to the `main` branch, only to the tagged release commits. By doing so, you encourage users of your action to reference named tags or `sha`s, and you help ensure the security of third party pull requests by doing the build yourself during a release.
Using semantic releases means that the users of your actions can pin their workflows to a version and know that they might continue to receive the latest stable, non-breaking features, depending on their comfort level:
## Working with the community
{% data variables.product.product_name %} provides tools and guides to help you work with the open source community. Here are a few tools we recommend setting up for healthy bidirectional communication. By providing the following signals to the community, you encourage others to use, modify, and contribute to your action:
* Maintain a `README` with plenty of usage examples and guidance. Weitere Informationen finden Sie unter „[Informationen zu README-Dateien](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes)“.
* Include a workflow status badge in your `README` file. For more information, see "[Adding a workflow status badge](/actions/managing-workflow-runs/adding-a-workflow-status-badge)." Also visit [shields.io](https://shields.io/) to learn about other badges that you can add.{% ifversion fpt %}
* Add community health files like `CODE_OF_CONDUCT`, `CONTRIBUTING`, and `SECURITY`. For more information, see "[Creating a default community health file](/github/building-a-strong-community/creating-a-default-community-health-file#supported-file-types)."{% endif %}
* Keep issues current by utilizing actions like [actions/stale](https://github.com/actions/stale).
## Weiterführende Informationen
Examples where similar patterns are employed include:
* [github/super-linter](https://github.com/github/super-linter)
* [octokit/request-action](https://github.com/octokit/request-action)
* [github-developer/javascript-action](https://github.com/github-developer/javascript-action)

View File

@@ -1,53 +0,0 @@
---
title: Exitcodes für Aktionen setzen
shortTitle: Exitcodes setzen
intro: 'Du kannst mittels Exitcodes den Status einer Aktion setzen. {% data variables.product.prodname_dotcom %} zeigt Status, um erfolgreiche oder fehlgeschlagene Aktionen kenntlich zu machen.'
redirect_from:
- /actions/building-actions/setting-exit-codes-for-actions
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: how_to
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
## Informationen zu Exitcodes
{% data variables.product.prodname_dotcom %} uses the exit code to set the action's check run status, which can be `success` or `failure`.
| Exit-Status | Prüflaufstatus | Beschreibung |
| --------------------------------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `0` | `success (Erfolg)` | Die Aktion wurde erfolgreich abgeschlossen, und andere Aufgaben, die von dieser Aktion abhängig sind, können nun starten. |
| Nonzero value (any integer but 0) | `failure (Fehlschlag)` | Alle anderen Exit-Codes weisen darauf hin, dass die Aktion fehlgeschlagen ist. Wenn eine Aktion fehlschlägt, werden alle derzeit laufenden Aktionen abgebrochen, und künftige Aktionen werden übersprungen. Sowohl der Prüflauf als auch die Prüfsuite erhalten den Status `failure`. |
## Fehler-Exit-Code in einer JavaScript-Aktion festlegen
Wenn Sie eine JavaScript-Aktion erstellen, können Sie mit dem Aktions-Toolkit [`@actions/core`](https://github.com/actions/toolkit/tree/main/packages/core) eine Meldung protokollieren und einen Fehler-Exit-Code festlegen. Ein Beispiel:
```javascript
try {
// something
} catch (error) {
core.setFailed(error.message);
}
```
Weitere Informationen findest Du unter „[Eine JavaScript-Aktion erstellen](/articles/creating-a-javascript-action)“.
## Fehler-Exit-Code in einer Docker-Container-Aktion festlegen
Wenn Du eine Docker-Container-Aktion erstellst, kannst Du einen Fehler-Exit-Code im Skript `entrypoint.sh` festlegen. Ein Beispiel:
```
if <condition> ; then
echo "Game over!"
exit 1
fi
```
Weitere Informationen finden Sie unter „[Eine Docker-Container-Aktion erstellen](/articles/creating-a-docker-container-action)“.

View File

@@ -1,41 +0,0 @@
---
title: About continuous deployment
intro: 'You can create custom continuous deployment (CD) workflows directly in your {% data variables.product.prodname_dotcom %} repository with {% data variables.product.prodname_actions %}.'
product: '{% data reusables.gated-features.actions %}'
versions:
fpt: '*'
ghes: '*'
ghae: '*'
type: overview
topics:
- CD
shortTitle: Continuous deployment
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
## About continuous deployment
_Continuous deployment_ (CD) is the practice of using automation to publish and deploy software updates. As part of the typical CD process, the code is automatically built and tested before deployment.
Continuous deployment is often coupled with continuous integration. For more information about continuous integration, see "[About continuous integration](/actions/guides/about-continuous-integration)".
## About continuous deployment using {% data variables.product.prodname_actions %}
You can set up a {% data variables.product.prodname_actions %} workflow to deploy your software product. To verify that your product works as expected, your workflow can build the code in your repository and run your tests before deploying.
You can configure your CD workflow to run when a {% data variables.product.product_name %} event occurs (for example, when new code is pushed to the default branch of your repository), on a set schedule, manually, or when an external event occurs using the repository dispatch webhook. For more information about when your workflow can run, see "[Events that trigger workflows](/actions/reference/events-that-trigger-workflows)."
{% data variables.product.prodname_actions %} provides features that give you more control over deployments. For example, you can use environments to require approval for a job to proceed, restrict which branches can trigger a workflow, or limit access to secrets. You can use concurrency to limit your CD pipeline to a maximum of one in-progress deployment and one pending deployment. For more information about these features, see "[Deploying with GitHub Actions](/actions/deployment/deploying-with-github-actions)" and "[Using environments for deployment](/actions/deployment/using-environments-for-deployment)."
## Workflow templates and third party actions
{% data reusables.actions.cd-templates-actions %}
## Weiterführende Informationen
- [Deploying with GitHub Actions](/actions/deployment/deploying-with-github-actions)
- [Using environments for deployment](/actions/deployment/using-environments-for-deployment){% ifversion fpt %}
- "[ Abrechnung für {% data variables.product.prodname_actions %} verwalten](/billing/managing-billing-for-github-actions)"
{% endif %}

View File

@@ -1,56 +0,0 @@
---
title: About continuous deployment
intro: 'You can create custom continuous deployment (CD) workflows directly in your {% data variables.product.prodname_dotcom %} repository with {% data variables.product.prodname_actions %}.'
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
type: overview
redirect_from:
- /actions/deployment/about-continuous-deployment
topics:
- CD
shortTitle: About continuous deployment
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
## About continuous deployment
_Continuous deployment_ (CD) is the practice of using automation to publish and deploy software updates. As part of the typical CD process, the code is automatically built and tested before deployment.
Continuous deployment is often coupled with continuous integration. For more information about continuous integration, see "[About continuous integration](/actions/guides/about-continuous-integration)".
## About continuous deployment using {% data variables.product.prodname_actions %}
You can set up a {% data variables.product.prodname_actions %} workflow to deploy your software product. To verify that your product works as expected, your workflow can build the code in your repository and run your tests before deploying.
You can configure your CD workflow to run when a {% data variables.product.product_name %} event occurs (for example, when new code is pushed to the default branch of your repository), on a set schedule, manually, or when an external event occurs using the repository dispatch webhook. For more information about when your workflow can run, see "[Events that trigger workflows](/actions/reference/events-that-trigger-workflows)."
{% ifversion fpt or ghae or ghes > 3.0 or ghec %}
{% data variables.product.prodname_actions %} provides features that give you more control over deployments. For example, you can use environments to require approval for a job to proceed, restrict which branches can trigger a workflow, or limit access to secrets. {% ifversion fpt or ghae-next or ghes > 3.1 or ghec %}You can use concurrency to limit your CD pipeline to a maximum of one in-progress deployment and one pending deployment. {% endif %}For more information about these features, see "[Deploying with GitHub Actions](/actions/deployment/deploying-with-github-actions)" and "[Using environments for deployment](/actions/deployment/using-environments-for-deployment)."{% endif %}
{% ifversion fpt or ghec or ghae-issue-4856 %}
## Using OpenID Connect to access cloud resources
{% data reusables.actions.about-oidc-short-overview %}
{% endif %}
## Workflow templates and third party actions
{% data reusables.actions.cd-templates-actions %}
{% ifversion fpt or ghae or ghes > 3.0 or ghec %}
## Weiterführende Informationen
- [Deploying with GitHub Actions](/actions/deployment/deploying-with-github-actions)
- [Using environments for deployment](/actions/deployment/using-environments-for-deployment){% ifversion fpt or ghec %}
- "[Managing billing for {% data variables.product.prodname_actions %}](/billing/managing-billing-for-github-actions)"{% endif %}
{% endif %}

View File

@@ -1,172 +0,0 @@
---
title: Deploying with GitHub Actions
intro: Learn how to control deployments with features like environments and concurrency.
versions:
fpt: '*'
ghes: '>=3.1'
ghae: '*'
ghec: '*'
type: overview
redirect_from:
- /actions/deployment/deploying-with-github-actions
topics:
- CD
shortTitle: Deploy with GitHub Actions
---
{% data reusables.actions.enterprise-beta %}
{% data reusables.actions.enterprise-github-hosted-runners %}
{% data reusables.actions.ae-beta %}
## Einführung
{% data variables.product.prodname_actions %} offers features that let you control deployments. Sie können:
- Trigger workflows with a variety of events.
- Configure environments to set rules before a job can proceed and to limit access to secrets.
- Use concurrency to control the number of deployments running at a time.
For more information about continuous deployment, see "[About continuous deployment](/actions/deployment/about-continuous-deployment)."
## Vorrausetzungen
You should be familiar with the syntax for {% data variables.product.prodname_actions %}. For more information, see "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)."
## Triggering your deployment
You can use a variety of events to trigger your deployment workflow. Some of the most common are: `pull_request`, `push`, and `workflow_dispatch`.
For example, a workflow with the following triggers runs whenever:
- There is a push to the `main` branch.
- A pull request targeting the `main` branch is opened, synchronized, or reopened.
- Someone manually triggers it.
```yaml
on:
push:
branches:
- main
pull_request:
branches:
- main
workflow_dispatch:
```
Weitere Informationen findest Du unter "[Ereignisse, die Workflows auslösen](/actions/reference/events-that-trigger-workflows)."
## Using environments
{% data reusables.actions.about-environments %}
## Using concurrency
Concurrency ensures that only a single job or workflow using the same concurrency group will run at a time. You can use concurrency so that an environment has a maximum of one deployment in progress and one deployment pending at a time.
{% note %}
**Note:** `concurrency` and `environment` are not connected. The concurrency value can be any string; it does not need to be an environment name. Additionally, if another workflow uses the same environment but does not specify concurrency, that workflow will not be subject to any concurrency rules.
{% endnote %}
For example, when the following workflow runs, it will be paused with the status `pending` if any job or workflow that uses the `production` concurrency group is in progress. It will also cancel any job or workflow that uses the `production` concurrency group and has the status `pending`. This means that there will be a maximum of one running and one pending job or workflow in that uses the `production` concurrency group.
```yaml
name: Deployment
concurrency: production
on:
push:
branches:
- main
jobs:
deployment:
runs-on: ubuntu-latest
environment: production
steps:
- name: deploy
# ...deployment-specific steps
```
You can also specify concurrency at the job level. This will allow other jobs in the workflow to proceed even if the concurrent job is `pending`.
```yaml
name: Deployment
on:
push:
branches:
- main
jobs:
deployment:
runs-on: ubuntu-latest
environment: production
concurrency: production
steps:
- name: deploy
# ...deployment-specific steps
```
You can also use `cancel-in-progress` to cancel any currently running job or workflow in the same concurrency group.
```yaml
name: Deployment
concurrency:
group: production
cancel-in-progress: true
on:
push:
branches:
- main
jobs:
deployment:
runs-on: ubuntu-latest
environment: production
steps:
- name: deploy
# ...deployment-specific steps
```
## Viewing deployment history
When a {% data variables.product.prodname_actions %} workflow deploys to an environment, the environment is displayed on the main page of the repository. For more information about viewing deployments to environments, see "[Viewing deployment history](/developers/overview/viewing-deployment-history)."
## Monitoring workflow runs
Every workflow run generates a real-time graph that illustrates the run progress. You can use this graph to monitor and debug deployments. For more information see, "[Using the visualization graph](/actions/monitoring-and-troubleshooting-workflows/using-the-visualization-graph)."
You can also view the logs of each workflow run and the history of workflow runs. For more information, see "[Viewing workflow run history](/actions/monitoring-and-troubleshooting-workflows/viewing-workflow-run-history)."
## Tracking deployments through apps
{% ifversion fpt or ghec %}
If your personal account or organization on {% ifversion ghae %}{% data variables.product.product_name %}{% else %}{% data variables.product.product_location %}{% endif %} is integrated with Microsoft Teams or Slack, you can track deployments that use environments through Microsoft Teams or Slack. For example, you can receive notifications through the app when a deployment is pending approval, when a deployment is approved, or when the deployment status changes. For more information about integrating Microsoft Teams or Slack, see "[GitHub extensions and integrations](/github/customizing-your-github-workflow/exploring-integrations/github-extensions-and-integrations#team-communication-tools)."
{% endif %}
You can also build an app that uses deployment and deployment status webhooks to track deployments. {% data reusables.actions.environment-deployment-event %} For more information, see "[Apps](/developers/apps)" and "[Webhook events and payloads](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#deployment)."
{% ifversion fpt or ghes or ghec %}
## Die Wahl eines Läufers
You can run your deployment workflow on {% data variables.product.company_short %}-hosted runners or on self-hosted runners. Traffic from {% data variables.product.company_short %}-hosted runners can come from a [wide range of network addresses](/rest/reference/meta#get-github-meta-information). If you are deploying to an internal environment and your company restricts external traffic into private networks, {% data variables.product.prodname_actions %} workflows running on {% data variables.product.company_short %}-hosted runners may not be communicate with your internal services or resources. To overcome this, you can host your own runners. For more information, see "[About self-hosted runners](/actions/hosting-your-own-runners/about-self-hosted-runners)" and "[About GitHub-hosted runners](/actions/using-github-hosted-runners/about-github-hosted-runners)."
{% endif %}
## Displaying a status badge
You can use a status badge to display the status of your deployment workflow. {% data reusables.repositories.actions-workflow-status-badge-intro %}
For more information, see "[Adding a workflow status badge](/actions/managing-workflow-runs/adding-a-workflow-status-badge)."
## Nächste Schritte:
This article demonstrated features of {% data variables.product.prodname_actions %} that you can add to your deployment workflows.
{% data reusables.actions.cd-templates-actions %}

View File

@@ -1,13 +0,0 @@
---
title: About deployments
shortTitle: About deployments
intro: 'Learn how deployments can run with {% data variables.product.prodname_actions %} workflows.'
versions:
fpt: '*'
ghae: issue-4856
ghec: '*'
children:
- /about-continuous-deployment
- /deploying-with-github-actions
---

Some files were not shown because too many files have changed in this diff Show More