Frecuentemente publicamos actualizaciones de nuestra documentación. Es posible que la traducción de esta página esté en curso. Para conocer la información más actual, visita la documentación en inglés. Si existe un problema con las traducciones en esta página, por favor infórmanos.

Sharing workflows with your organization

Learn how you can use organization features to collaborate with your team, by sharing workflow templates, secrets, and self-hosted runners.

En este artículo

Overview

If you need to share workflows and other GitHub Actions features with your team, then consider collaborating within a GitHub organization. An organization allows you to centrally store and manage secrets, artifacts, and self-hosted runners. You can also create workflow templates in the .github repository and share them with other users in your organization.

Creating a workflow template

Workflow templates can be created by users with write access to the organization's .github repository. The templates can then be used by organization members who have permission to create workflows. Workflow templates can be used to create new workflows in an organizations' public repositories; to use templates to create workflows in private repositories, the organization must be part of an enterprise or GitHub One plan.

This procedure demonstrates how to create a workflow template and metadata file. The metadata file describes how the template is presented to users when they are creating a new workflow.

  1. If it doesn't already exist, create a new public repository named .github in your organization.

  2. Create a directory named workflow-templates.

  3. Create your new workflow file inside the workflow-templates directory.

    If you need to refer to a repository's default branch, you can use the $default-branch placeholder. When a workflow is created using your template, the placeholder will be automatically replaced with the name of the repository's default branch.

    For example, this file named octo-organization-ci.yml demonstrates a basic workflow.

    name: Octo Organization CI
    
    on:
      push:
        branches: [ $default-branch ]
      pull_request:
        branches: [ $default-branch ]
    
    jobs:
      build:
        runs-on: ubuntu-latest
        
        steps:
        - uses: actions/checkout@v2
        
        - name: Run a one-line script
          run: echo Hello from Octo Organization
    
  4. Create a metadata file inside the workflow-templates directory. The metadata file must have the same name as the workflow file, but instead of the .yml extension, it must be appended with .properties.json. For example, this file named octo-organization-ci.properties.json contains the metadata for a workflow file named octo-organization-ci.yml:

    {
        "name": "Octo Organization Workflow",
        "description": "Octo Organization CI workflow template.",
        "iconName": "example-icon",
        "categories": [
            "Go"
        ],
        "filePatterns": [
            "package.json$",
            "^Dockerfile",
            ".*\\.md$"
        ]
    }
    
    • name - Required. The name of the workflow template. This is displayed in the list of available templates.
    • description - Required. The description of the workflow template. This is displayed in the list of available templates.
    • iconName - Required. Defines an icon for the workflow's entry in the template list. The iconName must be an SVG icon of the same name, and must be stored in the workflow-templates directory. For example, a SVG file named example-icon.svg is referenced as example-icon.
    • categories - Optional. Defines the language category of the workflow. When a user views the available templates, those templates that match the same language will feature more prominently. For information on the available language categories, see https://github.com/github/linguist/blob/master/lib/linguist/languages.yml.
    • filePatterns - Optional. Allows the template to be used if the user's repository has a file in its root directory that matches a defined regular expression.

To add another workflow template, add your files to the same workflow-templates directory. For example:

Workflow template files

Using a workflow template

This procedure demonstrates how a member of your organization can find and use a workflow template to create a new workflow. An organization's workflow templates can be used by anyone who is a member of the organization.

  1. En GitHub, visita la página principal del repositorio.
  2. Debajo del nombre de tu repositorio, da clic en Acciones.
    Pestaña de acciones en la navegación del repositorio principal
  3. If your repository already has existing workflows: In the upper-left corner, click New workflow.
    Create a new workflow
  4. Your organization's workflow templates are located in their own section titled "Workflows created by organization name". Under the name of the template you'd like to use, click Set up this workflow.
    Set up this workflow

Sharing secrets within an organization

You can centrally manage your secrets within an organization, and then make them available to selected repositories. This also means that you can update a secret in one location, and have the change apply to all repository workflows that use the secret.

When creating a secret in an organization, you can use a policy to limit which repositories can access that secret. For example, you can grant access to all repositories, or limit access to only private repositories or a specified list of repositories.

Para crear secretos a nivel organizacional, deberás tener acceso de administrador.

  1. En GitHub, navega hasta la página principal de la organización.
  2. Debajo de tu nombre de organización, da clic en Configuración.
    Botón de configuración de organización
  3. En la barra lateral izquierda, haz clic en Secrets (Secretos).
  4. Click New secret.
  5. Type a name for your secret in the Name input box.
  6. Enter the Value for your secret.
  7. From the Repository access dropdown list, choose an access policy.
  8. Click Add secret.

Share self-hosted runners within an organization

Organization admins can add their self-hosted runners to groups, and then create policies that control which repositories can access the group.

For more information, see "Managing access to self-hosted runners using groups."

Next steps

To continue learning about GitHub Actions, see "Security hardening for GitHub Actions."

¿Te ayudó este documento?

Privacy policy

Help us make these docs great!

All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.

Make a contribution

O, learn how to contribute.