Usar o GitHub Packages com o GitHub Actions

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

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

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.

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']

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: [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

- 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

• 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.

   

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.

   

   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.

   

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.

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