Publicamos atualizações frequentes em nossa documentação, e a tradução desta página ainda pode estar em andamento. Para obter as informações mais recentes, acesse a documentação em inglês. Se houver problemas com a tradução desta página, entre em contato conosco.

Usar o GitHub Packages com o GitHub Actions

É possível configurar um fluxo de trabalho no GitHub Actions para publicar ou instalar automaticamente um pacote do GitHub Package Registry.

GitHub Package Registry is available with GitHub Free, GitHub Pro, GitHub Free for organizations, GitHub Team, GitHub Enterprise Cloud, GitHub Enterprise Server 2.22, GitHub One, and GitHub AE.


O GitHub Package Registry não está disponível para repositórios privados de contas que utilizam planos antigos por-repositório. GitHub Package Registry está disponível com GitHub Free, GitHub Pro, GitHub Free para organizações, GitHub Team, GitHub Enterprise Cloud e GitHub One. Para obter mais informações, consulte "[produtos de GitHub](/articles/github-s-products)

Neste artigo

Sobre GitHub Package Registry com GitHub Actions

O GitHub Actions ajuda você a automatizar seus fluxos de trabalho de desenvolvimento de software no mesmo lugar que você armazena o código e colabora em pull requests e problemas. Você pode escrever tarefas individuais, chamadas de ações e combiná-las para criar um fluxo de trabalho personalizado. Com o GitHub Actions, você pode criar recursos completos de integração contínua (CI, Continuous Integration) e implantação contínua (CD, Continuous Deployment) diretamente no seu repositório. Para obter mais informações, consulte "Sobre GitHub Actions".

Você pode estender os recursos de CI e CD do seu repositório publicando ou instalando pacotes como parte do seu fluxo de trabalho.

Autenticar-se no Registro de contêiner do GitHub

Nota: Registro de contêiner do GitHub está atualmente em versão beta público e sujeito a alterações. Durante o beta, o armazenamento e a banda larga são grátis. Para usar Registro de contêiner do GitHub, você precisa habilitar a pré-visualização de recursos. Para obter mais informações, consulte "Sobre Registro de contêiner do GitHub" e "Habilitar melhor suporte ao contêiner".

Os PATs podem conceder amplo acesso à sua conta. You should select only the necessary read:packages, write:packages, or delete:packages scope when creating a PAT to authenticate to the registro de contêiner.

To authenticate to Registro de contêiner do GitHub within a GitHub Actions workflow, use the GITHUB_TOKEN for the best security and experience.

For guidance on updating your workflows that authenticate to ghcr.io with a personal access token, see "Upgrading a workflow that accesses ghcr.io."

Registro de contêiner do GitHub now supports GITHUB_TOKEN for easy and secure authentication in your workflows. If your workflow is using a personal access token (PAT) to authenticate to ghcr.io, then we highly recommend you update your workflow to use GITHUB_TOKEN.

For more information about GITHUB_TOKEN, see "Encrypted secrets" and "Authentication in a workflow."

Se você desejar usar o registro de contêiner em ações durante a versão beta, siga nossas práticas de segurança recomendadas para o uso do PAT emFortalecimento da segurança para o GitHub Actions".

Para um exemplo de autenticação, consulte "Efetuar a autenticação com o registro de contêiner".

Efetuar a autenticação nos registros do pacote em GitHub

Se você deseja que o fluxo de trabalho efetue a autenticação em GitHub Package Registry para acessar um registro de pacotes diferentes do registro de contêiner em GitHub, recomendamos usar o GITHUB_TOKEN que GitHub cria automaticamente para o seu repositório quando você habilita GitHub Actions em vez de um token de acesso pessoal para autenticação. O GITHUB_TOKEN tem escopos read:packages e write:packages do repositório atual. Para bifurcações, o token também tem o escopo read:packages para o repositório principal.

Você pode fazer referência ao GITHUB_TOKEN no seu arquivo de fluxo de trabalho usando o contexto {{secrets.GITHUB_TOKEN}}. Para obter mais informações, consulte "Permissões para o GITHUB_TOKEN".

