Open abesto opened 5 years ago
Alright, I'm now pretty happy with this. It can correctly load config options from a local file, a remote file, and do a best-effort try to get remote config based on the project and module name.
Heads up, I'll be merging this end of next week unless someone stops me. There are many changes here, and we're getting into merge-conflict-nightmare territory.
(Note this is on top of #34 ) Fixes #23
This allows defining per-project options in some central location. For convenience
PROJECT/MODULE
expands tohttps://openzipkin-contrib.github.io/apache-release-verification/presets/PROJECT/MODULE.yaml
; that is, thegh-pages
branch of this repo can serve as a central repository of configurations, but anyone is free to distribute their own configs however they like, as long as it's accessible over HTTP or HTTPS.As a proof of concept I've uploaded https://openzipkin-contrib.github.io/apache-release-verification/presets/zipkin/zipkin.yaml with the following contents:
That means one can now validate a Zipkin release as such:
The
--remote-config
option accepts full URLs as well, sozipkin/zipkin
is equivalent tohttps://openzipkin-contrib.github.io/apache-release-verification/presets/zipkin/zipkin.yaml
.Note that
--config
and--remote-config
can appear together (and are resolved in the order they're provided on the command line, with the latter overriding values provided by the former). So this can also be written, given a localzipkin.yaml
with the keysversion
,gpg-key
, andgit-hash
:A
remote-config
field in a local config file gets evaluated (but can be overridden via a command-line argument, like everything else specified via a local or remote config file)When
--remote-config
is not passed in, we try to infer it asproject/module
. Unlike explicitly defined--remote-config
values, there is no error raised if this inferred remote config file doesn't exist.