fix(config): stop parsing the syncerd binary as configuration, and remove the dead workflow - #50
Merged
Merged
Conversation
viper matches an extensionless file when a config type is set, and the extensionless file sitting in a working directory is very often the syncerd binary: make build writes ./syncerd, so running ./syncerd sync beside it made the tool read its own binary as YAML. The error that produced, "yaml: control characters are not allowed", names neither the file nor the cause. This repository's own scheduled workflow has failed that way on every run since at least June. Discovery now resolves the file itself and accepts only syncerd.yaml or syncerd.yml, in the working directory or ./config. When there is none it says so and lists everywhere it looked, which is the answer the operator actually needs.
It ran syncerd sync --once against a syncerd.yaml this repository has never contained, so it failed on every run since at least June, and its push trigger filtered on that same non existent path. The config discovery fix alongside this turns its failure from a baffling parse error into a clear one, which is an improvement to the message and not to the workflow. Removed rather than repaired. Making it work would mean deciding what this organisation wants mirrored and committing that as configuration, which is a product decision rather than a repair, and a workflow that has only ever failed teaches everyone to ignore a red mark on master.
clouddrove-ci
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found by watching the
SyncerDworkflow fail on master after #49 — then discovering it had failed on every run since at least June, months before anything I touched. Chasing it turned up a real product bug.The bug
make buildwrites./syncerd. viper matches an extensionless file when a config type is set. So running./syncerd syncin the directory you just built in makes the tool parse its own binary as YAML:That error names neither the file nor the cause. Reproduced in a clean directory containing nothing but the binary. Anyone following the README's build instructions and running from the repository root hits this.
The fix
Discovery resolves the file itself and accepts only a real
syncerd.yamlorsyncerd.yml, in.or./config. When there is none:Two regression tests: a directory containing only a binary named
syncerdis rejected, and a realsyncerd.yamlwins when both are present.The workflow
Also removes
.github/workflows/syncerd.yml. It ransyncerd sync --onceagainst asyncerd.yamlthis repository has never contained, and its push trigger filtered on that same non-existent path. The config fix above makes its failure legible rather than baffling, which improves the message and not the workflow.Deleted rather than repaired, at the maintainer's direction: making it work would mean deciding what this organisation wants mirrored and committing that as configuration, which is a product decision rather than a repair. A workflow that has only ever failed also teaches everyone to ignore a red mark on master, which is the more expensive problem.
Nothing references it — README, docs, and the other workflows are all clear.