Merge branch 'main' into patch-2
This commit is contained in:
Binary file not shown.
|
After Width: | Height: | Size: 122 KiB |
BIN
assets/images/help/repository/PR-required-check-skipped.png
Normal file
BIN
assets/images/help/repository/PR-required-check-skipped.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 110 KiB |
@@ -70,6 +70,7 @@ This example has a job called `Get_OIDC_ID_token` that uses actions to request a
|
||||
|
||||
This action exchanges a {% data variables.product.prodname_dotcom %} OIDC token for a Google Cloud access token, using [Workload Identity Federation](https://cloud.google.com/iam/docs/workload-identity-federation).
|
||||
|
||||
{% raw %}
|
||||
```yaml{:copy}
|
||||
name: List services in GCP
|
||||
on:
|
||||
@@ -97,3 +98,4 @@ jobs:
|
||||
gcloud auth login --brief --cred-file="${{ steps.auth.outputs.credentials_file_path }}"
|
||||
gcloud config list
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
@@ -129,7 +129,7 @@ git push --set-upstream origin main
|
||||
|
||||
### Example: contribute to an existing branch on {% data variables.product.product_name %}
|
||||
|
||||
This example assumes that you already have a project called `repo` already on the machine and that a new branch has been pushed to {% data variables.product.product_name %} since the last time changes were made locally.
|
||||
This example assumes that you already have a project called `repo` on the machine and that a new branch has been pushed to {% data variables.product.product_name %} since the last time changes were made locally.
|
||||
|
||||
```bash
|
||||
# change into the `repo` directory
|
||||
|
||||
@@ -35,7 +35,7 @@ In open source projects, forks are often used to iterate on ideas or changes bef
|
||||
|
||||
{% data reusables.repositories.private_forks_inherit_permissions %}
|
||||
|
||||
If you want to create a new repository from the contents of an existing repository but don't want to merge your changes upstream in the future, you can duplicate the repository or, if the repository is a template, use the repository as a template. For more information, see "[Duplicating a repository](/articles/duplicating-a-repository)" and "[Creating a repository from a template](/articles/creating-a-repository-from-a-template)".
|
||||
If you want to create a new repository from the contents of an existing repository but don't want to merge your changes to the upstream in the future, you can duplicate the repository or, if the repository is a template, you can use the repository as a template. For more information, see "[Duplicating a repository](/articles/duplicating-a-repository)" and "[Creating a repository from a template](/articles/creating-a-repository-from-a-template)".
|
||||
|
||||
## Further reading
|
||||
|
||||
|
||||
@@ -25,7 +25,7 @@ To create commits on behalf of an organization:
|
||||
- `org` is the organization's login
|
||||
- `name@organization.com` is in the organization's domain
|
||||
|
||||
Organization's can use the `name@organization.com` email as a public point of contact for open source efforts.
|
||||
Organizations can use the `name@organization.com` email as a public point of contact for open source efforts.
|
||||
|
||||
## Creating commits with an `on-behalf-of` badge on the command line
|
||||
|
||||
|
||||
@@ -38,11 +38,79 @@ remote: error: Required status check "ci-build" is failing
|
||||
|
||||
{% ifversion fpt or ghae or ghes or ghec %}
|
||||
|
||||
## Conflicts between head commit and test merge commit
|
||||
|
||||
Sometimes, the results of the status checks for the test merge commit and head commit will conflict. If the test merge commit has a status, the test merge commit must pass. Otherwise, the status of the head commit must pass before you can merge the branch. For more information about test merge commits, see "[Pulls](/rest/reference/pulls#get-a-pull-request)."
|
||||
|
||||

|
||||
{% endif %}
|
||||
|
||||
## Handling skipped but required checks
|
||||
|
||||
Sometimes a required status check is skipped on pull requests due to path filtering. For example, a Node.JS test will be skipped on a pull request that just fixes a typo in your README file and makes no changes to the JavaScript and TypeScript files in the `scripts` directory.
|
||||
|
||||
If this check is required and it gets skipped, then the check's status is shown as pending, because it's required. In this situation you won't be able to merge the pull request.
|
||||
|
||||
### Example
|
||||
|
||||
In this example you have a workflow that's required to pass.
|
||||
|
||||
```yaml
|
||||
name: ci
|
||||
on:
|
||||
pull_request:
|
||||
paths:
|
||||
- 'scripts/**'
|
||||
- 'middleware/**'
|
||||
jobs:
|
||||
build:
|
||||
runs-on: ubuntu-latest
|
||||
strategy:
|
||||
matrix:
|
||||
node-version: [12.x, 14.x, 16.x]
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Use Node.js ${{ matrix.node-version }}
|
||||
uses: actions/setup-node@v2
|
||||
with:
|
||||
node-version: ${{ matrix.node-version }}
|
||||
cache: 'npm'
|
||||
- run: npm ci
|
||||
- run: npm run build --if-present
|
||||
- run: npm test
|
||||
```
|
||||
|
||||
If someone submits a pull request that changes a markdown file in the root of the repository, then the workflow above won't run at all because of the path filtering. As a result you won't be able to merge the pull request. You would see the following status on the pull request:
|
||||
|
||||

|
||||
|
||||
You can fix this by creating a generic workflow, with the same name, that will return true in any case similar to the workflow below :
|
||||
|
||||
```yaml
|
||||
name: ci
|
||||
on:
|
||||
pull_request:
|
||||
paths-ignore:
|
||||
- 'scripts/**'
|
||||
- 'middleware/**'
|
||||
jobs:
|
||||
build:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- run: 'echo "No build required" '
|
||||
```
|
||||
Now the checks will always pass whenever someone sends a pull request that doesn't change the files listed under `paths` in the first workflow.
|
||||
|
||||

|
||||
|
||||
{% note %}
|
||||
|
||||
**Notes:**
|
||||
* Make sure that the `name` key and required job name in both the workflow files are the same. For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions)".
|
||||
* The example above uses {% data variables.product.prodname_actions %} but this workaround is also applicable to other CI/CD providers that integrate with {% data variables.product.company_short %}.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
It's also possible for a protected branch to require a status check from a specific {% data variables.product.prodname_github_app %}. If you see a message similar to the following, then you should verify that the check listed in the merge box was set by the expected app.
|
||||
|
||||
```
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:312f9971ce304c17fabed98ec5fe6ea231b9af1b5618a07ed30a8e7fdcec48d0
|
||||
size 640821
|
||||
oid sha256:4049476895fb239bc51e71ebd336338d41529afc67d2098dce429533dc003237
|
||||
size 641041
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:b3835dc9c8140372dc9045ad9a5b65a4d3ab9a4ca89c18643892afaafce8c21f
|
||||
size 1111873
|
||||
oid sha256:b0b2a1a218d1543eb344ae20b572c55b3e95859c5f6418dca4f7738ea730489c
|
||||
size 1111649
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:384a7ed16c410f489779f70b2e69702f7482d9d3ffde8626a00a5a39082fd7d2
|
||||
size 944980
|
||||
oid sha256:7166c39064400d935ff68fd4194d024349115b4015d7584f63a14e571b80f113
|
||||
size 944974
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:cae7b3fb01ed59695e3e1322be91d83453625f9c57667e3caef9ecd2a735140f
|
||||
size 3858956
|
||||
oid sha256:2ab881358f1b65eafb4780c410dc4cd0252cd02171e3faf47c0d8938e930bbfa
|
||||
size 3858188
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:fc98437370002d04c07d69fd3a99834d900c5e555a1c6782fbc4dfb26b0a92fa
|
||||
size 584575
|
||||
oid sha256:2f88d199c16319f387dc7befa2247fdf161a1ff43c149ecb1474f68da324a301
|
||||
size 584420
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:2ce5fdd6b8cd82ef10743d1c7d0551758b57986b5fe0f2d708c2a0fb6a62792f
|
||||
size 2455136
|
||||
oid sha256:2034c5b57c8f2fa0e1c49c827a213b0472109bff6cdf11067bf58912b0698e6a
|
||||
size 2455540
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:2e45159d105ce71bb139d44ab971bb4dfd76f02550856673bf4e07f47e3e9a89
|
||||
size 666696
|
||||
oid sha256:995025c3a0e1fdda18833647304d9eae5b457f3858a8dffa41b47424105b94e1
|
||||
size 666491
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:c9af740b2815a98c8e352e150e5f36b0fceae3a467fc996063bd976597941090
|
||||
size 3450805
|
||||
oid sha256:a0a5ee449971aad8ba85fb09e59062fee537eaea68340681c2966fb4f41752df
|
||||
size 3450524
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:5fc42443ad297bc3c5e7baddf86dac7f1355a77afeeeee85f2716881983d23c3
|
||||
size 545027
|
||||
oid sha256:ea29db113ce85355e408b98557371bd7a31d53f4762a12a5c21e39fc9f305aca
|
||||
size 544965
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:bc440897e70f394816adb45a68b9adde2305a0e1e66311d32ce7da91c8e7c5d4
|
||||
size 2232351
|
||||
oid sha256:84c39d3b1c41752c800066cb8a5edcb17958c47a285c55e4ce04640babb70294
|
||||
size 2233851
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:51097caa0ccaabcc951d15aa50118d1bb0e606af941d378b59fd9f8f5a286826
|
||||
size 655384
|
||||
oid sha256:4cb5ad2c1880cfa82c66379bd78ecb662809dd42df225f42c2ef5fa1a56a3932
|
||||
size 655625
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:a6ce6d74da9662716ba13b02ff08fe80b01b50bae5866482d2afecb519491424
|
||||
size 1144465
|
||||
oid sha256:aaaaa5076b294583fae46c0e057558041cb0d804800dc9f18c604f8cabbc02c6
|
||||
size 1144090
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:5c50b1d1384f2fe99783e031c9d7bdbaa93f3150f5b7f8d59cecf9340fb769a1
|
||||
size 969920
|
||||
oid sha256:2a8af3d531106d3f834ec517068786b91dd52cb9caf1c2fb8d06acf50c1d4643
|
||||
size 970024
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:b2fceca3128975c9b488348d9699aa7dd077a0726921963ad7a4636f9717c645
|
||||
size 3949850
|
||||
oid sha256:a52ee2080910250bde000300baf084993d065171a5591f2b369bf867f31f7bae
|
||||
size 3951668
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:11a3620eaed7ab1cf5e7b38c517de84d8517aed8fdbc187d4f75c1e771a0ec1b
|
||||
size 596965
|
||||
oid sha256:241912f2b98df27791f1aae857b74571e7ef08fb9b745b10ec8ea61f61dc20dd
|
||||
size 597228
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:5692635359801f327b3609f624f0307e0cd91b533d4d25025700607e74f8dcd0
|
||||
size 2514102
|
||||
oid sha256:23d4b5c4f3ed1c7ec69d038c5ca55fd5886d9baf932c00699ccfa995d4595e90
|
||||
size 2514879
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:3c07d6c9c6e53ad4982413f9931f49c47d5d7929a1cb96ece405ed2894d99a8f
|
||||
size 681373
|
||||
oid sha256:e520026797499331e24221d53fd73c24fcf935225aeb4c548613b366748adfc4
|
||||
size 681223
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:b63341b97585188e25dc7af60423bb1012b6ea22eb7ae129b4a1c078d7cbfa76
|
||||
size 3533364
|
||||
oid sha256:77a9b49b1b495ffd78c382b9325ad5d58d819577c4ab14533861826f476de0f6
|
||||
size 3533386
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:5c0fac5b7f94e08fc89e7de7e432e251e9751bfaf4e0dd99c0404821f71237da
|
||||
size 557270
|
||||
oid sha256:264928ca75f4ac57c795299d25af5ca67d9240baa9918377831f552c33e3eda7
|
||||
size 557069
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:0cd787a89d8ace7358a36f03977b07477fc8d19b601c860b44ecc8f200aa530a
|
||||
size 2287426
|
||||
oid sha256:67aad2a80ed7724c9f58a7daf685a33abbefd97f9f0c2ec21529db1eb1d5a649
|
||||
size 2289490
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:c219f6a4f3a1096f22b4d9be2b245518f487348e7e1289f4b7d5b0eb038c9717
|
||||
size 668715
|
||||
oid sha256:4f2aa508681440af8d93fc5b4f10ef5753627be6f80c1c2c08b89c35c40e11b0
|
||||
size 668718
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:3e9463d511b34a68a6361781a1b81b245a488fd712924d09c11826da73945924
|
||||
size 1168823
|
||||
oid sha256:4d832c1719ed684a7f5b35953d50d7250a5938c021c7829989e5e0393160b908
|
||||
size 1169094
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:fbe875c5976cc05852eeedab3af3d82e3f1bc0a95d9e0e417e44dc8d29f89bb9
|
||||
size 1000462
|
||||
oid sha256:c60fd8d5dce9adf6c582b098427b9509ee3dbf5241d4310ca7fc94ae7fc88483
|
||||
size 1000821
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:40a690852c9426fc0fd24e6a1b682e5a08d24767aac8881645788701c53d37c7
|
||||
size 4070365
|
||||
oid sha256:ac61b65215de8922fe562b8bd49306d518d11e52c5807b166386716194a67295
|
||||
size 4070323
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:154838f24eb51ab51c46c514fa17795da1a5e145c4490a8c3cb617a27c790960
|
||||
size 608178
|
||||
oid sha256:f62f8658e0c0c2b0495a1a39bfd342e9159a5653d3e384942b7af8b9971b7ab5
|
||||
size 608258
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:e1a35fabd98f0a8adcc255fc08d05ed60c93ddd19f082569765273f86edaf4aa
|
||||
size 2565158
|
||||
oid sha256:0871545c7f18518daa953bcba6292e5637272ffce62b9bcd681f21688d87fde6
|
||||
size 2565982
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:05466b66b077829f6a9f00645f53db72ef6712145892e1e64ab3e603c82ab568
|
||||
size 693778
|
||||
oid sha256:522045dfc163bf0c1c07650b75fec174dc9e51f0171e46a07d4b9a06d91192db
|
||||
size 693703
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:281b184c3e3346141d18089106b0ab86bc099575f2337e42bbfe1696cc930830
|
||||
size 3605084
|
||||
oid sha256:fd516842b0faff9a784672ae5e3a6b73401d0322260275f0ccb235065bc17b34
|
||||
size 3605119
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:5e22cef029b6dbd04ea2c4f752811f4aa464af0962f8a74cbf10230988abf2d0
|
||||
size 567438
|
||||
oid sha256:e59ad385a800b9a365266e860ccdeae0821ee015aa70c556cbbb7d14119b47c1
|
||||
size 567333
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:18a51e8a5cd3b95444f34e0df14ea4a569ffaac68af01856ba24ece494b9fc8a
|
||||
size 2330741
|
||||
oid sha256:0ef9cf8810cb83d8c70bd329adf8dd6ba7c9524de2a90a1e3390b958b5fa4a37
|
||||
size 2331617
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:6484d5951216b1520fb7e3b7a373aa2fa5c3ec0d6ff53b69c13ac45ddd6dc36d
|
||||
size 691520
|
||||
oid sha256:83d0f55f34c14378cfc55869db81d610e4e82ec44c6e3654a39735f0c69fcef6
|
||||
size 691539
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:6b2aab7d7354143c8caca39cb084d30d4f5416a625d661cd0dcfb18a8c2153f5
|
||||
size 1226846
|
||||
oid sha256:55918d08e38df87aab5502ae5389233815f720405e90f3d876f7d27fdd47722e
|
||||
size 1226449
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:d6fc73e2547748d05c62ea0dad62151e2bc684b7db4f9a5c2c36dfd2492495f5
|
||||
size 1034166
|
||||
oid sha256:14f9c12a3c7ad88c0bf99ac93153af53cb0464b863c78a624064e3c580c4efb2
|
||||
size 1034557
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:32cca1160ea6dadf8e1e5af353bcb15f04b5395232c4a8cc41844d14110b92e6
|
||||
size 4166793
|
||||
oid sha256:fa363ef21cf719ecef4ba4b13ecf2f6c642fbc4aebdc086640f766c89c5ec171
|
||||
size 4166266
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:d78d0c9aa44aeed0c3b32a3b4ad2807406dac27a3cca0db305b832e992b4cff6
|
||||
size 626696
|
||||
oid sha256:e20a7f3795818920308100b30595796c4c170eba4c62680f4b70d577a3be3765
|
||||
size 626610
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:63719612ca4fb18d17f6952892293c20c7dccca63ad479abc483ba9f607913f6
|
||||
size 2667106
|
||||
oid sha256:1f9a60b978506e84f321d83607e682bfb86fcbeaea57d74325fb8b16efa0bb8c
|
||||
size 2665818
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:d9562f4792047d624ac2e46b5f15bf06b7468958a872d557fd86c2e4627677e0
|
||||
size 716444
|
||||
oid sha256:d307f62694f67f388457f9cd9c9c8b81256dfe1d22c0b7eed1a6a3d5f25030d9
|
||||
size 716392
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:74afa6791aa9db1e094a75498bc8fc9d179b4e961d897511c09c7c5c5451fcff
|
||||
size 3733074
|
||||
oid sha256:b5bd3ae3940aac2a77a39e70e80c63d32c6a014466ac15a0df3be62a0cc152e8
|
||||
size 3733744
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:d1674ddfa56271c0450ddede38334863f433650520b4ba5240fb88a7d4f28461
|
||||
size 585859
|
||||
oid sha256:6a96cdb2a0f76e6e2d02006795d695e6fa54b98d883bfc0926fafbd18fd7fba3
|
||||
size 585848
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:737f2e58ee889820623aa23bf21104f89e2d5039b8c2a56c4e6d016d0b7ba266
|
||||
size 2412152
|
||||
oid sha256:34f9a77a145aded15cfbf0f4bd7ea996e170f89f8111f7524abca045b63ed390
|
||||
size 2415923
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:b03f55b6566106fa57c0a7d29dcb6177a003baaf8aaae837089a62e5f0e31ec5
|
||||
size 903800
|
||||
oid sha256:fd0f19fbb1a0fe94594749382b08227d0720c7fd26f90c1451f567a2b5864968
|
||||
size 903714
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:4f112d05702a73104d3ea03241968072791986348989917b9bf7fa04a1960e71
|
||||
size 1446493
|
||||
oid sha256:70d146912a0976fadf6880d4839bcd4a0801703a8584f8599eada139b41911cd
|
||||
size 1446676
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:bc4a9b188f8ccd08c1a616d8dfb6bb91aca6ce989930d1126d3283c819c948fc
|
||||
size 1327718
|
||||
oid sha256:ee29a9792b9205015d2e476f547546ddb99228bef87ff7e2c2a7cfccac455fcf
|
||||
size 1328029
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:cfa123c25451468eef5b399c7dc318498c8d85b7cfe2ae7e0ff53fc6e8f3dc3c
|
||||
size 5058345
|
||||
oid sha256:251d45bfc7553c51b6b065b102d41a6122bd6590d3ce39d858953658354d2d46
|
||||
size 5057097
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:0c30d67559aee72890b5440860441e1648fca3f26d2cc85baf03d537aa0fce44
|
||||
size 807385
|
||||
oid sha256:1a51cbbeb667b81bcbf3df02c1de62690586cd66d9bda264634b679f1542bc8c
|
||||
size 804554
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:43708c63799fa3e0aeafb783cb748cafbb89273499da598defd612dfdb73b654
|
||||
size 3278355
|
||||
oid sha256:ef1843d8e80f292d84b8944d605965a12ce952701213691ab188cc8ac486e83c
|
||||
size 3257274
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:35d161e9e6f2ffc0c5583f5e4a3356c3bacd2dc3ed7700702adc8a61412847d3
|
||||
size 929875
|
||||
oid sha256:fc3d32dca890327d675fd37e55f5cfbffd0733ed654815dd2f45bc9edbd81584
|
||||
size 929964
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:76abf48f01d3d5a0f88997f0c420b6ed0e17400e336ca3ae4ff04f88b8401bfe
|
||||
size 4682563
|
||||
oid sha256:c1ffbb4c18a7620c87b401b25ef7ed0327b4238c9ab3e8456400a25ba29972d9
|
||||
size 4684151
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:c180ab3c627d28ebc7c3e2b49f9722d7dfff5237fd716b90745ce21ccea1fc9f
|
||||
size 767682
|
||||
oid sha256:b7c54cb25b72eae9f4ee1f47191ed603eb8e9f349f2faae85fb9fce5092f58bd
|
||||
size 767565
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:0360443a4c2514323f4358323ded24cb95bd43e1a0ef50479c91bcc2c96355fb
|
||||
size 3033440
|
||||
oid sha256:cc01b486d49a5b787a57371687c20ba33885ec7c721bf12442357e112fb38eef
|
||||
size 3040552
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:e66572cec381830f2d97c5c54be8c4cf3d231a65e31393eec98aef4ce5f48706
|
||||
size 518835
|
||||
oid sha256:c0ccfacb0470c2d3bada0d1780e49b508ab0b4b80f11f15e6b043ab10b427bff
|
||||
size 518860
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:abcdc7e71552fa43d4d910823f1668c0e411ece814da9093455e2d1e4a8d4dc2
|
||||
size 879714
|
||||
oid sha256:ef23b630e10b8714b0efa9af50c8084dbc4c338111ab377e7878dbd5ecab5028
|
||||
size 880326
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:8a5140da0a52ea53b07d8adf579dbcb21cdb6d5d3aaf99472ca441fd70dc2cdf
|
||||
size 801141
|
||||
oid sha256:8958acc20c35b5347bd5aaefd6423fb7bde1991e1e7daaab1b0dab4e5f132795
|
||||
size 801401
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:f47e4e94a3b4ef4779881a2185f4d36fa357aa9d72dc5ff406cefb42e81d2925
|
||||
size 3215769
|
||||
oid sha256:209be38a3e7f71bbca95b88cfbc018f57d6ee6d4eda3cc1a050e73f86a5061de
|
||||
size 3214584
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:d2b9322db7bbfa9a99f52407f01a3356e3640475284ab1561b91329d55644ce3
|
||||
size 473621
|
||||
oid sha256:ce52fdbe18a6f0ad892c34ac05c1c53462c4a6f377c4141fba4b59145aa7f22c
|
||||
size 473569
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:6dfae8363077eaf286c2bd2997fe11fce060d3002955aa62f9c70b157932cf33
|
||||
size 1924951
|
||||
oid sha256:0148640cccc9c0a279c753009b9dcfe99b0a04684b0ff0c22617367d3975c8c5
|
||||
size 1924896
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:2e493b470a008339c0e3517d84ff1eae689dc4fe8d4fd00490bd234ceffcf13b
|
||||
size 539413
|
||||
oid sha256:2f99cd290b8b9015551e095e883cdb8375a258a4ae7e6d1309f3b589e43b3d63
|
||||
size 539340
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:5102681e6fd0b4b0ef1a4622c3ad2ee379b1e4ed93ecde2227366a9512fc7ed4
|
||||
size 2695435
|
||||
oid sha256:bd4877cc043e5a4317063118d2ac4c5ef6f1cff4ac4360d197d4be7926e9034e
|
||||
size 2696219
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:36da56c89db0178a013911c8d6da8c7dc200ccba509132e60c30f29b9450faa8
|
||||
size 442128
|
||||
oid sha256:729daf37f30f609328ed5062ae84a20303fb36679d54a7342ca05e8afd10d3e7
|
||||
size 441730
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:4d7fcafa911778e48d40179f651b18168b8a50e5f1a842f910312077f8045c0b
|
||||
size 1751362
|
||||
oid sha256:2822461d4e9f0bd3a7e6091c4236e29dd44bff3c1811af1c4897e205ea0bb2da
|
||||
size 1753555
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:476353cde8e2d159c387a88ff2b6db8deb944bcbcd4b7b264e5cf8dcd5af5e73
|
||||
size 801587
|
||||
oid sha256:6ad550fccae88cd6439678ccbe7493b8b7b25b928bf65fbc41f170cff7e220fd
|
||||
size 801555
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:cd5bc585efe2fda36f15769ea324faef7582b5560c09740bef52589ac2613a4f
|
||||
size 1447304
|
||||
oid sha256:4da3dd920cca01a205f80fcd173caeae7a3bb73f707a44a688e22381350710ed
|
||||
size 1447663
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:e440b04fbe6551e26bb0f19416840f37176aeba2bab4441bb1f4bb4b02b65f89
|
||||
size 1175696
|
||||
oid sha256:d6fb971d6435dd6ea697a30c977a641794f583d3f9f77824f80c2cf08667c7bb
|
||||
size 1175104
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:cee06c3205e5188beb1a77973e860909a8c5ef250990f3147a0a043b6fa4ec5a
|
||||
size 4730777
|
||||
oid sha256:964a4e2594a2f525069a529c8ba2915a3fcc51fb91b742a3d3216c70f3f4844d
|
||||
size 4727788
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:36f35483dcaa4c9dcbbe4636ffec87d73203c34e2e4fe043e75e26229285184b
|
||||
size 739136
|
||||
oid sha256:929ae4b019083381064094638d0458e7ed101319829f9951ae72f7b2f8509e48
|
||||
size 736375
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:71b31f1d64eb6352db70e846e4a84eeb9ec1dde4c40236cdc950dd2079f5db86
|
||||
size 3153950
|
||||
oid sha256:a0ce99de2b32d50d67ad42474530816cd0c9f87a8e4ad1fd4bd0964d4e6b9ae3
|
||||
size 3133761
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:dae76b12659557027af2a36ca624fd8bf8422096ad9f3025bce6da1e6f3f50fb
|
||||
size 831511
|
||||
oid sha256:4c6b06174df3b0eefe24f5254333a7370d3b724b4ffbee108ee4477cfd3a3606
|
||||
size 831633
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:62c290763dee493c1df8a81d28ea5e13c78fbf0149bee791a8d2264101ac6d3b
|
||||
size 4393341
|
||||
oid sha256:84ac8f110a88e55f4f4f6b0c2964c34d2766a446d0eeed7156caa9727cbe6d62
|
||||
size 4394083
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:1be4120b6d9a08c750cf0066d34d67830a539d2ba0dbd005cc44c43888943501
|
||||
size 706896
|
||||
oid sha256:f9e2c76af3bf9296b6ab7230ef2205a1598edde4984e836a2b0ec299c32afe44
|
||||
size 706733
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:28cc5265ab9c2efe95f48460d6ea90e8a8b10b08815f6bf8263ddc7f01aecd4e
|
||||
size 2937885
|
||||
oid sha256:d8b89cc136a3e40a481cd893478401ab7d744e6cac46652e82bce6d6254c2404
|
||||
size 2943592
|
||||
|
||||
@@ -18,12 +18,6 @@ topics:
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** Reusable workflows are currently in beta and subject to change.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
## About reusable workflows
|
||||
|
||||
Rather than copying and pasting deployment jobs from one workflow to another, you can create a reusable workflow that performs the deployment steps. A reusable workflow can be used by another workflow if it meets one of the access requirements described in "[Reusing workflows](/actions/learn-github-actions/reusing-workflows#access-to-reusable-workflows)."
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
---
|
||||
title: Reutilizar flujos de trabajo
|
||||
shortTitle: Reutilizar flujos de trabajo
|
||||
intro: Aprende cómo evitar la duplicación al crear un flujo de trabajo reusando los flujos existentes.
|
||||
title: Reusing workflows
|
||||
shortTitle: Reusing workflows
|
||||
intro: Learn how to avoid duplication when creating a workflow by reusing existing workflows.
|
||||
miniTocMaxHeadingLevel: 3
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '>=3.4'
|
||||
ghae: issue-4757
|
||||
ghec: '*'
|
||||
type: how_to
|
||||
topics:
|
||||
- Workflows
|
||||
@@ -17,77 +17,120 @@ topics:
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
{% data reusables.actions.ae-beta %}
|
||||
|
||||
{% note %}
|
||||
## Overview
|
||||
|
||||
**Nota:** Los flujos de trabajo reutilizables se encuentran actualmente en beta y están sujetos a cambios.
|
||||
Rather than copying and pasting from one workflow to another, you can make workflows reusable. You and anyone with access to the reusable workflow can then call the reusable workflow from another workflow.
|
||||
|
||||
{% endnote %}
|
||||
Reusing workflows avoids duplication. This makes workflows easier to maintain and allows you to create new workflows more quickly by building on the work of others, just as you do with actions. Workflow reuse also promotes best practice by helping you to use workflows that are well designed, have already been tested, and have been proved to be effective. Your organization can build up a library of reusable workflows that can be centrally maintained.
|
||||
|
||||
## Resumen
|
||||
The diagram below shows three build jobs on the left of the diagram. After each of these jobs completes successfully a dependent job called "Deploy" runs. This job calls a reusable workflow that contains three jobs: "Staging", "Review", and "Production." The "Production" deployment job only runs after the "Staging" job has completed successfully. Using a reusable workflow to run deployment jobs allows you to run those jobs for each build without duplicating code in workflows.
|
||||
|
||||
En vez de copiar y pegar desde un flujo de trabajo hacia otro, puedes hacer flujos de trabajo reutilizables. Tú y cualquiera que tenga acceso a un flujo de trabajo reutilizable pueden entonces llamarlo desde otro flujo.
|
||||

|
||||
|
||||
El reutilizar flujos de trabajo evita la duplicación. Esto hace que los flujos de trabajo se puedan mantener más fácilmente y te permite crear flujos de trabajo nuevos más fácilmente compilando sobre el trabajo de los demás, tal como lo haces con las acciones. La reutilización de flujos de trabajo también promueve las mejores prácticas al ayudarte a utilizar los flujos de trabajo que están bien diseñados, que ya se han probado y cuya efectividad ya se comprobó. Tu organización puede crear una librería de flujos de trabajo reutilizables que puede mantenerse centralmente.
|
||||
A workflow that uses another workflow is referred to as a "caller" workflow. The reusable workflow is a "called" workflow. One caller workflow can use multiple called workflows. Each called workflow is referenced in a single line. The result is that the caller workflow file may contain just a few lines of YAML, but may perform a large number of tasks when it's run. When you reuse a workflow, the entire called workflow is used, just as if it was part of the caller workflow.
|
||||
|
||||
A un flujo de trabajo que utiliza otro flujo de trabajo se le llama flujo de trabajo "llamante". El flujo de trabajo reutilizable es un flujo "llamado". Un flujo de trabajo llamante puede utilizar varios flujos de trabajo llamados. Cada flujo de trabajo llamado se referencia en una línea simple. El resultado es que el archivo de flujo de trabajo llamante podrá contener solo unas cuantas líneas de YAML, pero podría realizar una cantidad grande de tareas cuando se ejecute. Cuando reutilizas un flujo de trabajo, se utiliza todo el flujo de trabajo llamado justo como si fuera parte del flujo de trabajo llamante.
|
||||
If you reuse a workflow from a different repository, any actions in the called workflow run as if they were part of the caller workflow. For example, if the called workflow uses `actions/checkout`, the action checks out the contents of the repository that hosts the caller workflow, not the called workflow.
|
||||
|
||||
Si utilizas un flujo de trabajo desde un repositorio diferente, cualquier acción en el flujo de trabajo llamado se ejecutará como si fuera parte del llamante. Por ejemplo, si el flujo de trabajo llamado utiliza `actions/checkout`, la acción verifica el contenido del repositorio que hospeda el flujo de trabajo llamante y no el llamado.
|
||||
When a reusable workflow is triggered by a caller workflow, the `github` context is always associated with the caller workflow. The called workflow is automatically granted access to `github.token` and `secrets.GITHUB_TOKEN`. For more information about the `github` context, see "[Context and expression syntax for GitHub Actions](/actions/reference/context-and-expression-syntax-for-github-actions#github-context)."
|
||||
|
||||
Cuando un flujo de trabajo llamante activa uno reutilizable, el contexto `github` siempre se asocia con el flujo llamante. The called workflow is automatically granted access to `github.token` and `secrets.GITHUB_TOKEN`. Para obtener más información sobre el contexto `github`, consulta la sección "[Sintaxis de contexto y expresión para GitHub Actions](/actions/reference/context-and-expression-syntax-for-github-actions#github-context)".
|
||||
### Reusable workflows and workflow templates
|
||||
|
||||
## Acceso a los flujos de trabajo reutilizables
|
||||
Workflow templates allow everyone in your organization who has permission to create workflows to do so more quickly and easily. When people create a new workflow, they can choose a template and some or all of the work of writing the workflow will be done for them. Inside workflow templates, you can also reference reusable workflows to make it easy for people to benefit from reusing centrally managed workflow code. If you use a tag or branch name when referencing the reusable workflow then you can ensure that everyone who reuses that workflow will always be using the same YAML code. However, if you reference a reusable workflow by a tag or branch, be sure that you can trust that version of the workflow. For more information, see "[Security hardening for {% data variables.product.prodname_actions %}](/actions/security-guides/security-hardening-for-github-actions#reusing-third-party-workflows)."
|
||||
|
||||
Otros flujos de trabajo pueden usar uno reutilizable si cualquiera de los siguientes casos es cierto:
|
||||
For more information, see "[Creating workflow templates](/actions/learn-github-actions/creating-workflow-templates)."
|
||||
|
||||
* Ambos flujos de trabajo están en el mismo repositorio.
|
||||
* El flujo de trabajo llamado se almacena en un repositorio público.
|
||||
* El flujo de trabajo llamado se almacena en un repositorio interno y los ajustes de dicho repositorio permiten que se acceda a él. Para obtener más información, consulta la sección "[Administrar la configuración de {% data variables.product.prodname_actions %} en un repositorio](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-an-internal-repository)".
|
||||
## Access to reusable workflows
|
||||
|
||||
## Limitaciones
|
||||
A reusable workflow can be used by another workflow if {% ifversion ghes or ghec or ghae %}any{% else %}either{% endif %} of the following is true:
|
||||
|
||||
* Los flujos de trabajo reutilizables no pueden llamar a otros que también sean reutilizables.
|
||||
* Los flujos de trabajo solo podrán usar a los reutilizables que se encuentren almacenados en un repositorio privado en caso de que estos también se encuentren en el mismo repositorio.
|
||||
* Ninguna variable de ambiente que se configure en un contexto de `env` que se defina a nivel del flujo de trabajo en aquél llamante se propagará al flujo llamado. Para obtener más información sobre el contexto `env`, consulta la sección "[Sintaxis de contexto y expresión para GitHub Actions](/actions/reference/context-and-expression-syntax-for-github-actions#env-context)".
|
||||
* Both workflows are in the same repository.
|
||||
* The called workflow is stored in a public repository.{% ifversion ghes or ghec or ghae %}
|
||||
* The called workflow is stored in an internal repository and the settings for that repository allow it to be accessed. For more information, see "[Managing {% data variables.product.prodname_actions %} settings for a repository](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-an-internal-repository)."{% endif %}
|
||||
|
||||
Se eliminarán las siguientes limitaciones cuando la reutilización del flujo de trabajo salga del beta:
|
||||
* No puedes configurar la concurrencia de un flujo de trabajo llamado desde el flujo llamante. Para obtener más información sobre `jobs.<job_id>.concurrency`, consulta la sección "[Sintaxis de flujo de trabajo para las GitHub Actions](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idconcurrency)".
|
||||
* El flujo de trabajo llamante no puede acceder a las salidas que genera un flujo de trabajo llamado.
|
||||
## Using runners
|
||||
|
||||
## Crear un flujo de trabajo reutilizable
|
||||
### Using GitHub-hosted runners
|
||||
|
||||
Los flujos de trabajo reutilizables son archivos con formato YAML, muy similares a cualquier otro archivo de flujo de trabajo. Tal como con otros flujos de trabajo, puedes ubicar los reutilizables en el directorio `.github/workflows` de un repositorio. Los subdirectorios del directorio `workflows` no son compatibles.
|
||||
{% ifversion fpt or ghes or ghec %}
|
||||
The assignment of {% data variables.product.prodname_dotcom %}-hosted runners is always evaluated using only the caller's context. Billing for {% data variables.product.prodname_dotcom %}-hosted runners is always associated with the caller. The caller workflow cannot use {% data variables.product.prodname_dotcom %}-hosted runners from the called repository. For more information, see "[About {% data variables.product.prodname_dotcom %}-hosted runners](/actions/using-github-hosted-runners/about-github-hosted-runners)."
|
||||
{% endif %}
|
||||
{% ifversion ghae %}
|
||||
The assignment of {% data variables.actions.hosted_runner %}s is always evaluated using only the caller's context. Billing for {% data variables.actions.hosted_runner %}s is always associated with the caller. The caller cannot use {% data variables.actions.hosted_runner %}s from the called repository. For more information, see "[About {% data variables.actions.hosted_runner %}s](/github-ae@latest/actions/using-github-hosted-runners/about-ae-hosted-runners)."
|
||||
{% endif %}
|
||||
|
||||
Para que un flujo de trabajo sea reutilizable, los valores de `on` deben incluir `workflow_call`:
|
||||
### Using self-hosted runners
|
||||
|
||||
Called workflows can access self-hosted runners from caller's context. This means that a called workflow can access self-hosted runners that are:
|
||||
* In the caller repository
|
||||
* In the caller repository's organization{% ifversion ghes or ghec or ghae %} or enterprise{% endif %}, provided that the runner has been made available to the caller repository
|
||||
|
||||
## Limitations
|
||||
|
||||
* Reusable workflows can't call other reusable workflows.
|
||||
* Reusable workflows stored within a private repository can only be used by workflows within the same repository.
|
||||
* Any environment variables set in an `env` context defined at the workflow level in the caller workflow are not propagated to the called workflow. For more information about the `env` context, see "[Context and expression syntax for GitHub Actions](/actions/reference/context-and-expression-syntax-for-github-actions#env-context)."
|
||||
* You can't set the concurrency of a called workflow from the caller workflow. For more information about `jobs.<job_id>.concurrency`, see "[Workflow syntax for GitHub Actions](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idconcurrency)."
|
||||
|
||||
## Creating a reusable workflow
|
||||
|
||||
Reusable workflows are YAML-formatted files, very similar to any other workflow file. As with other workflow files, you locate reusable workflows in the `.github/workflows` directory of a repository. Subdirectories of the `workflows` directory are not supported.
|
||||
|
||||
For a workflow to be reusable, the values for `on` must include `workflow_call`:
|
||||
|
||||
```yaml
|
||||
on:
|
||||
workflow_call:
|
||||
```
|
||||
|
||||
Puedes definir entradas y secretos, las cuales pueden pasarse desde el flujo de trabajo llamante y luego utilizarse dentro del flujo llamado. El siguiente ejemplo, desde un flujo de trabajo reutilizable, define dos entradas (llamadas "ring" y "environment") y un secreto (llamado "token"):
|
||||
### Using inputs and secrets in a reusable workflow
|
||||
|
||||
```yaml
|
||||
on:
|
||||
workflow_call:
|
||||
inputs:
|
||||
ring:
|
||||
description: 'Identifier for the target deployment ring'
|
||||
default: 'ring-0'
|
||||
required: false
|
||||
type: string
|
||||
environment:
|
||||
required: false
|
||||
type: string
|
||||
secrets:
|
||||
token:
|
||||
required: false
|
||||
```
|
||||
You can define inputs and secrets, which can be passed from the caller workflow and then used within the called workflow. There are three stages to using an input or a secret in a reusable workflow.
|
||||
|
||||
Para encontrar los detalles de la sintaxis para definir entradas y secretos, consulta [on.workflow_call.inputs](/actions/reference/workflow-syntax-for-github-actions#onworkflow_callinputs) y [on.workflow_call.secrets](/actions/reference/workflow-syntax-for-github-actions#onworkflow_callsecrets).
|
||||
1. In the reusable workflow, use the `inputs` and `secrets` keywords to define inputs or secrets that will be passed from a caller workflow.
|
||||
{% raw %}
|
||||
```yaml
|
||||
on:
|
||||
workflow_call:
|
||||
inputs:
|
||||
username:
|
||||
required: true
|
||||
type: string
|
||||
secrets:
|
||||
envPAT:
|
||||
required: true
|
||||
```
|
||||
{% endraw %}
|
||||
For details of the syntax for defining inputs and secrets, see [`on.workflow_call.inputs`](/actions/reference/workflow-syntax-for-github-actions#onworkflow_callinputs) and [`on.workflow_call.secrets`](/actions/reference/workflow-syntax-for-github-actions#onworkflow_callsecrets).
|
||||
1. Reference the input or secret in the reusable workflow.
|
||||
|
||||
### Flujo de trabajo reutilizable de ejemplo
|
||||
{% raw %}
|
||||
```yaml
|
||||
jobs:
|
||||
reusable_workflow_job:
|
||||
runs-on: ubuntu-latest
|
||||
environment: production
|
||||
steps:
|
||||
- uses: ./.github/actions/my-action@v1
|
||||
with:
|
||||
username: ${{ inputs.username }}
|
||||
token: ${{ secrets.envPAT }}
|
||||
```
|
||||
{% endraw %}
|
||||
In the example above, `envPAT` is an environment secret that's been added to the `production` environment. This environment is therefore referenced within the job.
|
||||
|
||||
Este archivo de flujo de trabajo reutilizable llamado `workflow-B.yml` (nos referiremos a él más adelante) toma una secuencia de entrada y un secreto del flujo llamante y lo utiliza en una acción.
|
||||
{% note %}
|
||||
|
||||
**Note**: Environment secrets are encrypted strings that are stored in an environment that you've defined for a repository. Environment secrets are only available to workflow jobs that reference the appropriate environment. For more information, see "[Using environments for deployment](/actions/deployment/targeting-different-environments/using-environments-for-deployment#environment-secrets)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
1. Pass the input or secret from the caller workflow.
|
||||
|
||||
{% indented_data_reference reusables.actions.pass-inputs-to-reusable-workflows spaces=3 %}
|
||||
|
||||
### Example reusable workflow
|
||||
|
||||
This reusable workflow file named `workflow-B.yml` (we'll refer to this later in the [example caller workflow](#example-caller-workflow)) takes an input string and a secret from the caller workflow and uses them in an action.
|
||||
|
||||
{% raw %}
|
||||
```yaml{:copy}
|
||||
@@ -115,36 +158,27 @@ jobs:
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
## Llamar a un flujo de trabajo reutilizable
|
||||
## Calling a reusable workflow
|
||||
|
||||
Se llama a un flujo de trabajo reutilizable utilizando la palabra clave `uses`. A diferencia de cuando utilizas acciones en un flujo de trabajo, los flujos de trabajo reutilizables se llaman directamente desde un job y no dentro de los pasos de un job.
|
||||
You call a reusable workflow by using the `uses` keyword. Unlike when you are using actions within a workflow, you call reusable workflows directly within a job, and not from within job steps.
|
||||
|
||||
[`jobs.<job_id>.uses`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_iduses)
|
||||
|
||||
Se referencian los archivos de flujo de trabajo reutilizables utilizando la sintaxis:
|
||||
You reference reusable workflow files using the syntax:
|
||||
|
||||
`{owner}/{repo}/{path}/{filename}@{ref}`
|
||||
|
||||
Puedes llamar a flujos de trabajo múltiples, referenciando cada uno en un job separado.
|
||||
You can call multiple workflows, referencing each in a separate job.
|
||||
|
||||
{% data reusables.actions.uses-keyword-example %}
|
||||
|
||||
### Pasar entradas y secretos a un flujo de trabajo reutilizable
|
||||
### Passing inputs and secrets to a reusable workflow
|
||||
|
||||
Utiliza la palabra clave `with` para pasar entradas nombradas al flujo de trabajo llamado. Utiliza la palabra clave `secrets` para pasar los secretos nombrados. Las entradas y secretos que pases deben definirse en el flujo de trabajo llamado. Para las entradas, el tipo de datos del valor de estas debe coincidir con el tipo que se especifica para ellas en el flujo de trabajo llamado (booleano, número o secuencia).
|
||||
{% data reusables.actions.pass-inputs-to-reusable-workflows%}
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
with:
|
||||
username: mona
|
||||
secrets:
|
||||
token: ${{ secrets.TOKEN }}
|
||||
```
|
||||
{% endraw %}
|
||||
### Supported keywords for jobs that call a reusable workflow
|
||||
|
||||
### Palabras clave compatibles con los jobs que llaman a un flujo de trabajo reutilizable
|
||||
|
||||
Cuando llamas a un flujo de trabajo reutilizable, solo puedes utilizar las siguientes palabras clave en el job que contiene la llamada:
|
||||
When you call a reusable workflow, you can only use the following keywords in the job containing the call:
|
||||
|
||||
* [`jobs.<job_id>.name`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idname)
|
||||
* [`jobs.<job_id>.uses`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_iduses)
|
||||
@@ -158,16 +192,16 @@ Cuando llamas a un flujo de trabajo reutilizable, solo puedes utilizar las sigui
|
||||
|
||||
{% note %}
|
||||
|
||||
**Nota:**
|
||||
**Note:**
|
||||
|
||||
* Si no se especifica `jobs.<job_id>.permissions` en el job de llamada, el flujo de trabajo llamado tendrá los permisos predefinidos para el `GITHUB_TOKEN`. Para obtener más información, consulta la sección "[Autenticación en un flujo de trabajo](/actions/reference/authentication-in-a-workflow#permissions-for-the-github_token)".
|
||||
* Los permisos del `GITHUB_TOKEN` que se pasaron del flujo de trabajo llamante solo pueden bajarse de nivel (no elevarse) a través del flujo de trabajo llamado.
|
||||
* If `jobs.<job_id>.permissions` is not specified in the calling job, the called workflow will have the default permissions for the `GITHUB_TOKEN`. For more information, see "[Authentication in a workflow](/actions/reference/authentication-in-a-workflow#permissions-for-the-github_token)."
|
||||
* The `GITHUB_TOKEN` permissions passed from the caller workflow can be only downgraded (not elevated) by the called workflow.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
### Flujo de trabajo llamante de ejemplo
|
||||
### Example caller workflow
|
||||
|
||||
Este archivo de flujo de trabajo llama a otros dos archivos de flujo de trabajo. Al segundo de ellos, `workflow-B.yml` (que se muestra anteriormente), se le pasó una entrada, `username`, y un secreto, `token`.
|
||||
This workflow file calls two workflow files. The second of these, `workflow-B.yml` (shown in the [example reusable workflow](#example-reusable-workflow)), is passed an input (`username`) and a secret (`token`).
|
||||
|
||||
{% raw %}
|
||||
```yaml{:copy}
|
||||
@@ -191,6 +225,82 @@ jobs:
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
## Pasos siguientes
|
||||
## Using outputs from a reusable workflow
|
||||
|
||||
Para seguir aprendiendo sobre las {% data variables.product.prodname_actions %}, consulta la sección "[Eventos que activan flujos de trabajo](/actions/learn-github-actions/events-that-trigger-workflows)".
|
||||
A reusable workflow may generate data that you want to use in the caller workflow. To use these outputs, you must specify them as the outputs of the reusable workflow.
|
||||
|
||||
The following reusable workflow has a single job containing two steps. In each of these steps we set a single word as the output: "hello" and "world." In the `outputs` section of the job, we map these step outputs to job outputs called: `output1` and `output2`. In the `on.workflow_call.outputs` section we then define two outputs for the workflow itself, one called `firstword` which we map to `output1`, and one called `secondword` which we map to `output2`.
|
||||
|
||||
{% raw %}
|
||||
```yaml{:copy}
|
||||
name: Reusable workflow
|
||||
|
||||
on:
|
||||
workflow_call:
|
||||
# Map the workflow outputs to job outputs
|
||||
outputs:
|
||||
firstword:
|
||||
description: "The first output string"
|
||||
value: ${{ jobs.example_job.outputs.output1 }}
|
||||
secondword:
|
||||
description: "The second output string"
|
||||
value: ${{ jobs.example_job.outputs.output2 }}
|
||||
|
||||
jobs:
|
||||
example_job:
|
||||
name: Generate output
|
||||
runs-on: ubuntu-latest
|
||||
# Map the job outputs to step outputs
|
||||
outputs:
|
||||
output1: ${{ steps.step1.outputs.firstword }}
|
||||
output2: ${{ steps.step2.outputs.secondword }}
|
||||
steps:
|
||||
- id: step1
|
||||
run: echo "::set-output name=firstword::hello"
|
||||
- id: step2
|
||||
run: echo "::set-output name=secondword::world"
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
We can now use the outputs in the caller workflow, in the same way you would use the outputs from a job within the same workflow. We reference the outputs using the names defined at the workflow level in the reusable workflow: `firstword` and `secondword`. In this workflow, `job1` calls the reusable workflow and `job2` prints the outputs from the reusable workflow ("hello world") to standard output in the workflow log.
|
||||
|
||||
{% raw %}
|
||||
```yaml{:copy}
|
||||
name: Call a reusable workflow and use its outputs
|
||||
|
||||
on:
|
||||
workflow_dispatch:
|
||||
|
||||
jobs:
|
||||
job1:
|
||||
uses: octo-org/example-repo/.github/workflows/called-workflow.yml@v1
|
||||
|
||||
job2:
|
||||
runs-on: ubuntu-latest
|
||||
needs: job1
|
||||
steps:
|
||||
- run: echo ${{ needs.job1.outputs.firstword }} ${{ needs.job1.outputs.secondword }}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
For more information on using job outputs, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idoutputs)."
|
||||
|
||||
## Monitoring which workflows are being used
|
||||
|
||||
You can use the {% data variables.product.prodname_dotcom %} REST API to monitor how reusable workflows are being used. The `prepared_workflow_job` audit log action is triggered when a workflow job is started. Included in the data recorded are:
|
||||
* `repo` - the organization/repository where the workflow job is located. For a job that calls another workflow, this is the organization/repository of the caller workflow.
|
||||
* `@timestamp` - the date and time that the job was started, in Unix epoch format.
|
||||
* `job_name` - the name of the job that was run.
|
||||
* `job_workflow_ref` - the workflow file that was used, in the form `{owner}/{repo}/{path}/{filename}@{ref}`. For a job that calls another workflow, this identifies the called workflow.
|
||||
|
||||
For information about using the REST API to query the audit log for an organization, see "[Organizations](/rest/reference/orgs#get-the-audit-log-for-an-organization)."
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note**: Audit data for `prepared_workflow_job` can only be viewed using the REST API. It is not visible in the {% data variables.product.prodname_dotcom %} web interface, or included in JSON/CSV exported audit data.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
## Next steps
|
||||
|
||||
To continue learning about {% data variables.product.prodname_actions %}, see "[Events that trigger workflows](/actions/learn-github-actions/events-that-trigger-workflows)."
|
||||
|
||||
@@ -226,6 +226,31 @@ For more information, see "[Reusing workflows](/actions/learn-github-actions/reu
|
||||
|
||||
Required if input is defined for the `on.workflow_call` keyword. The value of this parameter is a string specifying the data type of the input. This must be one of: `boolean`, `number`, or `string`.
|
||||
|
||||
## `on.workflow_call.outputs`
|
||||
|
||||
A map of outputs for a called workflow. Called workflow outputs are available to all downstream jobs in the caller workflow. Each output has an identifier, an optional `description,` and a `value.` The `value` must be set to the value of an output from a job within the called workflow.
|
||||
|
||||
In the example below, two outputs are defined for this reusable workflow: `workflow_output1` and `workflow_output2`. These are mapped to outputs called `job_output1` and `job_output2`, both from a job called `my_job`.
|
||||
|
||||
### Example
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
on:
|
||||
workflow_call:
|
||||
# Map the workflow outputs to job outputs
|
||||
outputs:
|
||||
workflow_output1:
|
||||
description: "The first job output"
|
||||
value: ${{ jobs.my_job.outputs.job_output1 }}
|
||||
workflow_output2:
|
||||
description: "The second job output"
|
||||
value: ${{ jobs.my_job.outputs.job_output2 }}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
For information on how to reference a job output, see [`jobs.<job_id>.outputs`](#jobsjob_idoutputs). For more information, see "[Reusing workflows](/actions/learn-github-actions/reusing-workflows)."
|
||||
|
||||
## `on.workflow_call.secrets`
|
||||
|
||||
A map of the secrets that can be used in the called workflow.
|
||||
|
||||
@@ -48,9 +48,10 @@ When you have configured {% data variables.product.product_location %} to use {%
|
||||
Any VM that you use for {% data variables.product.prodname_dependabot %} runners must meet the requirements for self-hosted runners. In addition, they must meet the following requirements.
|
||||
|
||||
- Linux operating system
|
||||
- The following dependencies installed:
|
||||
- Docker running as the same user as the self-hosted runner application
|
||||
- Git
|
||||
- Git installed
|
||||
- Docker installed with access for the runner users:
|
||||
- We recommend installing Docker in rootless mode and configuring the runners to access Docker without `root` privileges.
|
||||
- Alternatively, install Docker and give the runner users raised privileges to run Docker.
|
||||
|
||||
The CPU and memory requirements will depend on the number of concurrent runners you deploy on a given VM. As guidance, we have successfully set up 20 runners on a single 2 CPU 8GB machine, but ultimately, your CPU and memory requirements will heavily depend on the repositories being updated. Some ecosystems will require more resources than others.
|
||||
|
||||
@@ -72,6 +73,15 @@ If you specify more than 14 concurrent runners on a VM, you must also update the
|
||||
|
||||
1. Provision self-hosted runners, at the repository, organization, or enterprise account level. For more information, see "[About self-hosted runners](/actions/hosting-your-own-runners/about-self-hosted-runners)" and "[Adding self-hosted runners](/actions/hosting-your-own-runners/adding-self-hosted-runners)."
|
||||
|
||||
2. Verify that the self-hosted runners meet the requirements for {% data variables.product.prodname_dependabot %} before assigning a `dependabot` label to each runner you want {% data variables.product.prodname_dependabot %} to use. For more information, see "[Using labels with self-hosted runners](/actions/hosting-your-own-runners/using-labels-with-self-hosted-runners#assigning-a-label-to-a-self-hosted-runner)."
|
||||
2. Set up the self-hosted runners with the requirements described above. For example, on a VM running Ubuntu 20.04 you would:
|
||||
|
||||
3. Optionally, enable workflows triggered by {% data variables.product.prodname_dependabot %} to use more than read-only permissions and to have access to any secrets that are normally available. For more information, see "[Troubleshooting {% data variables.product.prodname_actions %} for your enterprise](/admin/github-actions/advanced-configuration-and-troubleshooting/troubleshooting-github-actions-for-your-enterprise#enabling-workflows-triggered-by-dependabot-access-to-dependabot-secrets-and-increased-permissions)."
|
||||
- Verify that Git is installed: `command -v git`
|
||||
- Install Docker and ensure that the runner users have access to Docker. For more information, see the Docker documentation.
|
||||
- [Install Docker Engine on Ubuntu](https://docs.docker.com/engine/install/ubuntu/)
|
||||
- Recommended approach: [Run the Docker daemon as a non-root user (Rootless mode)](https://docs.docker.com/engine/security/rootless/)
|
||||
- Alternative approach: [Manage Docker as a non-root user](https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user)
|
||||
- Verify that the runners have access to the public internet and can only access the internal networks that {% data variables.product.prodname_dependabot %} needs.
|
||||
|
||||
3. Assign a `dependabot` label to each runner you want {% data variables.product.prodname_dependabot %} to use. For more information, see "[Using labels with self-hosted runners](/actions/hosting-your-own-runners/using-labels-with-self-hosted-runners#assigning-a-label-to-a-self-hosted-runner)."
|
||||
|
||||
4. Optionally, enable workflows triggered by {% data variables.product.prodname_dependabot %} to use more than read-only permissions and to have access to any secrets that are normally available. For more information, see "[Troubleshooting {% data variables.product.prodname_actions %} for your enterprise](/admin/github-actions/advanced-configuration-and-troubleshooting/troubleshooting-github-actions-for-your-enterprise#enabling-workflows-triggered-by-dependabot-access-to-dependabot-secrets-and-increased-permissions)."
|
||||
|
||||
@@ -23,7 +23,6 @@ topics:
|
||||
- Actions
|
||||
- Repositories
|
||||
---
|
||||
<!--For this article in earlier GHES versions, see /content/github/finding-security-vulnerabilities-and-errors-in-your-code-->
|
||||
|
||||
{% data reusables.code-scanning.beta %}
|
||||
{% data reusables.code-scanning.enterprise-enable-code-scanning-actions %}
|
||||
@@ -34,13 +33,21 @@ You decide how to generate {% data variables.product.prodname_code_scanning %} a
|
||||
|
||||
{% data reusables.code-scanning.enabling-options %}
|
||||
|
||||
{% ifversion ghae %}
|
||||
## Prerequisites
|
||||
|
||||
Before setting up {% data variables.product.prodname_code_scanning %} for a repository, you must ensure that there is at least one self-hosted {% data variables.product.prodname_actions %} runner available to the repository.
|
||||
|
||||
Enterprise owners, organization and repository administrators can add self-hosted runners. For more information, see "[About self-hosted runners](/actions/hosting-your-own-runners/about-self-hosted-runners)" and "[Adding self-hosted runners](/actions/hosting-your-own-runners/adding-self-hosted-runners)."
|
||||
{% endif %}
|
||||
|
||||
## Setting up {% data variables.product.prodname_code_scanning %} using actions
|
||||
|
||||
{% ifversion fpt or ghec %}Using actions to run {% data variables.product.prodname_code_scanning %} will use minutes. For more information, see "[About billing for {% data variables.product.prodname_actions %}](/billing/managing-billing-for-github-actions/about-billing-for-github-actions)."{% endif %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-security %}
|
||||
3. To the right of "{% data variables.product.prodname_code_scanning_capc %} alerts", click **Set up {% data variables.product.prodname_code_scanning %}**. {% ifversion fpt or ghes > 3.0 or ghae-next or ghec %}If {% data variables.product.prodname_code_scanning %} is missing, you need to ask an organization owner or repository administrator to enable {% data variables.product.prodname_GH_advanced_security %}. For more information, see "[Managing security and analysis settings for your organization](/organizations/keeping-your-organization-secure/managing-security-and-analysis-settings-for-your-organization)" or "[Managing security and analysis settings for your repository](/github/administering-a-repository/managing-security-and-analysis-settings-for-your-repository)."{% endif %}
|
||||
1. To the right of "{% data variables.product.prodname_code_scanning_capc %} alerts", click **Set up {% data variables.product.prodname_code_scanning %}**. {% ifversion fpt or ghes > 3.0 or ghae-next or ghec %}If {% data variables.product.prodname_code_scanning %} is missing, you need to ask an organization owner or repository administrator to enable {% data variables.product.prodname_GH_advanced_security %}. For more information, see "[Managing security and analysis settings for your organization](/organizations/keeping-your-organization-secure/managing-security-and-analysis-settings-for-your-organization)" or "[Managing security and analysis settings for your repository](/github/administering-a-repository/managing-security-and-analysis-settings-for-your-repository)."{% endif %}
|
||||

|
||||
4. Under "Get started with {% data variables.product.prodname_code_scanning %}", click **Set up this workflow** on the {% data variables.product.prodname_codeql_workflow %} or on a third-party workflow.
|
||||
Workflows are only displayed if they are relevant for the programming languages detected in the repository. The {% data variables.product.prodname_codeql_workflow %} is always displayed, but the "Set up this workflow" button is only enabled if {% data variables.product.prodname_codeql %} analysis supports the languages present in the repository.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Personalizar tu codespace
|
||||
intro: '{% data variables.product.prodname_codespaces %} es un ambiente dedicado para ti. Puedes configurar tus repositorios con un contenedor de dev para definir su ambiente predeterminado de Codespaces y personalizar tu experiencia de desarrollo a lo largo de tus codespaces con dotfiles y sincronización de ajustes.'
|
||||
title: Customizing your codespace
|
||||
intro: '{% data variables.product.prodname_codespaces %} is a dedicated environment for you. You can configure your repositories with a dev container to define their default Codespaces environment, and personalize your development experience across all of your codespaces with dotfiles and Settings Sync.'
|
||||
product: '{% data reusables.gated-features.codespaces %}'
|
||||
versions:
|
||||
fpt: '*'
|
||||
@@ -10,8 +10,10 @@ redirect_from:
|
||||
topics:
|
||||
- Codespaces
|
||||
children:
|
||||
- /configuring-codespaces-for-your-project
|
||||
- /personalizing-codespaces-for-your-account
|
||||
- /changing-the-machine-type-for-your-codespace
|
||||
- /setting-your-default-editor-for-codespaces
|
||||
- /setting-your-default-region-for-codespaces
|
||||
- /prebuilding-codespaces-for-your-project
|
||||
---
|
||||
|
||||
|
||||
|
||||
@@ -14,6 +14,7 @@ topics:
|
||||
- Codespaces
|
||||
- Fundamentals
|
||||
- Developer
|
||||
shortTitle: Create a codespace
|
||||
---
|
||||
|
||||
## About codespace creation
|
||||
|
||||
@@ -13,6 +13,7 @@ topics:
|
||||
- Codespaces
|
||||
- Fundamentals
|
||||
- Developer
|
||||
shortTitle: Delete a codespace
|
||||
---
|
||||
|
||||
|
||||
|
||||
@@ -14,6 +14,7 @@ topics:
|
||||
- Codespaces
|
||||
- Fundamentals
|
||||
- Developer
|
||||
shortTitle: Develop in a codespace
|
||||
---
|
||||
|
||||
|
||||
|
||||
@@ -15,7 +15,6 @@ children:
|
||||
- /using-codespaces-for-pull-requests
|
||||
- /deleting-a-codespace
|
||||
- /forwarding-ports-in-your-codespace
|
||||
- /changing-the-machine-type-for-your-codespace
|
||||
- /using-codespaces-in-visual-studio-code
|
||||
- /using-codespaces-with-github-cli
|
||||
---
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Administrar tus codespaces
|
||||
intro: 'Puedes utilizar los ajustes de {% data variables.product.prodname_github_codespaces %} para administrar la información que pudiera necesitar tu codespace.'
|
||||
title: Managing your codespaces
|
||||
intro: 'You can use {% data variables.product.prodname_github_codespaces %} settings to manage information that your codespace might need.'
|
||||
product: '{% data reusables.gated-features.codespaces %}'
|
||||
versions:
|
||||
fpt: '*'
|
||||
@@ -14,7 +14,5 @@ children:
|
||||
- /managing-repository-access-for-your-codespaces
|
||||
- /reviewing-your-security-logs-for-codespaces
|
||||
- /managing-gpg-verification-for-codespaces
|
||||
- /setting-your-default-editor-for-codespaces
|
||||
- /setting-your-default-region-for-codespaces
|
||||
---
|
||||
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ You can create a codespace from any branch or commit in your repository and begi
|
||||
|
||||
To customize the runtimes and tools in your codespace, you can create a custom configuration to define an environment (or _dev container_) that is specific for your repository. Using a dev container allows you to specify a Docker environment for development with a well-defined tool and runtime stack that can reference an image, Dockerfile, or docker-compose. This means that anyone using the repository will have the same tools available to them when they create a codespace.
|
||||
|
||||
If you don't do any custom configuration, {% data variables.product.prodname_codespaces %} will clone your repository into an environment with the default codespace image that includes many tools, languages, and runtime environments. For more information, see "[Configuring Codespaces for your project](/codespaces/setting-up-your-codespace/configuring-codespaces-for-your-project)".
|
||||
If you don't do any custom configuration, {% data variables.product.prodname_codespaces %} will clone your repository into an environment with the default codespace image that includes many tools, languages, and runtime environments. For more information, see "[Introduction to dev containers](/codespaces/setting-up-your-codespace/configuring-codespaces-for-your-project)".
|
||||
|
||||
You can also personalize aspects of your codespace environment by using a public [dotfiles](https://dotfiles.github.io/tutorials/) repository and [Settings Sync](https://code.visualstudio.com/docs/editor/settings-sync). Personalization can include shell preferences, additional tools, editor settings, and VS Code extensions. For more information, see "[Customizing your codespace](/codespaces/customizing-your-codespace)".
|
||||
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
title: 'Configurar tu proyecto para {% data variables.product.prodname_codespaces %}'
|
||||
intro: 'Aprende cómo iniciar con los {% data variables.product.prodname_codespaces %}, incluyendo cómo configurar y hacer ajustes para lenguajes específicos.'
|
||||
title: 'Setting up your repository for {% data variables.product.prodname_codespaces %}'
|
||||
allowTitleToDifferFromFilename: true
|
||||
intro: 'Learn how to get started with {% data variables.product.prodname_codespaces %}, including set up and configuration for specific languages.'
|
||||
product: '{% data reusables.gated-features.codespaces %}'
|
||||
versions:
|
||||
fpt: '*'
|
||||
@@ -8,6 +9,8 @@ versions:
|
||||
redirect_from:
|
||||
- /codespaces/getting-started-with-codespaces
|
||||
children:
|
||||
- /configuring-codespaces-for-your-project
|
||||
- /setting-up-your-project-for-codespaces
|
||||
- /setting-up-your-nodejs-project-for-codespaces
|
||||
- /setting-up-your-dotnet-project-for-codespaces
|
||||
- /setting-up-your-java-project-for-codespaces
|
||||
|
||||
@@ -11,6 +11,8 @@ versions:
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Codespaces
|
||||
hasExperimentalAlternative: true
|
||||
hidden: true
|
||||
---
|
||||
|
||||
|
||||
@@ -36,14 +38,14 @@ When you create a codespace, your project is created on a remote VM that is dedi
|
||||
|
||||
You can customize your codespace by adjusting the amount of vCPUs and RAM, [adding dotfiles to personalize your environment](/codespaces/setting-up-your-codespace/personalizing-codespaces-for-your-account), or by modifying the tools and scripts installed.
|
||||
|
||||
{% data variables.product.prodname_codespaces %} uses a file called `devcontainer.json` to store configurations. On launch {% data variables.product.prodname_codespaces %} uses the file to install any tools, dependencies, or other set up that might be needed for the project. For more information, see "[Configuring Codespaces for your project](/codespaces/setting-up-your-codespace/configuring-codespaces-for-your-project)."
|
||||
{% data variables.product.prodname_codespaces %} uses a file called `devcontainer.json` to store configurations. On launch {% data variables.product.prodname_codespaces %} uses the file to install any tools, dependencies, or other set up that might be needed for the project. For more information, see "[Introduction to dev containers](/codespaces/setting-up-your-codespace/configuring-codespaces-for-your-project)."
|
||||
|
||||
|
||||
## Step 2: Add a dev container to your codespace from a template
|
||||
|
||||
The default codespaces container comes with the latest .NET version and common tools preinstalled. However, we encourage you to set up a custom container so you can tailor the tools and scripts that run as part of codespace creation to your project's needs and ensure a fully reproducible environment for all {% data variables.product.prodname_codespaces %} users in your repository.
|
||||
|
||||
To set up your project with a custom container, you will need to use a `devcontainer.json` file to define the environment. In {% data variables.product.prodname_codespaces %} you can add this either from a template or you can create your own. For more information on dev containers, see "[Configuring Codespaces for your project
|
||||
To set up your project with a custom container, you will need to use a `devcontainer.json` file to define the environment. In {% data variables.product.prodname_codespaces %} you can add this either from a template or you can create your own. For more information on dev containers, see "[Introduction to dev containers
|
||||
](/codespaces/setting-up-your-codespace/configuring-codespaces-for-your-project)."
|
||||
|
||||
|
||||
|
||||
@@ -10,6 +10,8 @@ versions:
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Codespaces
|
||||
hasExperimentalAlternative: true
|
||||
hidden: true
|
||||
---
|
||||
|
||||
|
||||
@@ -35,14 +37,14 @@ When you create a codespace, your project is created on a remote VM that is dedi
|
||||
|
||||
You can customize your codespace by adjusting the amount of vCPUs and RAM, [adding dotfiles to personalize your environment](/codespaces/setting-up-your-codespace/personalizing-codespaces-for-your-account), or by modifying the tools and scripts installed.
|
||||
|
||||
{% data variables.product.prodname_codespaces %} uses a file called `devcontainer.json` to store configurations. On launch {% data variables.product.prodname_codespaces %} uses the file to install any tools, dependencies, or other set up that might be needed for the project. For more information, see "[Configuring Codespaces for your project](/codespaces/setting-up-your-codespace/configuring-codespaces-for-your-project)."
|
||||
{% data variables.product.prodname_codespaces %} uses a file called `devcontainer.json` to store configurations. On launch {% data variables.product.prodname_codespaces %} uses the file to install any tools, dependencies, or other set up that might be needed for the project. For more information, see "[Introduction to dev containers](/codespaces/setting-up-your-codespace/configuring-codespaces-for-your-project)."
|
||||
|
||||
|
||||
## Step 2: Add a dev container to your codespace from a template
|
||||
|
||||
The default codespaces container comes with the latest Java version, package managers (Maven, Gradle), and other common tools preinstalled. However, we recommend that you set up a custom container to define the tools and scripts that your project needs. This will ensure a fully reproducible environment for all {% data variables.product.prodname_codespaces %} users in your repository.
|
||||
|
||||
To set up your project with a custom container, you will need to use a `devcontainer.json` file to define the environment. In {% data variables.product.prodname_codespaces %} you can add this either from a template or you can create your own. For more information on dev containers, see "[Configuring Codespaces for your project](/codespaces/setting-up-your-codespace/configuring-codespaces-for-your-project)."
|
||||
To set up your project with a custom container, you will need to use a `devcontainer.json` file to define the environment. In {% data variables.product.prodname_codespaces %} you can add this either from a template or you can create your own. For more information on dev containers, see "[Introduction to dev containers](/codespaces/setting-up-your-codespace/configuring-codespaces-for-your-project)."
|
||||
|
||||
|
||||
{% data reusables.codespaces.command-palette-container %}
|
||||
|
||||
@@ -14,6 +14,8 @@ topics:
|
||||
- Developer
|
||||
- Node
|
||||
- JavaScript
|
||||
hasExperimentalAlternative: true
|
||||
hidden: true
|
||||
---
|
||||
|
||||
|
||||
@@ -40,13 +42,13 @@ When you create a codespace, your project is created on a remote VM that is dedi
|
||||
|
||||
You can customize your codespace by adjusting the amount of vCPUs and RAM, [adding dotfiles to personalize your environment](/codespaces/setting-up-your-codespace/personalizing-codespaces-for-your-account), or by modifying the tools and scripts installed.
|
||||
|
||||
{% data variables.product.prodname_codespaces %} uses a file called `devcontainer.json` to store configurations. On launch {% data variables.product.prodname_codespaces %} uses the file to install any tools, dependencies, or other set up that might be needed for the project. For more information, see "[Configuring Codespaces for your project](/codespaces/setting-up-your-codespace/configuring-codespaces-for-your-project)."
|
||||
{% data variables.product.prodname_codespaces %} uses a file called `devcontainer.json` to store configurations. On launch {% data variables.product.prodname_codespaces %} uses the file to install any tools, dependencies, or other set up that might be needed for the project. For more information, see "[Introduction to dev containers](/codespaces/setting-up-your-codespace/configuring-codespaces-for-your-project)."
|
||||
|
||||
## Step 2: Add a dev container to your codespace from a template
|
||||
|
||||
The default codespaces container will support running Node.js projects like [vscode-remote-try-node](https://github.com/microsoft/vscode-remote-try-node) out of the box. By setting up a custom container you can customize the tools and scripts that run as part of codespace creation and ensure a fully reproducible environment for all {% data variables.product.prodname_codespaces %} users in your repository.
|
||||
|
||||
To set up your project with a custom container, you will need to use a `devcontainer.json` file to define the environment. In {% data variables.product.prodname_codespaces %} you can add this either from a template or you can create your own. For more information on dev containers, see "[Configuring Codespaces for your project](/codespaces/setting-up-your-codespace/configuring-codespaces-for-your-project)".
|
||||
To set up your project with a custom container, you will need to use a `devcontainer.json` file to define the environment. In {% data variables.product.prodname_codespaces %} you can add this either from a template or you can create your own. For more information on dev containers, see "[Introduction to dev containers](/codespaces/setting-up-your-codespace/configuring-codespaces-for-your-project)".
|
||||
|
||||
{% data reusables.codespaces.command-palette-container %}
|
||||
3. For this example, click **Node.js**. If you need additional features you can select any container that’s specific to Node or a combination of tools such as Node and MongoDB.
|
||||
|
||||
@@ -13,6 +13,8 @@ topics:
|
||||
- Codespaces
|
||||
- Developer
|
||||
- Python
|
||||
hasExperimentalAlternative: true
|
||||
hidden: true
|
||||
---
|
||||
|
||||
|
||||
@@ -40,14 +42,14 @@ When you create a codespace, your project is created on a remote VM that is dedi
|
||||
|
||||
You can customize your codespace by adjusting the amount of vCPUs and RAM, [adding dotfiles to personalize your environment](/codespaces/setting-up-your-codespace/personalizing-codespaces-for-your-account), or by modifying the tools and scripts installed.
|
||||
|
||||
{% data variables.product.prodname_codespaces %} uses a file called `devcontainer.json` to store configurations. On launch {% data variables.product.prodname_codespaces %} uses the file to install any tools, dependencies, or other set up that might be needed for the project. For more information, see "[Configuring Codespaces for your project](/codespaces/setting-up-your-codespace/configuring-codespaces-for-your-project)."
|
||||
{% data variables.product.prodname_codespaces %} uses a file called `devcontainer.json` to store configurations. On launch {% data variables.product.prodname_codespaces %} uses the file to install any tools, dependencies, or other set up that might be needed for the project. For more information, see "[Introduction to dev containers](/codespaces/setting-up-your-codespace/configuring-codespaces-for-your-project)."
|
||||
|
||||
|
||||
## Step 2: Add a dev container to your codespace from a template
|
||||
|
||||
The default codespaces container comes with the latest Python version, package managers (pip, Miniconda), and other common tools preinstalled. However, we recommend that you set up a custom container to define the tools and scripts that your project needs. This will ensure a fully reproducible environment for all {% data variables.product.prodname_codespaces %} users in your repository.
|
||||
|
||||
To set up your project with a custom container, you will need to use a `devcontainer.json` file to define the environment. In {% data variables.product.prodname_codespaces %} you can add this either from a template or you can create your own. For more information on dev containers, see "[Configuring Codespaces for your project](/codespaces/setting-up-your-codespace/configuring-codespaces-for-your-project)."
|
||||
To set up your project with a custom container, you will need to use a `devcontainer.json` file to define the environment. In {% data variables.product.prodname_codespaces %} you can add this either from a template or you can create your own. For more information on dev containers, see "[Introduction to dev containers](/codespaces/setting-up-your-codespace/configuring-codespaces-for-your-project)."
|
||||
|
||||
|
||||
{% data reusables.codespaces.command-palette-container %}
|
||||
|
||||
@@ -77,7 +77,8 @@ To search for specific events, use the `action` qualifier in your query. Actions
|
||||
| [`secret_scanning_new_repos`](#secret_scanning_new_repos-category-actions) | Contains organization-level configuration activities for secret scanning for new repositories created in the organization. {% ifversion fpt or ghec %}
|
||||
| [`sponsors`](#sponsors-category-actions) | Contains all events related to sponsor buttons (see "[Displaying a sponsor button in your repository](/articles/displaying-a-sponsor-button-in-your-repository)"){% endif %}
|
||||
| [`team`](#team-category-actions) | Contains all activities related to teams in your organization.
|
||||
| [`team_discussions`](#team_discussions-category-actions) | Contains activities related to managing team discussions for an organization.
|
||||
| [`team_discussions`](#team_discussions-category-actions) | Contains activities related to managing team discussions for an organization.{% ifversion fpt or ghec or ghes > 3.1 or ghae-next %}
|
||||
| [`workflows`](#workflows-category-actions) | Contains activities related to {% data variables.product.prodname_actions %} workflows.{% endif %}
|
||||
|
||||
You can search for specific sets of actions using these terms. For example:
|
||||
|
||||
@@ -743,10 +744,11 @@ For more information, see "[Managing the publication of {% data variables.produc
|
||||
| `disable` | Triggered when an organization owner disables team discussions for an organization. For more information, see "[Disabling team discussions for your organization](/articles/disabling-team-discussions-for-your-organization)."
|
||||
| `enable` | Triggered when an organization owner enables team discussions for an organization.
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.1 or ghae-next %}
|
||||
### `workflows` category actions
|
||||
|
||||
{% data reusables.actions.actions-audit-events-workflow %}
|
||||
|
||||
{% endif %}
|
||||
## Further reading
|
||||
|
||||
- "[Keeping your organization secure](/articles/keeping-your-organization-secure)"{% ifversion fpt or ghec or ghes > 3.3 or ghae-issue-5146 %}
|
||||
|
||||
@@ -5,9 +5,9 @@ intro: Learn how to avoid duplication when creating a workflow by reusing existi
|
||||
miniTocMaxHeadingLevel: 3
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '>=3.4'
|
||||
ghae: issue-4757
|
||||
ghec: '*'
|
||||
type: how_to
|
||||
topics:
|
||||
- Workflows
|
||||
@@ -17,17 +17,15 @@ topics:
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
{% data reusables.actions.ae-beta %}
|
||||
|
||||
{% note %}
|
||||
## Overview
|
||||
|
||||
**Note:** Reusable workflows are currently in beta and subject to change.
|
||||
Rather than copying and pasting from one workflow to another, you can make workflows reusable. You and anyone with access to the reusable workflow can then call the reusable workflow from another workflow.
|
||||
|
||||
{% endnote %}
|
||||
Reusing workflows avoids duplication. This makes workflows easier to maintain and allows you to create new workflows more quickly by building on the work of others, just as you do with actions. Workflow reuse also promotes best practice by helping you to use workflows that are well designed, have already been tested, and have been proved to be effective. Your organization can build up a library of reusable workflows that can be centrally maintained.
|
||||
|
||||
## 概要
|
||||
The diagram below shows three build jobs on the left of the diagram. After each of these jobs completes successfully a dependent job called "Deploy" runs. This job calls a reusable workflow that contains three jobs: "Staging", "Review", and "Production." The "Production" deployment job only runs after the "Staging" job has completed successfully. Using a reusable workflow to run deployment jobs allows you to run those jobs for each build without duplicating code in workflows.
|
||||
|
||||
Rather than copying and pasting from one workflow to another, you can make workflows reusable. You and anyone with access to the reusable workflow can then call the reusable workflow from another workflow.
|
||||
|
||||
Reusing workflows avoids duplication. This makes workflows easier to maintain and allows you to create new workflows more quickly by building on the work of others, just as you do with actions. Workflow reuse also promotes best practice by helping you to use workflows that are well designed, have already been tested, and have been proved to be effective. Your organization can build up a library of reusable workflows that can be centrally maintained.
|
||||

|
||||
|
||||
A workflow that uses another workflow is referred to as a "caller" workflow. The reusable workflow is a "called" workflow. One caller workflow can use multiple called workflows. Each called workflow is referenced in a single line. The result is that the caller workflow file may contain just a few lines of YAML, but may perform a large number of tasks when it's run. When you reuse a workflow, the entire called workflow is used, just as if it was part of the caller workflow.
|
||||
|
||||
@@ -35,23 +33,43 @@ If you reuse a workflow from a different repository, any actions in the called w
|
||||
|
||||
When a reusable workflow is triggered by a caller workflow, the `github` context is always associated with the caller workflow. The called workflow is automatically granted access to `github.token` and `secrets.GITHUB_TOKEN`. For more information about the `github` context, see "[Context and expression syntax for GitHub Actions](/actions/reference/context-and-expression-syntax-for-github-actions#github-context)."
|
||||
|
||||
### Reusable workflows and workflow templates
|
||||
|
||||
Workflow templates allow everyone in your organization who has permission to create workflows to do so more quickly and easily. When people create a new workflow, they can choose a template and some or all of the work of writing the workflow will be done for them. Inside workflow templates, you can also reference reusable workflows to make it easy for people to benefit from reusing centrally managed workflow code. If you use a tag or branch name when referencing the reusable workflow then you can ensure that everyone who reuses that workflow will always be using the same YAML code. However, if you reference a reusable workflow by a tag or branch, be sure that you can trust that version of the workflow. For more information, see "[Security hardening for {% data variables.product.prodname_actions %}](/actions/security-guides/security-hardening-for-github-actions#reusing-third-party-workflows)."
|
||||
|
||||
For more information, see "[Creating workflow templates](/actions/learn-github-actions/creating-workflow-templates)."
|
||||
|
||||
## Access to reusable workflows
|
||||
|
||||
A reusable workflow can be used by another workflow if any of the following is true:
|
||||
A reusable workflow can be used by another workflow if {% ifversion ghes or ghec or ghae %}any{% else %}either{% endif %} of the following is true:
|
||||
|
||||
* Both workflows are in the same repository.
|
||||
* The called workflow is stored in a public repository.
|
||||
* The called workflow is stored in an internal repository and the settings for that repository allow it to be accessed. For more information, see "[Managing {% data variables.product.prodname_actions %} settings for a repository](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-an-internal-repository)."
|
||||
* The called workflow is stored in a public repository.{% ifversion ghes or ghec or ghae %}
|
||||
* The called workflow is stored in an internal repository and the settings for that repository allow it to be accessed. For more information, see "[Managing {% data variables.product.prodname_actions %} settings for a repository](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-an-internal-repository)."{% endif %}
|
||||
|
||||
## 制限事項
|
||||
## Using runners
|
||||
|
||||
### Using GitHub-hosted runners
|
||||
|
||||
{% ifversion fpt or ghes or ghec %}
|
||||
The assignment of {% data variables.product.prodname_dotcom %}-hosted runners is always evaluated using only the caller's context. Billing for {% data variables.product.prodname_dotcom %}-hosted runners is always associated with the caller. The caller workflow cannot use {% data variables.product.prodname_dotcom %}-hosted runners from the called repository. For more information, see "[About {% data variables.product.prodname_dotcom %}-hosted runners](/actions/using-github-hosted-runners/about-github-hosted-runners)."
|
||||
{% endif %}
|
||||
{% ifversion ghae %}
|
||||
The assignment of {% data variables.actions.hosted_runner %}s is always evaluated using only the caller's context. Billing for {% data variables.actions.hosted_runner %}s is always associated with the caller. The caller cannot use {% data variables.actions.hosted_runner %}s from the called repository. For more information, see "[About {% data variables.actions.hosted_runner %}s](/github-ae@latest/actions/using-github-hosted-runners/about-ae-hosted-runners)."
|
||||
{% endif %}
|
||||
|
||||
### Using self-hosted runners
|
||||
|
||||
Called workflows can access self-hosted runners from caller's context. This means that a called workflow can access self-hosted runners that are:
|
||||
* In the caller repository
|
||||
* In the caller repository's organization{% ifversion ghes or ghec or ghae %} or enterprise{% endif %}, provided that the runner has been made available to the caller repository
|
||||
|
||||
## Limitations
|
||||
|
||||
* Reusable workflows can't call other reusable workflows.
|
||||
* Reusable workflows stored within a private repository can only be used by workflows within the same repository.
|
||||
* Any environment variables set in an `env` context defined at the workflow level in the caller workflow are not propagated to the called workflow. For more information about the `env` context, see "[Context and expression syntax for GitHub Actions](/actions/reference/context-and-expression-syntax-for-github-actions#env-context)."
|
||||
|
||||
The following limitations will be removed when workflow reuse moves out of beta:
|
||||
* You can't set the concurrency of a called workflow from the caller workflow. For more information about `jobs.<job_id>.concurrency`, see "[Workflow syntax for GitHub Actions](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idconcurrency)."
|
||||
* Outputs generated by a called workflow can't be accessed by the caller workflow.
|
||||
|
||||
## Creating a reusable workflow
|
||||
|
||||
@@ -64,30 +82,55 @@ on:
|
||||
workflow_call:
|
||||
```
|
||||
|
||||
You can define inputs and secrets, which can be passed from the caller workflow and then used within the called workflow. The following example, from a reusable workflow, defines two inputs (called "ring" and "environment") and one secret (called "token"):
|
||||
### Using inputs and secrets in a reusable workflow
|
||||
|
||||
```yaml
|
||||
on:
|
||||
workflow_call:
|
||||
inputs:
|
||||
ring:
|
||||
description: 'Identifier for the target deployment ring'
|
||||
default: 'ring-0'
|
||||
required: false
|
||||
type: string
|
||||
environment:
|
||||
required: false
|
||||
type: string
|
||||
secrets:
|
||||
token:
|
||||
required: false
|
||||
```
|
||||
You can define inputs and secrets, which can be passed from the caller workflow and then used within the called workflow. There are three stages to using an input or a secret in a reusable workflow.
|
||||
|
||||
For details of the syntax for defining inputs and secrets, see [on.workflow_call.inputs](/actions/reference/workflow-syntax-for-github-actions#onworkflow_callinputs) and [on.workflow_call.secrets](/actions/reference/workflow-syntax-for-github-actions#onworkflow_callsecrets).
|
||||
1. In the reusable workflow, use the `inputs` and `secrets` keywords to define inputs or secrets that will be passed from a caller workflow.
|
||||
{% raw %}
|
||||
```yaml
|
||||
on:
|
||||
workflow_call:
|
||||
inputs:
|
||||
username:
|
||||
required: true
|
||||
type: string
|
||||
secrets:
|
||||
envPAT:
|
||||
required: true
|
||||
```
|
||||
{% endraw %}
|
||||
For details of the syntax for defining inputs and secrets, see [`on.workflow_call.inputs`](/actions/reference/workflow-syntax-for-github-actions#onworkflow_callinputs) and [`on.workflow_call.secrets`](/actions/reference/workflow-syntax-for-github-actions#onworkflow_callsecrets).
|
||||
1. Reference the input or secret in the reusable workflow.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
jobs:
|
||||
reusable_workflow_job:
|
||||
runs-on: ubuntu-latest
|
||||
environment: production
|
||||
steps:
|
||||
- uses: ./.github/actions/my-action@v1
|
||||
with:
|
||||
username: ${{ inputs.username }}
|
||||
token: ${{ secrets.envPAT }}
|
||||
```
|
||||
{% endraw %}
|
||||
In the example above, `envPAT` is an environment secret that's been added to the `production` environment. This environment is therefore referenced within the job.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note**: Environment secrets are encrypted strings that are stored in an environment that you've defined for a repository. Environment secrets are only available to workflow jobs that reference the appropriate environment. For more information, see "[Using environments for deployment](/actions/deployment/targeting-different-environments/using-environments-for-deployment#environment-secrets)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
1. Pass the input or secret from the caller workflow.
|
||||
|
||||
{% indented_data_reference reusables.actions.pass-inputs-to-reusable-workflows spaces=3 %}
|
||||
|
||||
### Example reusable workflow
|
||||
|
||||
This reusable workflow file named `workflow-B.yml` (we'll refer to this later) takes an input string and a secret from the caller workflow and uses them in an action.
|
||||
This reusable workflow file named `workflow-B.yml` (we'll refer to this later in the [example caller workflow](#example-caller-workflow)) takes an input string and a secret from the caller workflow and uses them in an action.
|
||||
|
||||
{% raw %}
|
||||
```yaml{:copy}
|
||||
@@ -121,7 +164,7 @@ You call a reusable workflow by using the `uses` keyword. Unlike when you are us
|
||||
|
||||
[`jobs.<job_id>.uses`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_iduses)
|
||||
|
||||
You reference reusable workflow files using the syntax:
|
||||
You reference reusable workflow files using the syntax:
|
||||
|
||||
`{owner}/{repo}/{path}/{filename}@{ref}`
|
||||
|
||||
@@ -131,16 +174,7 @@ You can call multiple workflows, referencing each in a separate job.
|
||||
|
||||
### Passing inputs and secrets to a reusable workflow
|
||||
|
||||
Use the `with` keyword in a job to pass named inputs to the called workflow. Use the `secrets` keyword to pass named secrets. The inputs and secrets you pass must be defined in the called workflow. For inputs, the data type of the input value must match the type specified for that input in the called workflow (boolean, number, or string).
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
with:
|
||||
username: mona
|
||||
secrets:
|
||||
token: ${{ secrets.TOKEN }}
|
||||
```
|
||||
{% endraw %}
|
||||
{% data reusables.actions.pass-inputs-to-reusable-workflows%}
|
||||
|
||||
### Supported keywords for jobs that call a reusable workflow
|
||||
|
||||
@@ -158,16 +192,16 @@ When you call a reusable workflow, you can only use the following keywords in th
|
||||
|
||||
{% note %}
|
||||
|
||||
**注釈:**
|
||||
**Note:**
|
||||
|
||||
* If `jobs.<job_id>.permissions` is not specified in the calling job, the called workflow will have the default permissions for the `GITHUB_TOKEN`. 詳しい情報については、「[ワークフローでの認証](/actions/reference/authentication-in-a-workflow#permissions-for-the-github_token)」を参照してください。
|
||||
* If `jobs.<job_id>.permissions` is not specified in the calling job, the called workflow will have the default permissions for the `GITHUB_TOKEN`. For more information, see "[Authentication in a workflow](/actions/reference/authentication-in-a-workflow#permissions-for-the-github_token)."
|
||||
* The `GITHUB_TOKEN` permissions passed from the caller workflow can be only downgraded (not elevated) by the called workflow.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
### Example caller workflow
|
||||
|
||||
This workflow file calls two workflow files. The second of these, `workflow-B.yml` (shown above), is passed an input, `username`, and a secret, `token`.
|
||||
This workflow file calls two workflow files. The second of these, `workflow-B.yml` (shown in the [example reusable workflow](#example-reusable-workflow)), is passed an input (`username`) and a secret (`token`).
|
||||
|
||||
{% raw %}
|
||||
```yaml{:copy}
|
||||
@@ -191,6 +225,82 @@ jobs:
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
## 次のステップ
|
||||
## Using outputs from a reusable workflow
|
||||
|
||||
A reusable workflow may generate data that you want to use in the caller workflow. To use these outputs, you must specify them as the outputs of the reusable workflow.
|
||||
|
||||
The following reusable workflow has a single job containing two steps. In each of these steps we set a single word as the output: "hello" and "world." In the `outputs` section of the job, we map these step outputs to job outputs called: `output1` and `output2`. In the `on.workflow_call.outputs` section we then define two outputs for the workflow itself, one called `firstword` which we map to `output1`, and one called `secondword` which we map to `output2`.
|
||||
|
||||
{% raw %}
|
||||
```yaml{:copy}
|
||||
name: Reusable workflow
|
||||
|
||||
on:
|
||||
workflow_call:
|
||||
# Map the workflow outputs to job outputs
|
||||
outputs:
|
||||
firstword:
|
||||
description: "The first output string"
|
||||
value: ${{ jobs.example_job.outputs.output1 }}
|
||||
secondword:
|
||||
description: "The second output string"
|
||||
value: ${{ jobs.example_job.outputs.output2 }}
|
||||
|
||||
jobs:
|
||||
example_job:
|
||||
name: Generate output
|
||||
runs-on: ubuntu-latest
|
||||
# Map the job outputs to step outputs
|
||||
outputs:
|
||||
output1: ${{ steps.step1.outputs.firstword }}
|
||||
output2: ${{ steps.step2.outputs.secondword }}
|
||||
steps:
|
||||
- id: step1
|
||||
run: echo "::set-output name=firstword::hello"
|
||||
- id: step2
|
||||
run: echo "::set-output name=secondword::world"
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
We can now use the outputs in the caller workflow, in the same way you would use the outputs from a job within the same workflow. We reference the outputs using the names defined at the workflow level in the reusable workflow: `firstword` and `secondword`. In this workflow, `job1` calls the reusable workflow and `job2` prints the outputs from the reusable workflow ("hello world") to standard output in the workflow log.
|
||||
|
||||
{% raw %}
|
||||
```yaml{:copy}
|
||||
name: Call a reusable workflow and use its outputs
|
||||
|
||||
on:
|
||||
workflow_dispatch:
|
||||
|
||||
jobs:
|
||||
job1:
|
||||
uses: octo-org/example-repo/.github/workflows/called-workflow.yml@v1
|
||||
|
||||
job2:
|
||||
runs-on: ubuntu-latest
|
||||
needs: job1
|
||||
steps:
|
||||
- run: echo ${{ needs.job1.outputs.firstword }} ${{ needs.job1.outputs.secondword }}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
For more information on using job outputs, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idoutputs)."
|
||||
|
||||
## Monitoring which workflows are being used
|
||||
|
||||
You can use the {% data variables.product.prodname_dotcom %} REST API to monitor how reusable workflows are being used. The `prepared_workflow_job` audit log action is triggered when a workflow job is started. Included in the data recorded are:
|
||||
* `repo` - the organization/repository where the workflow job is located. For a job that calls another workflow, this is the organization/repository of the caller workflow.
|
||||
* `@timestamp` - the date and time that the job was started, in Unix epoch format.
|
||||
* `job_name` - the name of the job that was run.
|
||||
* `job_workflow_ref` - the workflow file that was used, in the form `{owner}/{repo}/{path}/{filename}@{ref}`. For a job that calls another workflow, this identifies the called workflow.
|
||||
|
||||
For information about using the REST API to query the audit log for an organization, see "[Organizations](/rest/reference/orgs#get-the-audit-log-for-an-organization)."
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note**: Audit data for `prepared_workflow_job` can only be viewed using the REST API. It is not visible in the {% data variables.product.prodname_dotcom %} web interface, or included in JSON/CSV exported audit data.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
## Next steps
|
||||
|
||||
To continue learning about {% data variables.product.prodname_actions %}, see "[Events that trigger workflows](/actions/learn-github-actions/events-that-trigger-workflows)."
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Customizing your codespace
|
||||
intro: '{% data variables.product.prodname_codespaces %} は自分専用の環境に整えることができます。 You can configure your repositories with a dev container to define their default Codespaces environment, and personalize your development experience across all of your codespaces with dotfiles and Settings Sync.'
|
||||
intro: '{% data variables.product.prodname_codespaces %} is a dedicated environment for you. You can configure your repositories with a dev container to define their default Codespaces environment, and personalize your development experience across all of your codespaces with dotfiles and Settings Sync.'
|
||||
product: '{% data reusables.gated-features.codespaces %}'
|
||||
versions:
|
||||
fpt: '*'
|
||||
@@ -10,8 +10,10 @@ redirect_from:
|
||||
topics:
|
||||
- Codespaces
|
||||
children:
|
||||
- /configuring-codespaces-for-your-project
|
||||
- /personalizing-codespaces-for-your-account
|
||||
- /changing-the-machine-type-for-your-codespace
|
||||
- /setting-your-default-editor-for-codespaces
|
||||
- /setting-your-default-region-for-codespaces
|
||||
- /prebuilding-codespaces-for-your-project
|
||||
---
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: codespace で開発する
|
||||
intro: '専用のクラウド環境でプロジェクト開発を開始するための codespace を作成します。 転送されたポートを使用してアプリケーションを実行したり、{% data variables.product.prodname_vscode %} 内の Codespaces を使用したりすることもできます。'
|
||||
title: Developing in a codespace
|
||||
intro: 'Create a codespace to get started with developing your project inside a dedicated cloud environment. You can use forwarded ports to run your application and even use codespaces inside {% data variables.product.prodname_vscode %}'
|
||||
product: '{% data reusables.gated-features.codespaces %}'
|
||||
versions:
|
||||
fpt: '*'
|
||||
@@ -15,8 +15,7 @@ children:
|
||||
- /using-codespaces-for-pull-requests
|
||||
- /deleting-a-codespace
|
||||
- /forwarding-ports-in-your-codespace
|
||||
- /changing-the-machine-type-for-your-codespace
|
||||
- /using-codespaces-in-visual-studio-code
|
||||
- /using-codespaces-with-github-cli
|
||||
---
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Codespaces を管理する
|
||||
intro: '{% data variables.product.prodname_github_codespaces %} 設定を使用して、codespace に必要な情報を管理できます。'
|
||||
title: Managing your codespaces
|
||||
intro: 'You can use {% data variables.product.prodname_github_codespaces %} settings to manage information that your codespace might need.'
|
||||
product: '{% data reusables.gated-features.codespaces %}'
|
||||
versions:
|
||||
fpt: '*'
|
||||
@@ -14,7 +14,5 @@ children:
|
||||
- /managing-repository-access-for-your-codespaces
|
||||
- /reviewing-your-security-logs-for-codespaces
|
||||
- /managing-gpg-verification-for-codespaces
|
||||
- /setting-your-default-editor-for-codespaces
|
||||
- /setting-your-default-region-for-codespaces
|
||||
---
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
title: 'Setting up your project for {% data variables.product.prodname_codespaces %}'
|
||||
intro: '特定の言語のセットアップや構成など、{% data variables.product.prodname_codespaces %} の使用方法を学びます。'
|
||||
title: 'Setting up your repository for {% data variables.product.prodname_codespaces %}'
|
||||
allowTitleToDifferFromFilename: true
|
||||
intro: 'Learn how to get started with {% data variables.product.prodname_codespaces %}, including set up and configuration for specific languages.'
|
||||
product: '{% data reusables.gated-features.codespaces %}'
|
||||
versions:
|
||||
fpt: '*'
|
||||
@@ -8,6 +9,8 @@ versions:
|
||||
redirect_from:
|
||||
- /codespaces/getting-started-with-codespaces
|
||||
children:
|
||||
- /configuring-codespaces-for-your-project
|
||||
- /setting-up-your-project-for-codespaces
|
||||
- /setting-up-your-nodejs-project-for-codespaces
|
||||
- /setting-up-your-dotnet-project-for-codespaces
|
||||
- /setting-up-your-java-project-for-codespaces
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user