Можно ли сохранить WORKDIR между действиями в действиях GitHub?

Question

Сегодня утром я проснулся с бета-приглашением GitHub Actions (wooo) и начал играть с ним с целью перенастроить несколько простых конвейеров сборки, тестирования и развертывания, которые я сейчас использую на CircleCI.

Я все еще пытаюсь разобраться с действиями, но поток, который я имею в виду, заключается в том, что после нажатия первое действие в рабочем процессе запустит контейнер Docker. Внутри этого контейнера я буду запускать несколько простых процессов сборки, таких как минимизация ресурсов и удаление артефактов. Следующее действие затем запустит несколько тестов для сборки. И следующее действие (я) в конвейере будет развернуто в одной из нескольких сред, в зависимости от ветви, к которой я подтолкнул.

Я следовал за документами на https://developer.github.com/actions/creating-github-actions/creating-a-docker-container/ и у меня есть элементарный рабочий процесс, который запускает контейнер Docker и выполняет некоторые команды сборки внутри WORKDIR, Я также могу запустить развертывание (через rsync) из этого WORKDIR тоже.

Тем не менее, я хотел бы разделить это на отдельные шаги / действия, но я не могу найти путь к этому.

По сути, это будет похоже на модель заданий / рабочих процессов CircleCI, которую я использую. Однако в CircleCI первое задание запускает сборку, а затем сохраняет результирующую структуру каталогов на протяжении всего остального рабочего процесса, например:

# Persist dist directory
  - persist_to_workspace:
      root: ~/project
      paths:
        - .

Итак, я как бы приравниваю Рабочие места CircleCI к Действиям GitHub, что может быть не так? По сути, я пытаюсь выяснить, могу ли я WORKDIR внутри контейнера Docker первого Action и сделать это WORKDIR доступны для последующих действий.

Возможно ли это, или я не в силах сделать то, что, по-моему, могут делать GitHub Actions?

Спасибо!

Answer 1

Я отвечаю на этот вопрос сам на случай, если кто-то еще столкнется с этой проблемой (и, как и я, не полностью прочитал документы!).: О)

Документы здесь объясняют, но по существу рабочий каталог любого контейнера, который вы запускаете как часть действия, существует как /github/workspace, Действия могут изменять содержимое этого рабочего каталога, и когда контейнеры запускаются в последующих действиях во время рабочего процесса, рабочий каталог для этих действий / контейнеров будет содержать изменения, сделанные ранее в рабочем процессе.

Итак, ответ да, докер WORKDIR в /github/workspace сохраняется во всем рабочем процессе GitHub Actions аналогично тому, как он может сохраняться в рабочем процессе CircleCI.

Answer 2

В моих сегодняшних тестах он не может сохранять файлы между заданиями. CircleCi делает, там вы можете хранить некоторый контент для чтения при следующих заданиях, но в GitHub Actions я не могу.

Далее мои тесты:

Напишите файл о работе, попробуйте прочитать на следующем

Используемый тестовый файл.

1) Написание наGITHUB_WORKSPACE
Мой путь: /home/runner/work/github-actions-test/github-actions-test)
Результаты: доступно для записи и чтения при первом задании, но пусто для второго задания Ссылка на действие

2) Написание на/github/home
Мой путь: / github / home
Результаты:cannot access '/github/home/Ссылка на действие

3) Написание на/home
Мой путь: / home
Результаты:touch: cannot touch '/home/myFile.txt': Permission denied
Ссылка на действие

Answer 3

Я думаю, что действия / [электронная почта защищена] — это последнее решение.

        - name: Create a file
    run: echo "I won't live long" > my_file.txt

  - name: Upload Artifact
    uses: actions/upload-artifact@v3
    with:
      name: my-artifact
      path: my_file.txt
      retention-days: 5

Пример реального мираmdn/contentрепо:

1. Сборка и загрузка происходит в pr-test.yml
2. Сборка загружается и развертывается в pr-review-companion.yml.

Answer 4

Я пробовал action/upload-artifact@v3 , но для больших файлов, таких как артефакт размером 1 ГБ, сжатие и загрузка занимает около 40 минут.

Я бы предложил использовать action/cache@v3 для обмена файлами между заданиями, которые занимают ~2 минуты.

      
name: build-deploy

on:
  push:
    branches: [ production ]
  workflow_dispatch:

jobs:

  your-job-1:
      runs-on: ubuntu-latest
      name: 'build'

      steps:
      - name: Cache Build
        id: cache-build
        uses: actions/cache/save@v3
        with:
          path: ${{ github.workspace }}/your-folder-to-cache
          key: ${{ github.sha }}-your-cache-key

  your-job-2:
      runs-on: ubuntu-latest
      name: 'deploy'

      steps:
      - uses: actions/cache/restore@v3
        id: restore-build
        with:
          path: ${{ github.workspace }}/your-folder-to-cache
          key: ${{ github.sha }}-your-cache-key

  cleanup:
      runs-on: ubuntu-latest
      needs: ['your-job-1', 'your-job-2']
      name: 'cache cleanup'

      steps:
      - uses: adapttive/cache-delete
        with:
          github-token: ${{ secrets.ADMIN_GITHUB_TOKEN }}
          cache-key: ${{ github.sha }}-your-cache-key 

Кроме того, вы можете использовать мое действие Adaptive/cache-Delete вcleanupзадание по удалению кэша после развертывания.