Репо не найдено с использованием semantic-release-monorepo в рабочем процессе GitHub Actions

Я создаю рабочий процесс GitHub Actions для создания и публикации пакетов npm в GitHub Packages. Репо - это монорепозиторий с несколькими пакетами, поэтому я использую инструмент semantic-release-monorepo. Однако шаг к публикации не удается, и я не могу понять, почему.

Мой файл рабочего процесса GitHub Actions выглядит следующим образом (немного урезан)

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    env:
      GH_TOKEN: ${{ secrets.MY_PAT }}

    steps:
      - name: Checkout repo
        uses: actions/checkout@v2

        run: |
          yarn install
          yarn build

      - name: Setup node for publishing to Github packages
        uses: actions/setup-node@v2
        env:
          NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          node-version: "12.x"
          registry-url: "https://npm.pkg.github.com"

      - name: Yarn publish packages
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 
        run: |
          yarn publish-packages

yarn publish-packages запускает сценарий, который выполняет команду lerna для семантического выпуска

lerna exec --concurrency 1 -- npx --no-install semantic-release -e semantic-release-monorepo

Я убедился, что репозиторий package.json, а также package.json для каждого пакета имеет правильный URL-адрес репозитория, https://github.com/owner/repo.git. У моего личного токена доступа есть разрешения на репо, запись и удаление пакетов.

Независимо от того, какие конфигурации я меняю, шаг завершается ошибкой со следующими сообщениями:

Команда git push --dry-run --no-verify https: // [secure] @ github.com / xxx / xxx.git HEAD: develop не удалось с сообщением об ошибке remote: Repository not found. 26 фатальный: репозиторий https://github.com/xxx/xxx.git/ не найден.

Второе сообщение

EGITNOPERMISSION: 'semantic-release не может отправить тег версии в ветку develop в удаленном репозитории Git с URL https://[secure]@github.com/xxx/xxx.git

Другие вещи, которые я пробовал:

  • Добавление scope = @ xxx к шагу установки-узла после чтения GH docs, в котором говорится, что GitHub Packages поддерживает только пакеты npm с ограниченной областью действия.
  • Согласно документам по семантическому выпуску, я попытался установить GH_TOKEN, GITHUB_TOKEN и NPM_TOKEN для каждой комбинации моего PAT или GITHUB_TOKEN в секрете. Я считаю, что в документах говорится, что поддерживается только PAT. Кроме того, NPM_TOKEN не требуется, поскольку использование URL-адреса реестра с действием узла настройки создает файл .npmrc, который по умолчанию использует NODE_AUTH_TOKEN.
  • Здесь есть почти аналогичный вопрос , но с добавлением .git к URL-адресу его репозитория кажется, исправил это для него
  • Документы Github говорят, что я могу использовать PAT или GITHUB_TOKEN в качестве токена аутентификации в файле .npmrc, так что это не должно быть проблемой

Я просмотрел документы для semantic-release, semantic-release-monorepo, GitHub Actions и GitHub Packages. Если мне нужно добавить дополнительную информацию, пожалуйста, дайте мне знать.


git github-actions node.js semantic-release
person wizloc    schedule 11.06.2021    source источник

Ответы (1)


arrow_upward
0
arrow_downward

После еще нескольких проб и ошибок я обнаружил причину. Если я правильно понимаю, рабочий процесс Github будет автоматически использовать доступный секрет GITHUB_TOKEN для аутентификации в Github на этапе проверки репо с использованием actions/checkout. Затем он сохранял учетные данные с этого шага и повторно использовал их для шага публикации пакетов, хотя я вводил токен личного доступа в качестве переменной среды на этом шаге.

В конце концов, исправление заключалось в использовании параметра persist-credentials на первом шаге, подобном этому

steps:
  - name: Checkout repo
    uses: actions/checkout@v2
    with:
      persist-credentials: false

А затем с помощью токена личного доступа для аутентификации с помощью GitHub на последнем этапе, как я уже отмечал, я считаю, что это правильный метод в моем вопросе, поскольку документы семантического выпуска утверждают, что поддерживается только аутентификация PAT.

person wizloc    schedule 15.06.2021