2. UI and YAML Coexistence The biggest blocker is determining how UI-configured schedules and YAML-configured schedules should interact:
YAML in the repo should be the only way to do it. The whole point of this issue/feature request is to persist and version-control the config in Git. UI settings should be disabled immediately, once a YAML config exists in the repo, and then slowly be deprecated. Since the UI consists of filling form fields with crontab syntax, there is not a lot of great UI experience to lose IMHO
Based on @mcnesium's comment, the idea of a solution where the UI settings would update (or be retrieved from) the YAML came to mind.
That's fine, though it adds the complexity of having to trigger commit(s) anytime the UI interacts with settings that exist in the YAML.
Then again maybe that idea isn't horrible in the long term.
Producing a commit dialog (with the option to create a feature branch?) upon changing Schedules from the UI wouldn't be all that bad of a workflow (right?). There's work to make that all happen though.
Pipeline schedules in the UI could be saved/retrieved from the YAML if they exist there. I suppose the question could then be
Michael Bear (553f7994) at 01 Sep 19:17
Add square brackets to GH/GL in README.md
Michael Bear (460f4281) at 01 Sep 19:14
Edit GitLab hyperlink text in README.md
Michael Bear (55f988f7) at 01 Sep 19:10
Edit README.md
Michael Bear (b4d37c96) at 16 Aug 13:31
Michael Bear (b4d37c96) at 16 Aug 13:30
Add alert to README.md
Michael Bear (d61a0758) at 16 Aug 13:10
Michael Bear (5b058233) at 16 Aug 02:43
Michael Bear (5b058233) at 16 Aug 02:40
Edit README.md
Michael Bear (d4d3706a) at 16 Aug 02:37
Michael Bear (70a45c4d) at 16 Aug 02:35
Michael Bear (d4d3706a) at 16 Aug 02:35
Merge branch 'ci-variables' into 'main'
... and 1 more commit