Самостоятельные бегуны на Github на каждую ветку

Question

Я пытаюсь реализовать самодостаточный раннер на Github, но сильно ударился о стену

Я хочу, чтобы для моих серверов prod и dev были разные бегуны

Насколько я понимаю, можно установить метки в зависимости от среды, но оба моих сервера dev и prod по существу одинаковы (оба являются сервером Windows 20012 R2 с аналогичным оборудованием)

У меня есть два файла yml, указывающих на dev и master соответственно, но могу ли я указать бегуну на правильное действие?

Я пробовал добавить к бегунам такой ярлык:

Но когда я публикую в мастере, запускается топ-раннер.

Файл yml для prod выглядит примерно так:

      name: SSR-Prod

on:
  push:
    branches: [master]
  pull_request:
    branches: [master]

jobs:
  build:
    runs-on: self-hosted

    steps:
      - uses: actions/checkout@v2
      - name: Restore dependencies
        run: npm install
      - name: Build and publish
        run: npm run build:ssr

Answer 1

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

      runs-on: [ self-hosted, master ]

Это гарантирует, что ваш рабочий процесс будет запущен на втором бегуне.

Answer 2

На самом деле я обнаружил, что ответ @frennky нам не подходит; потратил много времени на вырывание волос (к счастью, у меня их много). Что сработало, так это:

На самом деле это легко сделать, но выяснить, как это странно сложно.

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

Для нас сработало следующее:

        setup-dns:
    name: Setup dynamic DNS
    runs-on: prod

Предполагая, конечно, что ваш лейбл — «производство». (Кстати, не заставляйте Prod использовать динамический DNS). Согласно документам и здравому смыслу, это должно работать:

        setup-dns:
    name: Setup dynamic DNS
    runs-on: [self-hosted, prod]

Но это не так; бегун никогда не бежит. У меня был разговор со службой поддержки GitHub, но я потерял ссылку. До тех пор, пока вы не создадите автономный бегун с меткой (не именем) ' ubuntu-latest' (или другие версии O/S исполнителя, размещенные на GitHub), у вас не возникнет проблем!

Если подумать логически, то для размещения собственного ярлыка требуется , чтобы это был автономный бегун, поэтому два значения для «runs-on» несколько избыточны. Я предполагаю, что вы все еще можете использовать две самостоятельные метки исполнителя, и подпрограмма будет работать на любой доступной. Мы не пошли по этому пути, так как нам нужно было, чтобы исправления запускались на нескольких производственных серверах детерминировано, поэтому у нас буквально есть prod1, prod2, prod2 и т. д.

Теперь вот где это становится интересным. Допустим, у вас есть вызываемый рабочий процесс, более известный как «подпрограмма». В этом случае вы не можете использовать " runs-on" в вызывающем; только вызываемый.

Итак, вот что вы делаете в вызываемом рабочем процессе:

      on:
   workflow_call:
      inputs:
         target_runner_label:
                type: string
                description: 'Target GitHub Runner'
                required: true

   # not strictly needed, but great for testing your callable workflow
   workflow_dispatch:
      inputs:
         target_runner_label:
                type: string
                description: 'Target GitHub Runner'
                required: true

 jobs:
   report_settings:
      name: Report Settings
      runs-on: ${{ inputs.target_runner_label || github.event.inputs.target_runner_label }}

Теперь - вы можете удивиться ||заявление посередине. Оказывается, синтаксис обращения к workflow_callвходы и workflow_dispatchвходы совершенно разные.

Еще одна загвоздка: «имя» бегуна совершенно лишнее, потому что это метка, а не имя, которое рабочий процесс использует для его запуска. В приведенном ниже примере вы не будете использовать «erpnext_erpdev» для запуска рабочего процесса, вы будете использовать «erp_fix».