#[SOLVED] - I'm having a problem with enums since v0.18.11

1 messages · Page 1 of 1 (latest)

pliant adder
#

Since I upgraded to this version, enums are not working as before.

Before

with

// Main `New` function
func New(
  // ...
  // +optional
  version KsVersion,
  // ...
) // ...
// Enum definition
type KsVersion string
const (
  v1_30 KsVersion = "v1_30"
  v1_31 KsVersion = "v1_31"
  v1_32 KsVersion = "v1_32"
  v1_33 KsVersion = "v1_33"
)
// And a function
func Foo(version KsVersion) //...

The options to pass to the enum were the values, that in this case are the same as the vars names (i.e. dagger call --version v1_30)

Now

with the same as before the options are: one of V_1_30,V_1_31,V_1_32,V_1_33, this are the vars names, but not as they were defined


After realising the previous behaviour, I just changed the value for version in my workflow.

Now the thing is, in my module (kind), which defines the enum, it works perfectly. But I have another module (validate-crds) that depends in the first one that gives me the following error:

  ┆ ): Directory!
  ┆ version: V_1_31
  ): ValidateCrds! 0.2s ERROR
panic: failed to unmarshal input arg version: unknown enum value "v1_31"                                                   
                                                                                                                           
goroutine 1 [running]:                                                                                                     
main.invoke({0x8f2e80, 0x400

This happens with this command: dagger call --version V_1_31 .....

The dependency is installed as a local module:

"dependencies": [
  {
    "name": "kind",
    "source": "../kind"
  }
]

I call the kind module like this:

opts := dagger.KindOpts{}
if version != "" {
    opts.Version = version
}
container := dag.Kind(dockerSocket, kindSvc, opts).Container()

Why could this be happening?

hollow goblet
hollow goblet
#

@eager jungle @native pine is the normalization effect also expected? reading this comment from Helder:

I hope in most cases users have been using values equal to the names.

Even if that's the case, dagger call would still break because of the normalization if they names contain numbers and letters

#

i.e: v1 is normalized to V_1 in the CLI

#

just noticed something else is happening as well. With this example:

// Main `New` function
func New(
    // +optional
    version KsVersion,
) *Enums {
    return &Enums{}
}

// Enum definition
type KsVersion string

const (
    v1_30 KsVersion = "v1_30"
    v1_31 KsVersion = "v1_31"
    v1_32 KsVersion = "v1_32"
    v1_33 KsVersion = "v1_33"
)

func (e *Enums) Foo(version KsVersion) {
    fmt.Println(version)
}

even if I leave dagger.json in v0.18.10, running dagger call foo --help shows different outputs.

#v0.18.10
USAGE
  dagger call foo [arguments]

ARGUMENTS
      --version v1_30,v1_31,v1_32,v1_33   [required]
#v0.18.11
USAGE
  dagger call foo [arguments]

ARGUMENTS
      --version ,,,   [required]
#

added a comment in the GH issue for visibility

eager jungle
#

the normalization is intended

hollow goblet
#
130|marcos:tmp/enums (⎈ |N/A)$ dagger call foo --version "v1_30"
▶ connect 0.2s
▶ load module: . 0.7s
✘ parsing command line arguments 0.0s ERROR
! invalid argument "v1_30" for "--version" flag: value should be one of ,,,
eager jungle
#

i think this is also still fixed?

hollow goblet
#

sweet 🙏

eager jungle
#

at least seems to be 🤔

hollow goblet
eager jungle
#

fyi, we'll be doing a v0.18.12 release before the end of the week, that should include fixes for this

thorn pine
#

Just updated to 0.18.11, assuming the above is also responsible for panic: failed to unmarshal parent object: unknown enum value "" with blank unknown enum value?

hollow goblet
thorn pine
#

I'm still having this issue on v0.18.12: panic: failed to unmarshal parent object: unknown enum value ""

#
ARGUMENTS
      --environment DV,AT,PR        Environment code [required]
dagger call ... --environment AT

->

panic: failed to unmarshal parent object: unknown enum value ""

eager jungle
#

are you storing an enum value on a struct? do you have a snippet of that?