About permissions and package access for repository-owned packages

Note: Repository-owned packages include RubyGems, npm, Apache Maven, NuGet, Gradle, and Docker packages that use the package namespace docker.pkg.github.com.

Quando você habilita o GitHub Actions, o GitHub instala um aplicativo GitHub no repositório. The GITHUB_TOKEN secret is a GitHub App installation access token. You can use the installation access token to authenticate on behalf of the GitHub App installed on your repository. As permissões do token são restritas ao repositório do fluxo de trabalho. For more information, see "Permissions for the GITHUB_TOKEN."

GitHub Package Registry allows you to push and pull packages through the GITHUB_TOKEN available to a GitHub Actions workflow.

About permissions and package access for registro de contêiner

The registro de contêiner (ghcr.io) allows users to create and administer containers as free-standing resources at the organization level. Containers can be owned by an organization or personal user account and you can customize access to each of your containers separately from repository permissions.

All workflows accessing the registro de contêiner should use the GITHUB_TOKEN instead of a personal access token. For more information about security best practices, see "Security hardening for GitHub Actions."

Default permissions and access settings for containers modified through workflows

When you create, install, modify, or delete a container through a workflow, there are some default permission and access settings used to ensure admins have access to the workflow. You can adjust these access settings as well.

For example, by default if a workflow creates a container using the GITHUB_TOKEN, then:

  • The container inherits the visibility and permissions model of the repository where the workflow is run.
  • Repository admins where the workflow is run become the admins of the container once the container is created.

These are more examples of how default permissions work for workflows that manage packages.

GitHub Actions workflow taskDefault permissions and access
Download an existing container- If the container is public, any workflow running in any repository can download the container.
- If the container is internal, then all workflows running in any repository owned by the Enterprise account can download the container. For enterprise-owned organizations, you can read any repository in the enterprise
- If the container is private, only workflows running in repositories that are given read permission on that container can download the container.
Upload a new version to an existing container- If the container is private, internal, or public, only workflows running in repositories that are given write permission on that container can upload new versions to the container.
Delete a container or versions of a container- If the container is private, internal, or public, only workflows running in repositories that are given delete permission can delete existing versions of the container.

You can also adjust access to containers in a more granular way or adjust some of the default permissions behavior. Para obter mais informações, consulte "Configurar controle de acesso e visibilidade para imagens de contêiner".

Publicar um pacote usando uma ação

Você pode usar GitHub Actions para publicar automaticamente pacotes como parte do fluxo de integração contínua (CI). Esta abordagem da implantação contínua (CD) permite que você automatize a criação de novas versões do pacote, se o código atender aos seus padrões de qualidade. Por exemplo, você pode criar um fluxo de trabalho que executa testes CI toda vez que um desenvolvedor faz push do código para um branch específico. Se os testes passarem, o fluxo de trabalho poderá publicar uma nova versão do pacote em GitHub Package Registry.

As etapas de configuração variam de acordo com o cliente do pacote. Para obter informações gerais sobre a configuração de um fluxo de trabalho para GitHub Actions, consulte "Configurar um fluxo de trabalho."

O exemplo a seguir demonstra como você pode usar GitHub Actions para criar e testar seu aplicativo e, em seguida, criar automaticamente uma imagem do Docker e publicá-la em GitHub Package Registry:

  • Crie um novo arquivo de fluxo de trabalho no repositório (como .github/workflows/deploy-image.yml) e adicione o YAML a seguir:

    YAML
    name: Create and publish a package
    on:
      push:
        branches: ['release']
    jobs:
      run-npm-build:
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v2
          - name: npm install and build webpack
            run: |
              npm install
              npm run build
          - uses: actions/upload-artifact@main
            with:
              name: webpack artifacts
              path: public/
    
      run-npm-test:
        runs-on: ubuntu-latest
        needs: run-npm-build
        strategy:
          matrix:
            os: [ubuntu-latest]
            node-version: [12.x, 14.x]
        steps:
          - uses: actions/checkout@v2
          - name: Use Node.js ${{ matrix.node-version }}
            uses: actions/setup-node@v1
            with:
              node-version: ${{ matrix.node-version }}
          - uses: actions/download-artifact@main
            with:
              name: webpack artifacts
              path: public
          - name: npm install, and test
            run: |
              npm install
              npm test
            env:
              CI: true
    
      build-and-push-image:
        runs-on: ubuntu-latest
        needs: run-npm-test
        steps:
        - name: Checkout
          uses: actions/checkout@v2
        - name: Build container image
          uses: docker/build-push-action@v1
          with:
            username: ${{ github.actor }}
            password: ${{ secrets.GITHUB_TOKEN }}
            registry: docker.pkg.github.com
            repository: ${{ github.repository }}/octo-image
            tag_with_sha: true
            tag_with_ref: true

