GitHub Actions без UTC-болю: timezone у cron і environments без зайвих deployments

Коротко: GitHub Actions закрив дві болючі дрібниці, які реально економлять час командам: тепер scheduled workflows можна запускати у вашому локальному часовому поясі, а environments можна використовувати без створення зайвих deployment-записів. Для щоденної CI-рутини це менше помилок у розкладі та чистіша історія деплоїв.

Що змінилося в березневому оновленні GitHub Actions

1) Timezone для cron-розкладу

Раніше більшість команд тримала schedule в UTC і постійно ловила зсуви при сезонному переході часу. Тепер можна вказати timezone прямо біля cron-виразу:

on:
  schedule:
    - cron: '0 9 * * 1-5'
      timezone: 'Europe/Kyiv'

Практичний ефект:

• менше ручних перерахунків UTC;
• менше помилок у запуску «о 9:00 за Києвом»;
• простіший рев’ю workflow-файлів.

2) deployment: false для environment без зайвого шуму

Якщо job використовує environment лише заради secrets/variables (а не реального деплою), можна вимкнути створення deployment object:

jobs:
  test:
    runs-on: ubuntu-latest
    environment:
      name: staging
      deployment: false
    steps:
      - run: npm test

Це зручно для CI/test pipelines, де не хочеться засмічувати deployment history.

Важливі обмеження, які не можна ігнорувати

deployment: false не вимикає частину захистів environment:

• wait timer все одно діє;
• required reviewers все одно потрібні.

Але є критичний виняток: якщо на environment увімкнені custom deployment protection rules (через GitHub App), job з deployment: false може впасти з помилкою несумісності.

Коли це варто впроваджувати прямо зараз

1. У вас є регулярні ранкові/нічні джоби, прив’язані до локального часу команди.
2. Ви використовуєте staging/prod environments як контейнер для секретів.
3. У deployment history вже накопичився «шум» від тестових workflow.

30-хвилинний playbook міграції

1. Візьміть 1-2 найкритичніші scheduled workflow.
2. Перенесіть cron на timezone (IANA).
3. Для CI/test job у staging додайте deployment: false.
4. Прогоніть dry-run/ручну перевірку trigger-часу.
5. Зробіть короткий запис у README/engineering handbook, чому і де це застосовано.

Типові помилки команд

• Змінити timezone без перевірки фактичного часу запуску.
  Виправлення: після merge перевірте перші 1-2 запуски у вкладці Actions.

• Увімкнути deployment: false на production deployment job.
  Виправлення: тримайте це для CI/test, а не для справжніх релізів.

• Ігнорувати custom protection rules.
  Виправлення: перед змінами звіртеся з налаштуванням environment.

Висновок

Це не «гучний реліз», а саме той тип змін, що знімає щоденний операційний біль. Якщо коротко: переводьте schedule на timezone, а environments у CI використовуйте точково з deployment: false — але тільки після перевірки правил захисту.

Офіційні джерела:

• https://github.blog/changelog/2026-03-19-github-actions-late-march-2026-updates
• https://docs.github.com/actions/reference/workflows-and-actions/workflow-syntax#onschedule
• https://docs.github.com/actions/how-tos/deploy/configure-and-manage-deployments/control-deployments#using-environments-without-deployments