From 06ba9dd64fd83f279cc89e3b3c4954259b98ec2a Mon Sep 17 00:00:00 2001 From: Mahdiar Naufal <133770311+mahdiar-naufal-shyftplan@users.noreply.github.com> Date: Mon, 18 Sep 2023 13:37:48 +0200 Subject: [PATCH] Update reusing-workflows.md (#26519) Co-authored-by: hubwriter --- content/actions/using-workflows/reusing-workflows.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/actions/using-workflows/reusing-workflows.md b/content/actions/using-workflows/reusing-workflows.md index 1bd67dd812..2f048b328a 100644 --- a/content/actions/using-workflows/reusing-workflows.md +++ b/content/actions/using-workflows/reusing-workflows.md @@ -265,6 +265,7 @@ When you call a reusable workflow, you can only use the following keywords in th - If `jobs..permissions` is not specified in the calling job, the called workflow will have the default permissions for the `GITHUB_TOKEN`. For more information, see "[AUTOTITLE](/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)." - The `GITHUB_TOKEN` permissions passed from the caller workflow can be only downgraded (not elevated) by the called workflow. + - If you use `jobs..concurrency.cancel-in-progress: true`, don't use the same value for `jobs..concurrency.group` in the called and caller workflows as this will cause the workflow that's already running to be cancelled. A called workflow uses the name of its caller workflow in {% raw %}${{ github.workflow }}{% endraw %}, so using this context as the value of `jobs..concurrency.group` in both caller and called workflows will cause the caller workflow to be cancelled when the called workflow runs. {% endnote %}