-
-
Notifications
You must be signed in to change notification settings - Fork 354
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move plugin config to root.pipeline.[step].settings #464
Conversation
Signed-off-by: jolheiser <john.olheiser@gmail.com>
If we break with old pipeline config i think we should have a look at drome 1.0 pipeline format ... Whats even better would be to add a version flag so we can be backwards compatible. Breaking with things for admin is one thing. But breaking with things user use is a other story in my opinion |
Idear is if version is not set it's v1 And your breaking changes is v2 Let tje v1 parse stay as is and ad a new one? |
We can look at this, but I don't know that it would be good to do in a single PR, however...(see below)
In order to make the transition a bit easier, maybe we flag version 2 pipeline config format as "unstable" until we finish making changes? In terms of this PR
|
yes I like your proposal ... about packages what about |
Just as an idea: Could we add support for a config plugin as later versions of drone have it, to use it to convert v1 woodpecker configs to new v2 configs on the fly and then only add code / support for the newest schema in the main server itself? |
I think at some point we could deprecate v1? |
If it is not to complicated to support two schema in parallel as 6543 suggested, then I think we can also add support for both. Just had the feeling it would duplicate a lot of code and adding the config plugin support should be considered at some point anyways. |
To prefent duplicated code if posible iproposed a common package |
Signed-off-by: jolheiser <john.olheiser@gmail.com>
I looked at this a bit more, and unfortunately it seems it would require a fair amount of copying. What I have currently isn't ideal, but would work in the interim. Essentially it combines the past behavior with the new. Any unknown keys are pushed into I'm not sure how we want to move forward with the format. Maintaining a v1and v2 would likely require a fair amount of copying. One thing we could possibly do is copy the v1 as-is one time, that is for a "converter" that will move v1 configs to v2 |
TODO note: update json schema |
@anbraten can you add the schema part to this pull? |
@6543 I updated the schema a bit and fixed tests. |
This PR moves vargs to settings.
More specifically, it moves
to