As configurações relevantes são explicadas na seguinte tabela:

on:
  push:
    branches: ['release']
Configura o fluxo de trabalho Criar e publicar um pacote para ser executado toda vez que uma alteração é enviada para o branch denominado versão.
run-npm-build:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v2
    - name: npm install and build webpack
      run: |
        npm install
        npm run build
    - uses: actions/upload-artifact@main
      with:
        name: webpack artifacts
        path: public/
Este trabalho instala o NPM e o usa para criar o aplicativo.
run-npm-test:
  runs-on: ubuntu-latest
  needs: run-npm-build
  strategy:
    matrix:
      os: [ubuntu-latest]
      node-version: [14.x]
  steps:
    - uses: actions/checkout@v2
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v1
      with:
        node-version: ${{ matrix.node-version }}
    - uses: actions/download-artifact@main
      with:
        name: webpack artifacts
        path: public
    - name: npm install, and test
      run: |
        npm install
        npm test
      env:
        CI: true
Este trabalho usa teste do npm para testar o código. O comando needs: run-npm-build torna esse trabalho dependente do trabalho run-npm-build.
- name: Build container image
Cria uma nova etapa denominada Build container image. Esta etapa é executada como parte do trabalho build-and-push-image. O comando needs: run-npm-test torna essa tarefa dependente do trabalho run-npm-test.
uses: docker/build-push-action@v1
Usa a ação build-push-action do Docker para criar a imagem com base no arquivo Docker do seu repositório. Se a criação for bem-sucedida, ela faz p push da imagem para GitHub Package Registry.
with:
Envia os parâmetros necessários para a ação build-push-action. Isto é definido nas linhas subsequentes.
username: ${{ github.actor }}
Define a conta de usuário que publicará os pacotes. Uma vez publicados, os pacotes pertencem à conta definida aqui.
password: ${{ secrets.GITHUB_TOKEN }}
Define a senha usada para acessar GitHub Package Registry.
registry: docker.pkg.github.com
Define o registro que hospedará os pacotes resultantes. This example uses GitHub Package Registry. If you're using the registro de contêiner, then use ghcr.io as the hostname.
repository: ${{ github.repository }}/octo-image
Define qual repositório hospedará o pacote resultante e define o nome do pacote publicado. Substitui octo-image pelo nome que você deseja para o seu pacote.
tag_with_sha: true
Marca o pacote publicado com os primeiros sete caracteres do SHA do commit. Por exemplo, sha-2f2d842.
tag_with_ref: true
Tags o pacote publicado com a referência do Git. Este pode ser o nome do branch usado para criar o pacote.
  • Este novo fluxo de trabalho será executado automaticamente toda vez que você fizer uma alteração em uma versão nomeada do branch no repositório. Você pode visualizar o progresso na aba Ações.
  • Alguns minutos após a conclusão do fluxo de trabalho, o novo pacote ficará visível no seu repositório. Para encontrar seus pacotes disponíveis, consulte "Visualizar os pacotes de um repositório".

Instalar um pacote usando uma ação

Você pode instalar pacotes como parte de seu fluxo de CI usando o GitHub Actions. Por exemplo, você poderia configurar um fluxo de trabalho para que sempre que um desenvolvedor fizesse push do código para um pull request, o fluxo de trabalho resolveria as dependências, fazendo o download e instalando pacotes hospedados pelo GitHub Package Registry. Em seguida, o fluxo de trabalho pode executar testes de CI que exigem as dependências.

