Github actions: базовые понятия. что это такое и как удаленно прогонять…

Тогда о чём пост?

Flutter. Мы настроим не абстрактный CI в вакууме. Мы сделаем такой пайплайн, с которым ваше Flutter-приложение будет чувствовать себя хорошо. Поэтому затронем некоторые специфичные моменты, касающиеся конкретного фреймворка
Деньги. Github Actions — очень доступный сервис. Вы получаете бесплатный безлимит для публичных репозиториев и 2 000 бесплатных минут в месяц для приватных (что немало). И всё-таки мы сделаем упор на то, чтобы реализовать нужные сценарии максимально эффективно при минимальных затратах.
Деплой. Flutter при компиляции чудесным образом превращается в Android и iOS сборки, которые нужно как-то подписывать и деплоить. Это совсем не простой этап, который, тем не менее, мы тоже реализуем в рамках этого поста.

Добавление ключей

Итак, когда вы создали ключи, их нужно добавить на хостинг и в репозиторий. Как именно устроено это на разных хостингах, я знать не могу, но покажу на примере cPanel, как это выглядит.

Скриншот из cPanel, доступ по SSH

Добавляем id_rsa.pub в публичные ключи репозитория, если потребуется, авторизуем его (просто нажатием кнопки), и сохраняем.

Теперь идем в репозиторий GitHub, переходим в Settings, оттуда переходим в Secrets. Внутри нужно будет назвать секрет и ввести приватный ключ (сохраните его заранее в буфер обмена). Называйте ключ просто – key, вставляйте ключ и сохраняйте.

Готово, оба ключа введены и должны работать.

Sending values to the pre and post actions

You can use the command to create environment variables for sharing with your workflow’s or actions. For example, you can create a file with the action, pass the file location to the action, and then use the action to delete the file. Alternatively, you could create a file with the action, pass the file location to the action, and also use the action to delete the file.

If you have multiple or actions, you can only access the saved value in the action where was used. For more information on the action, see «.»

The command can only be run within an action, and is not available to YAML files. The saved value is stored as an environment value with the prefix.

This example uses JavaScript to run the command. The resulting environment variable is named with the value of :

The variable is then exclusively available to the cleanup script running under the action. This example runs in and uses JavaScript to display the value assigned to the environment variable:

Бэкапы баз данных

Какие шансы, что вы не потеряете свои данные в случае, если совершаете по 2-3 обновления в неделю, многие из которых мигрируют базу?

Спойлер: шансов немного

Поэтому практически сразу встал вопрос о том, как автоматизировать создание бэкапов баз данных. Тем более, когда их несколько, а варианты с готовыми системами управления либо дорогие, либо очень дорогие. И вновь на помощь приходит Github Actions!

В прошлом примере мы рассматривали подключение к серверу и выполнение некоторых скриптов. Кажется, это нам и нужно, ведь порты к базам данных закрыты и извне подключаться к ним – идея не очень хорошая.

Начнем с разметки каталогов на сервере: в корне создадим каталог , внутри него — и .

В каталоге создадим маленький скрипт:

Это максимум, который удалось реализовать за 15 минут, загуглив общий синтаксис sh-скриптов. Но этого нам хватит. Сохраним файл под именем .

Теперь переходим к репозиторию и создадим новый workflow по аналогии выше:

