Replies: 3 comments 3 replies
-
Or send to plugin entire settings as JSON :) |
Beta Was this translation helpful? Give feedback.
0 replies
-
But wouldn't this break plugins? |
Beta Was this translation helpful? Give feedback.
0 replies
-
Please dont. Why not just use escaping? https://github.com/thegeeklab/wp-plugin-go/blob/main/types/stringslice.go |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Currently all plugin vars are concatenated via
,
and then provided to the plugins:woodpecker/pipeline/frontend/yaml/compiler/settings/params_test.go
Lines 43 to 56 in fcc57df
This creates the following issue:
By default,
urfave/cli
splitsStringSliceFlags
on,
, i.e. that a value ofPLUGIN_SLICE=1,2,3
will become<argname> 1 <argname>2 <argname>3
.This is fine, works in most cases and is often needed when needing to pass arguments multiple times to a CLI (like in docker for the
--build-args
argument).It doesn't work so well when any of the items contain a
,
on purpose as these will then also be split, whereas they should stay as a single value.There is a lot of trouble in the buildx plugin for this reason (1, 2, 3) as occasionally values should contain a comma. Right now there is no way to workaround this if the
StringSliceFlag
value should be kept.However,
urfave/cli
provides the optionSliceFlagSeparator
(default,
). This could be changed to;
and then no splitting at,
would happen but only on;
. However, this would require that the incoming env vars from WP also use;
as a separator. I.e., the initial value would then look likePLUGIN_SLICE=1;2;3
.Making this change would solve quite some issues and allow
,
to be a valid character withinStringSliceFlags
options. The downside would be that users need to use;
from there onward if they manually supply env var options instead of declaring them as YAML.Beta Was this translation helpful? Give feedback.
All reactions