Installing packages hosted by the GitHub Package Registry through GitHub Actions requires minimal configuration or additional authentication when you use the GITHUB_TOKEN. Data transfer is also free when an action installs a package. Para obter mais informações, consulte "Sobre a cobrança do GitHub Package Registry".

As etapas de configuração variam de acordo com o cliente do pacote. Para obter informações gerais sobre a configuração de um fluxo de trabalho para GitHub Actions, consulte "Configurar um fluxo de trabalho."

Upgrading a workflow that accesses ghcr.io

Registro de contêiner do GitHub now supports GITHUB_TOKEN for easy and secure authentication in your workflows. If your workflow is using a personal access token (PAT) to authenticate to ghcr.io, then we highly recommend you update your workflow to use GITHUB_TOKEN.

For more information about GITHUB_TOKEN, see "Encrypted secrets" and "Authentication in a workflow."

Using the GITHUB_TOKEN instead of a PAT, which includes the repo scope, increases the security of your repository as you don't need to use a long-lived PAT that offers unnecessary access to the repository where your workflow is run. For more information about security best practices, see "Security hardening for GitHub Actions."

  1. Navigate to your package landing page.

  2. In the left sidebar, click Actions access.

    "Actions access" option in left menu

  3. To ensure your container package has access to your workflow, you must add the repository where the workflow is stored to your container. Click Add repository and search for the repository you want to add.

    "Add repository" button

    Note: Adding a repository to your container through the Actions access menu option is different than connecting your container to a repository. For more information, see "Ensuring workflow access to your package" and "Connecting a repository to a container image."

  4. Optionally, using the "role" drop-down menu, select the default access level that you'd like the repository to have to your container image.

    Permission access levels to give to repositories

  5. Open your workflow file. On the line where you login to ghcr.io, replace your PAT with ${{ secrets.GITHUB_TOKEN }}.

For example, this workflow publishes a Docker container using ${{ secrets.GITHUB_TOKEN }} to authenticate.

YAML
name: Demo Push

on:   
  push:
    # Publish `master` as Docker `latest` image.
    branches:
      - master
      - seed

    # Publish `v1.2.3` tags as releases.
    tags:
      - v*

  # Run tests for any PRs.
  pull_request:

env:
  IMAGE_NAME: ghtoken_product_demo

jobs:
  # Push image to GitHub Packages.
  # See also https://docs.docker.com/docker-hub/builds/
  push:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - name: Build image
        run: docker build . --file Dockerfile --tag $IMAGE_NAME --label "runnumber=${GITHUB_RUN_ID}"

      - name: Log into registry
        # This is where you will update the PAT to GITHUB_TOKEN
        run: echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin

      - name: Push image
        run: |
          IMAGE_ID=ghcr.io/${{ github.repository_owner }}/$IMAGE_NAME

          # Change all uppercase to lowercase
          IMAGE_ID=$(echo $IMAGE_ID | tr '[A-Z]' '[a-z]')
          # Strip git ref prefix from version
          VERSION=$(echo "${{ github.ref }}" | sed -e 's,.*/\(.*\),\1,')
          # Strip "v" prefix from tag name
          [[ "${{ github.ref }}" == "refs/tags/"* ]] && VERSION=$(echo $VERSION | sed -e 's/^v//')
          # Use Docker `latest` tag convention
          [ "$VERSION" == "master" ] && VERSION=latest
          echo IMAGE_ID=$IMAGE_ID
          echo VERSION=$VERSION
          docker tag $IMAGE_NAME $IMAGE_ID:$VERSION
          docker push $IMAGE_ID:$VERSION

Esse documento ajudou você?

Privacy policy

Ajude-nos a tornar esses documentos ótimos!

Todos os documentos do GitHub são de código aberto. Você percebeu que algo que está errado ou não está claro? Envie um pull request.

Faça uma contribuição

Ou, aprenda como contribuir.