К слову, тут появился новый для этого материала тип триггера – . Данный вид триггеров запускается по расписанию, а вот время запуска описано в формате «cron» (https://ru.wikipedia.org/wiki/Cron): многим ненавидимый, но в то же время прекрасный формат, позволяющий прописывать правило времени.

Итак, что мы имеем по итогу: раз в сутки (в полночь по UTC) на Github срабатывает триггер и запускает экшен, который, в свою очередь, устанавливает соединение с нашим сервером и выполняет скрипт запуска нашего бэкап-скрипта. Бэкап-скрипт пробегается по контейнерам с базами данных и создает бэкапы в соответствующих каталогах. Также у нас есть возможность создать резервные бэкапы вручную со страницы соответствующего workflow. Все, что вам останется – придумать, куда отправлять бэкапы на долгосрочное хранение.

К слову, автоматизированное создание бэкапов из 5 контейнеров занимает у нас 13-15 секунд вместе с подключением к серверу. Неплохо, не правда ли?

The components of GitHub Actions

You can configure a GitHub Actions workflow to be triggered when an event occurs in your repository, such as a pull request being opened or an issue being created. Your workflow contains one or more jobs which can run in sequential order or in parallel. Each job will run inside its own virtual machine runner, or inside a container, and has one or more steps that either run a script that you define or run an action, which is a reusable extension that can simplify your workflow.

Workflows

A workflow is a configurable automated process that will run one or more jobs. Workflows are defined by a YAML file checked in to your repository and will run when triggered by an event in your repository, or they can be triggered manually, or at a defined schedule.

Your repository can have multiple workflows in a repository, each of which can perform a different set of steps. For example, you can have one workflow to build and test pull requests, another workflow to deploy your application every time a release is created, and still another workflow that adds a label every time someone opens a new issue.

You can reference a workflow within another workflow, see «Reusing workflows.»

Events

An event is a specific activity in a repository that triggers a workflow run. For example, activity can originate from GitHub when someone creates a pull request, opens an issue, or pushes a commit to a repository. You can also trigger a workflow run on a schedule, by , or manually.

For a complete list of events that can be used to trigger workflows, see Events that trigger workflows.

Jobs

A job is a set of steps in a workflow that execute on the same runner. Each step is either a shell script that will be executed, or an action that will be run. Steps are executed in order and are dependent on each other. Since each step is executed on the same runner, you can share data from one step to another. For example, you can have a step that builds your application followed by a step that tests the application that was built.

You can configure a job’s dependencies with other jobs; by default, jobs have no dependencies and run in parallel with each other. When a job takes a dependency on another job, it will wait for the dependent job to complete before it can run. For example, you may have multiple build jobs for different architectures that have no dependencies, and a packaging job that is dependent on those jobs. The build jobs will run in parallel, and when they have all completed successfully, the packaging job will run.

Actions

An action is a custom application for the GitHub Actions platform that performs a complex but frequently repeated task. Use an action to help reduce the amount of repetitive code that you write in your workflow files. An action can pull your git repository from GitHub, set up the correct toolchain for your build environment, or set up the authentication to your cloud provider.

You can write your own actions, or you can find actions to use in your workflows in the GitHub Marketplace.

Runners

A runner is a server that runs your workflows when they’re triggered. Each runner can run a single job at a time. GitHub provides Ubuntu Linux, Microsoft Windows, and macOS runners to run your workflows; each workflow run executes in a fresh, newly-provisioned virtual machine. If you need a different operating system or require a specific hardware configuration, you can host your own runners. For more information about self-hosted runners, see «Hosting your own runners.»

Советы и напутствия

Настраивайте workflow в публичном репозитории. Если вы настраиваете workflow для приватного репозитория, сконфигурируйте его сперва в публичном, а затем перенесите в приватный. Так вы сэкономите драгоценные бесплатные минуты билд-тайма вашего тарифного плана. Ведь проблемы, из-за которых вам придётся снова и снова перезапускать workflow при настройке, у вас обязательно будут.
Реализуйте step’ы в отдельных shell-скриптах. Сложный workflow становится нагляднее. К тому же упрощается ручной запуск скриптов на машине для быстрой проверки. В тестовом примере я не всегда соблюдал эту рекомендацию для упрощения.
Следите за Run Duration вашего workflow. Обычно время исполнения одного и того же workflow почти не меняется от запуска к запуску, если на то нет объективных причин. В деталях каждого исполненного workflow можно увидеть, сколько минут и секунд заняло исполнение каждого отдельного step’а. Самой времязатратной всегда будет сама сборка артефакта. Установка Flutter SDK тоже займёт не меньше минуты. Нормальное время сборки для маленького проекта — 5-6 минут.

в репозитории с тестовым приложениемSurfрепозитории SurfGear

Пишем файл для деплоя

Чтобы сделать собственно сам деплой, то есть дать понять гиту, что при изменении кода надо залить его на удаленный сервер, нам нужно написать скрипт на языке Yaml. Ниже я приложу код, вникать в него вовсе необязательно, но ниже я укажу действительно важные моменты.

Итак, название файла deploy.yml
Внутри также указан name: Deploy
А далее указано действие, по которому сработает скрипт — . То есть, когда вы будете пушить что-то в ветку main – сработает скрипт. Конечно, если у вас другая ветка – можете поменять ее.
Далее указана «работа», или же jobs. Там описано, где именно будет запускаться все это и как. А также указан путь к ключам, как . Как раз тут и указано наше название ключа, key, которое мы писали в секретах.

И самая интересная для нас часть кода — это build и deploy.

Первая строка по факту равноценна привычному , просто через ci установить все это на гите быстрее. Вторая же строка — это строка опциональная. Если у вас в проекте есть npm-скрипт build — используйте. Если у вас вообще нет npm-скриптов — удалите эти строчки.

Ну а здесь происходит буквально деплой данных. Сперва, командой мы переходим в папку app (опять же, абсолютно опциональная вещь, если у вас просто нет папки app и никуда не надо переходить – можно убрать эту команду). Ну и далее для нас важна только строка, указывающая, куда все это деплоить:

Это полный путь к моему серверу, причем в конце еще и указан адрес конкретного сайта, в данном случае blog.maxgraph.ru. Если вдруг вы не знаете этот путь – можете уточнить у поддержки вашего хостинга. И будьте внимательны, чтобы случайно не задеплоить данные не туда, куда надо, ведь подобный деплой полностью затирает то, что было ранее.

Tips and FAQ

️ Create SSH Deploy Key

Generate your deploy key with the following command.

ssh-keygen -t rsa -b 4096 -C "$(git config user.email)" -f gh-pages -N ""
# You will get 2 files:
#   gh-pages.pub (public key)
#   gh-pages     (private key)

Next, Go to Repository Settings

Go to Deploy Keys and add your public key with the Allow write access
Go to Secrets and add your private key as

Add your public key	Success

Add your private key	Success

️ First Deployment with

The has limitations for the first deployment so we have to select the GitHub Pages branch on the repository settings tab. After that, do the second deployment like the following pictures.

First deployment failed	Go to the settings tab

Select branch	Deploying again and succeed

️ Use the latest and specific release

We recommend you to use the latest and specific release of this action for stable CI/CD.
It is useful to watch this repository (release only) to check the latest release of this action.

For continuous updating, we can use the GitHub native Dependabot.
Here is an example configuration of the bot. The config file is located in .

version: 2
updates:
- package-ecosystem: "github-actions"
  directory: "/"
  schedule:
    interval: "daily"
  labels:
  - "CI/CD"
  commit-message:
    prefix: ci

See the official documentation for more details about the Dependabot: Keeping your dependencies updated automatically — GitHub Docs

️ Schedule and Manual Deployment

For deploying regularly, we can set the workflow trigger.
See

For deploying manually, we can set the workflow trigger.
See

name: GitHub Pages

on:
  push:
    branches:
      - main
  schedule:
    - cron: "22 22 * * *"
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-20.04
    concurrency:
      group: $` github`.`workflow `-$` github`.`ref `
    steps:
    ...

Environment Files

During the execution of a workflow, the runner generates temporary files that can be used to perform certain actions. The path to these files are exposed via environment variables. You will need to use UTF-8 encoding when writing to these files to ensure proper processing of the commands. Multiple commands can be written to the same file, separated by newlines.

Warning: On Windows, legacy PowerShell () does not use UTF-8 by default. Make sure you write files using the correct encoding. For example, you need to set UTF-8 encoding when you set the path:

Or switch to PowerShell Core, which defaults to UTF-8:

More detail about UTF-8 and PowerShell Core found on this great Stack Overflow answer:

Компоненты Workflow

Рабочий процесс (воркфлоу) состоит из четырех компонентов:

статусы (Statuses);
переходы между статусами (Transitions);
исполнители (Assignees);
решения (резолюшны или Resolutions).

Чтобы наглядно проиллюстрировать компоненты, разберем рабочий процесс на примере отслеживания книг в обычной библиотеке. Каждая библиотечная книга — это аналог задачи нашего производства.

Рабочий процесс (Workflow) для отслеживания книг в библиотеке.

Статусы

Статусы указывают, где задача находится в рабочем процессе, и эти статусы должны быть уникальными. В примере рабочего процесса библиотеки книга может находиться в одном из трех состояний: «в библиотеке» (at library), «у читателя» (with customer) или «снята с учета» (retired). Если вы настроите свои переходы как двунаправленные, любая задача сможет проходить через один и тот же статус несколько раз ().

Статусы бывают двух видов: нерешенные — unresolved (открытые) и решенные — resolved (закрытые). Статус «снята с учета» — закрытый, а «в библиотеке» и «у читателя» — открытые.

В качестве других распространенных открытых статусов часто используют:

«Открыто».
«В работе».
«На проверке».
«В планировании».
«Ожидает анализа» и т.д.

Примеры типовых закрытых статусов:

«Отправлено».
«Опубликовано».
«Закрыто».
«Сдано».
«Принято» и т.д.

Переходы

Переходы отражают предпринимаемые действия и определяют способ движения задачи от статуса к статусу. Они вроде дороги, соединяющей два города, — могут быть односторонними или двунаправленными. Можно разрешить задачам переходить из одного статуса в несколько других (на выбор). Это позволяет разрабатывать Workflow для свободно текущих процессов, в которых есть несколько возможных последующих шагов для решения проблемы.

Пример Workflow для свободно текущего процесса.

Можно настроить переходы так, чтобы задачи шли по строго определенному пути. Это позволяет отразить более регламентированные процессы.

Пример Workflow для жесткого процесса, где задачи идут по строго определенному пути.

В примере нашего рабочего процесса библиотечная книга не может быть снята с учета, пока она находится у читателя. Сначала книге должны присвоить статус «в библиотеке».

Исполнитель

Исполнитель — это ответственный за задачу. В примере с библиотекой мы бы назначали исполнителем читателя каждый раз, когда ему выдают книгу во временное пользование. Благодаря этому библиотекари знают, у кого из читателей сейчас находится эта книга.

Решения (резолюшны)

В решениях объясняется, почему проблема перешла из открытого статуса в закрытый. При выводе книги из обращения ее удаляют из инвентаря — переводят в закрытый статус «снята с учета». Таким образом выносят решение (резолюшн) по этой книге. Могут быть другие решения: «повреждено», «устарело» или «потеряно».

Выполнение кода в контейнере

Мы определили как скрипт bash, при этом можно было выполнить скрипт Node, модуль Python, да все, что угодно.

В нашем случае вместо написания кода для сборки и отправки сайта Storybook на GitHub Pages, мы используем storybook-deployer. Извиняюсь за некоторый подвох. Он не завершен, потому что, как видите, предполагает много элементов, относящихся к самому проекту. Например, в нем используется npm, а не yarn.

#!/bin/sh -lcd $GITHUB_WORKSPACE# Установка deployernpm install --save-dev @storybook/storybook-deployer# Установка других зависимостейnpm installexport GH_TOKEN=${1}export BRANCH=${2}# Развертывание страниц GitHubnpx storybook-to-ghpages --host-token-env-variable=GH_TOKEN --branch=$BRANCH --ci

Развертывание сайта Storybook происходит следующими этапами:

Установка зависимости .
Выполнение с правильными аргументами ветки и токена.

Весь код готового экшена находится на GitHub.

Использование экшена в рабочем потоке GitHub

Рассмотрим применение этого экшена в репозитории, где Storybook используется для сборки и развертывания сайта в ветке при каждой передаче в мастер-ветку.

В репозитории, расположенном в , нужно создать файл рабочего потока:

name: Deploy to GitHub Pageson: push:   branches:     masterjobs: build:   runs-on: ubuntu-latest   steps:     - uses: actions/checkout@v2     - name: Install dependencies       run: npm install     - name: Deploy storybook to Github Pages       uses: deborah-digges/[email protected]       with:         access-token: $` github`.`actor `:$` secrets`.`GITHUB_TOKEN `

Мы указываем, что данный рабочий поток должен выполняться при каждой push в ветку master. У него одна задача — , которая разделена на три шага:

Переключение на репозиторий при помощи экшена .
Установка зависимостей через выполнение скрипта.
Развертывание сайта Storybook на GitHub Pages, используя только что созданный экшен.

Мы ссылаемся на экшен при помощи инструкции , которая включает:

Владельца или название организации;
Название репозитория;
Версию, которая может быть тегом или ID коммита в репозитории.

Чтобы увидеть этот рабочий поток в действии, загляните в данный репозиторий, который с помощью созданного экшена развертывает сайт Storybook на GitHub Pages.

Есть ли смысл создавать экшен?

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

Чтобы лучше это понять, важно помнить, что шаг в рабочем процессе может быть:

Экшеном, инкапсулирующим логику, активируемую при помощи вводных инструкций.
Командой bash, выполняемой самим рабочим процессом.

В данном случае количество переиспользуемой логики в созданном нами экшене невелико, и он представляет собой просто тонкую обертку вокруг уже существующего инструмента . Этот инструмент можно было бы просто выполнить прямо внутри рабочего потока.

При изменении файла рабочего процесса для выполнения кода экшена мы получаем тот же результат без необходимости создавать и обслуживать новый экшен в репозитории.

name: Deploy to GitHub Pageson: push:   branches:     masterjobs: build:   runs-on: ubuntu-latest   steps:     - uses: actions/checkout@v2     - name: Install dependencies       run: npm install     - name: Deploy storybook to Github Pages       run: npm install --save-dev @storybook/storybook-deployer && npx storybook-to-ghpages --branch=$BRANCH --ci       env:         GH_TOKEN: $` secrets`.`GH_TOKEN `

Прежде чем писать отдельный экшен, нужно ответить на следующий вопрос: “Пригодится ли эта абстракция другим пользователям?”

Если ответом будет “Нет”, то, скорее всего, и создавать его не стоит.

Выводы

В этой статье мы изучили, когда стоит использовать именно экшен Docker, как его написать, а также когда есть смысл создавать отдельный экшен, а когда лучше выполнять встроенные шаги в самом рабочем потоке.

Более подробно о том, что такое GitHub Actions, в чем их польза, и как написать такой экшен на JavaScript, можете прочесть в одной из предыдущих статей.

В гостях у GitHub Package Registry
Kubernetes избавляется от Docker
Генерируем образы Docker с помощью Spring Boot

Читайте нас в Telegram, VK и

Overview

Rather than copying and pasting from one workflow to another, you can make workflows reusable. You and anyone with access to the reusable workflow can then call the reusable workflow from another workflow.

Reusing workflows avoids duplication. This makes workflows easier to maintain and allows you to create new workflows more quickly by building on the work of others, just as you do with actions. Workflow reuse also promotes best practice by helping you to use workflows that are well designed, have already been tested, and have been proved to be effective. Your organization can build up a library of reusable workflows that can be centrally maintained.

The diagram below shows three build jobs on the left of the diagram. After each of these jobs completes successfully a dependent job called «Deploy» runs. This job calls a reusable workflow that contains three jobs: «Staging», «Review», and «Production.» The «Production» deployment job only runs after the «Staging» job has completed successfully. Using a reusable workflow to run deployment jobs allows you to run those jobs for each build without duplicating code in workflows.

A workflow that uses another workflow is referred to as a «caller» workflow. The reusable workflow is a «called» workflow. One caller workflow can use multiple called workflows. Each called workflow is referenced in a single line. The result is that the caller workflow file may contain just a few lines of YAML, but may perform a large number of tasks when it’s run. When you reuse a workflow, the entire called workflow is used, just as if it was part of the caller workflow.

If you reuse a workflow from a different repository, any actions in the called workflow run as if they were part of the caller workflow. For example, if the called workflow uses , the action checks out the contents of the repository that hosts the caller workflow, not the called workflow.

When a reusable workflow is triggered by a caller workflow, the context is always associated with the caller workflow. The called workflow is automatically granted access to and . For more information about the context, see «.»

Reusable workflows and workflow templates

Workflow templates allow everyone in your organization who has permission to create workflows to do so more quickly and easily. When people create a new workflow, they can choose a template and some or all of the work of writing the workflow will be done for them. Inside workflow templates, you can also reference reusable workflows to make it easy for people to benefit from reusing centrally managed workflow code. If you use a tag or branch name when referencing the reusable workflow then you can ensure that everyone who reuses that workflow will always be using the same YAML code. However, if you reference a reusable workflow by a tag or branch, be sure that you can trust that version of the workflow. For more information, see «.»

For more information, see «Creating workflow templates.»

About GitHub Packages with GitHub Actions

GitHub Actions help you automate your software development workflows in the same place you store code and collaborate on pull requests and issues. You can write individual tasks, called actions, and combine them to create a custom workflow. With GitHub Actions you can build end-to-end continuous integration (CI) and continuous deployment (CD) capabilities directly in your repository. For more information, see «About GitHub Actions.»

You can extend the CI and CD capabilities of your repository by publishing or installing packages as part of your workflow.

Authenticating to the Container registry

To authenticate to the Container registry within a GitHub Actions workflow, use the for the best security and experience. If your workflow is using a personal access token (PAT) to authenticate to , then we highly recommend you update your workflow to use the .

For guidance on updating your workflows that authenticate to with a personal access token, see «.»

For more information about the , see «.»

If you’re using the Container registry in actions, follow our security best practices at «.»

Authenticating to package registries on GitHub

If you want your workflow to authenticate to GitHub Packages to access a package registry other than the Container registry on GitHub.com, then we recommend using the that GitHub automatically creates for your repository when you enable GitHub Actions instead of a personal access token for authentication. You should set the permissions for this access token in the workflow file to grant read access for the scope and write access for the scope. For forks, the is granted read access for the parent repository. For more information, see «Authenticating with the GITHUB_TOKEN.»

You can reference the in your workflow file using the context. For more information, see «Authenticating with the GITHUB_TOKEN.»

Когда неуместно использование конкретной версии Node (12)

Быть может вам нужно построить экшен на другой версии Node.

Даже если вы задействуете поддерживаемый Node 12, есть пара причин, по которым все равно может оказаться удобным использовать именно экшен Docker:

Вам больше не потребуется включать каталог непосредственно в репозиторий экшена. Можно использовать файл , где указаны зависимости, и откуда Docker контейнер при выполнении экшена будет эти зависимости извлекать.
Связывание необходимой для выполнения экшена среды с самим экшеном исключит вероятность внесения нарушающих работоспособность изменений при обновлении ПО в среде исполнителя на GitHub.

Создание экшена в контейнере Docker

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

Их экшен задуман для сборки и развертывания сайта StoryBook либо на GitHub Pages, либо в корзине AWS S3. Так что я расскажу о том, как создать экшен в контейнере Docker именно для этого случая.

Ознакомительный материал по данной теме можете найти в документации GitHub.

Upgrading a workflow that accesses ghcr.io

The Container registry supports the for easy and secure authentication in your workflows. If your workflow is using a personal access token (PAT) to authenticate to , then we highly recommend you update your workflow to use the .

For more information about the , see «.»

Using the instead of a PAT, which includes the 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 «.»

Navigate to your package landing page.
In the left sidebar, click Actions access.
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 «» and «Connecting a repository to a package.»
Optionally, using the «role» drop-down menu, select the default access level that you’d like the repository to have to your container image.
Open your workflow file. On the line where you log in to , replace your PAT with .

For example, this workflow publishes a Docker image using to authenticate.

Folder setup

argocd: Kustomize files for ArgoCD
argocd-applications: ArgoCD application for each Kubeflow component
cert-manager: Kustomize files for installing cert-manager v1.4.0
kubeflow: Kustomize files for installing Kubeflow componenets
- common/dex-istio: Kustomize files for Dex auth installation
- common/oidc-authservice: Kustomize files for OIDC authservice
- roles-namespaces: Kustomize files for Kubeflow namespace and ClusterRoles
- user-namespace: Kustomize manifest to create the profile and namespace for the default Kubeflow user
- katib: Kustomize files for installing Katib
- kfserving
  knative: Kustomize files for installing KNative
  
  : Kustomize files for installing KFServing
- central-dashboard: Kustomize files for installing the Central Dashboard
- jupyter-web-app
  
  notebook-controller: Kustomize files for installing the Notebook Controller
  
  : Kustomize files for installing the Jupyter Web App
- pod-defaults: Kustomize files for installing Pod Defaults (a.k.a. admission webhook)
- profile-controller_access-management: Kustomize files for installing the Profile Controller and Access Management
- tensorboards-web-app
  
  tensorboard-controller: Kustomize files for installing the Tensorboard Controller
  
  : Kustomize files for installing the Tensorboards Web App
- volumes-web-app: Kustomize files for installing the Volumes Web App
- operators: Kustomize files for installing the various operators
- pipelines: Kustomize files for installing Kubeflow Pipelines
metallb: Kustomize files for installing MetalLB

Root files

kustomization.yaml: Kustomization file that references the ArgoCD application files in argocd-applications
kubeflow.yaml: ArgoCD application that deploys the ArgoCD applications referenced in kustomization.yaml

Коммит кода

Добавьте каталог , файлы и , а также каталог .
Сделайте коммит изменений.
Отметьте изменения тегом: .
Отправьте их в репозиторий: .

Весь итоговый код для этого экшена можете найти в моем репозитории.

Экшен в рабочем процессе репозитория

Перейдите в репозиторий, где хотели бы использовать этот экшен для комментирования пул реквестов новых участников. Создайте в нем каталог . Добавьте в этот каталог файл для описания рабочего процесса:

name: Comment on pull requeston:  pull_request:    branches:      mainjobs:  comment:    runs-on: ubuntu-latest    steps:      - uses: deborah-digges/[email protected]        with:          access-token: $` secrets`.`ACCESS_TOKEN `

Именно здесь вы указываете события, в ответ на которые хотите запускать рабочий процесс. В данном случае нам нужно, чтобы он запускался в в ветке .

В текущем рабочем процессе есть одна задача , которая содержит один этап, состоящий из только что созданного нами экшена, использующего формат , который указывает:

Имя пользователя или организации на GitHub, где искать экшен.
Название репозитория, где расположен этот экшен и его зависимости.
Версию экшена, которая может быть либо в форме тега, либо в виде хэша коммита.