You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: translations/ja-JP/content/actions/creating-actions/releasing-and-maintaining-actions.md
+9-8Lines changed: 9 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,14 +9,15 @@ topics:
9
9
- Community
10
10
versions:
11
11
fpt: '*'
12
+
ghec: '*'
12
13
ghes: '*'
13
14
ghae: '*'
14
15
---
15
16
16
17
{% data reusables.actions.enterprise-beta %}
17
18
{% data reusables.actions.enterprise-github-hosted-runners %}
18
19
19
-
## はじめに
20
+
## Introduction
20
21
21
22
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:
22
23
@@ -37,7 +38,7 @@ JavaScript actions are Node.js repositories with metadata. However, JavaScript a
37
38
38
39
* 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.
39
40
40
-
{% ifversion fpt %}
41
+
{% ifversion fpt or ghec %}
41
42
42
43
* Tagged releases can be published directly to {% data variables.product.prodname_marketplace %} and consumed by workflows across {% data variables.product.prodname_dotcom %}.
43
44
@@ -54,7 +55,7 @@ To support the developer process in the next section, add two {% data variables.
54
55
55
56
### Example developer process
56
57
57
-
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.
58
+
Here is an example process that you can follow to automatically run tests, create a release{% ifversion fpt or ghec%} and publish to {% data variables.product.prodname_marketplace %}{% endif %}, and publish your action.
58
59
59
60
1. Do feature work in branches per GitHub flow. For more information, see "[GitHub flow](/get-started/quickstart/github-flow)."
60
61
* Whenever a commit is pushed to the feature branch, your testing workflow will automatically run the tests.
@@ -65,13 +66,13 @@ Here is an example process that you can follow to automatically run tests, creat
65
66
66
67
***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).
67
68
68
-
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 %}.
69
+
3. Create a semantically tagged release. {% ifversion fpt or ghec %} 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 or ghec %} and "[Publishing actions in {% data variables.product.prodname_marketplace %}](/actions/creating-actions/publishing-actions-in-github-marketplace#publishing-an-action)"{% endif %}.
69
70
70
71
* When a release is published or edited, your release workflow will automatically take care of compilation and adjusting tags.
71
72
72
73
* 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).
73
74
74
-
### 結果
75
+
### Results
75
76
76
77
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.
77
78
@@ -81,12 +82,12 @@ Using semantic releases means that the users of your actions can pin their workf
81
82
82
83
{% 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:
83
84
84
-
* Maintain a `README` with plenty of usage examples and guidance. 詳しい情報については「[README について](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes)」を参照してください。
85
-
* 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 %}
85
+
* Maintain a `README` with plenty of usage examples and guidance. For more information, see "[About READMEs](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes)."
86
+
* 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 or ghec %}
86
87
* 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 %}
87
88
* Keep issues current by utilizing actions like [actions/stale](https://github.com/actions/stale).
88
89
89
-
## 参考リンク
90
+
## Further reading
90
91
91
92
Examples where similar patterns are employed include:
0 commit comments