Skip to content

Instantly share code, notes, and snippets.

@sulami
Last active July 1, 2019 14:52
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save sulami/b14bb09f38239ac558050828835deef0 to your computer and use it in GitHub Desktop.
Save sulami/b14bb09f38239ac558050828835deef0 to your computer and use it in GitHub Desktop.
# Rejected alternatives for conditional workflow semantics
# 'explicit' key
# Pros:
# - Somewhat self-explanatory
#
# Rejected because:
# * Adds a special-purpose key to workflow which only serves to mark a workflow
# as "not run on receipt of a webhook".
# * Configgers cannot control workflows as groups. 'explicit' allows marking
# the set to run on receipt of a webhook, API-callers need to specify each
# individual workflow when triggering via the API.
# * Cannot be extended. Any new triggering rules (such as filtering the entire
# workflow by VCS data) will require new forms of config.
# * Requires additional workflows syntax to filter entire workflows by VCS data.
workflows:
# foo won't be triggered by a webhook
foo:
explicit: true
jobs:
- whatever
- another
bar:
jobs:
- a-job
- another-job
---
# Separate trigger rules
# Pros:
# - User-defined rules
# - Could be extended to include filtering by VCS data
#
# Rejected because:
# * Can be extended but the semantics for combining triggers from the list are
# not obvious, it is easy to write a trigger which conflicts with itself.
# * Configgers cannot control workflows as groups. 'explicit' only allows
# marking a single set of workflows to not run on receipt of a webhook,
# API-callers need to specify each individual workflow when triggering via the
# API.
trigger_rules:
workflows:
foo:
- explicit: true
workflows:
# foo won't be triggered by a webhook
foo:
jobs:
- whatever
- another
---
# More elaborate, named, trigger rules
# Pros:
# - Flexible, can be reused across workflows
#
# Rejected because:
# * Semantics for combining either multiple trigger_rules, or the individual
# conditions inside a trigger_rule are not obvious. It is easy to create
# triggers which conflict with themselves.
trigger_rules:
bar:
branch:
- master:
workflows:
- foo
explicit:
workflows:
- foo
workflows:
trigger_rule: bar
foo:
jobs:
- whatever
- another
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment