#[Solved] Gitlab CI "Query.secret has no such argument"

1 messages Β· Page 1 of 1 (latest)

cosmic pasture
#

We're running dagger in Gitlab CI, it was running previously. I do not believe anything has changed in the environment and we just ran into this error.

This is running using the PHP SDK.

1   : [4.8s] | Error: input: query:
1   : [4.8s] | query{secret(uri:"env://CI_REGISTRY_PASSWORD"){id}}
1   : [4.8s] | 
1   : [4.8s] | error: parse selections: parse field "secret": Query.secret has no such argument: "uri"
1   : [4.8s] | 
1   : publish --registry=registry.gitlab.com --username=gitlab-ci-token --password=CI_REGISTRY_PASSWORD 

Is this:

  • A known issue in Dagger?
  • An unknown issue in the Dagger PHP SDK?
  • An issue specific to our setup?
chrome bay
#

are your cli and engine versions matched?

#

we hit this ourselves lol, ideally this should have neatly broken

cosmic pasture
#

Ah thank you for the quick response!

I believe that is what we're hitting, I'll let you know

cosmic pasture
#

So that was the solution. Thank you πŸ™‚

It fixed an issue and lead straight to another issue...

We got a 422 Unprocessable Entity on 0.15.4 like this help thread

We figured, it may be that it depends on a dagger module which was a bit outdated.

We tried updating the module.

Now I'm trying to install the updated version in our bigger project.

Error: failed to get module SDK: input: moduleSource.withContextDirectory.asModule failed to create module: select: failed to update module dependencies: failed to load module "my-project" dependency "sai" config: failed to decode module config: unmarshal module config: unmarshal module config: json: cannot unmarshal object into Go struct field alias.sdk of type string

This reminded me of this recent PR: update sdk field in dagger.json from string to struct #9454

Has anything changed in how a dagger.json should look in the latest version?

GitHub

This (is a WIP) stab at updating the dagger.json's sdk field from a string to a struct.
fixes #9156
I am opening this PR to collect initial feedback while I am trying to figure out how we c...

chrome bay
#

this'll be caused by using the new sdk.source in a dagger.json in a version that doesn't support it

#

now this is a bug yup - the engineVersion should have been bumped to v0.15.4 automatically when changing to sdk.source

#

and you would get a clearer error i think

cosmic pasture
#

Just a quick sanity check, does this look right to you?

{
  "name": "my-project",
  "engineVersion": "v0.15.4",
  "sdk": {
    "source":  "php"
  },
  "dependencies": [
    {
      "name": "sai",
      "source": "https://github.com/sai-php/sai",
      "pin": "99b3babcf77d0f203b9f307418731b86687e4789"
    }
  ],
  "source": "dagger"
}

This is a project where the dagger.json is located adjacent to a dagger/ directory

chrome bay
#

yeah, that looks good πŸ‘€

serene stream
#

Confirming that the engine version was bumped to 0.15.4 in my case too.

cosmic pasture
#

This may be an issue in the PHP SDK, as simply updating to the latest version of dagger has broken unchanged php modules

#

Is there any behaviour that had to be updated in the core SDKs for the upgrade?

#

@serene stream What SDK were you using when you ran into the 422?

chrome bay
#

even with matching client<->engine?

chrome bay
timber lark
#

issue is happening locally; where the engine matches the cli

#
:~/git/dag/php$ dagger version
dagger v0.15.4 (registry.dagger.io/engine:v0.15.4) linux/amd64
:~/git/dag/php$ docker ps | grep dagger
e161842740b9   registry.dagger.io/engine:v0.15.4                 "dagger-entrypoint.s…"   24 hours ago   Up 24 hours                                                                                           dagger-engine-v0.15.4
chrome bay
#

okay so i can get the 422 error to happen

#

but just to clarify, are you also still seeing the "cannot unmarshal object into Go struct field alias.sdk of type string"

chrome bay
#

okay, so for the 422 error we're getting the php sdk is producing an invalid query 😦

#

withKind defeinitely needs an arg there

#

any ideas why it does that?

#

it should be withKind(STRING_KIND)

#

i'm kinda confused how that's even possible

timber lark
#

I am as well; was studying the source code and it requires an argument to that function; it'd throw a PHP error if one wasn't passed

chrome bay
#

yeah okay

#

if i revert that change it works

#

I thought we established that that wasn't needed though? #php message

#

πŸ€”

timber lark
#

I don't think my module uses enums either, so it wouldn't be triggering that :/

chrome bay
#

that is what it is - the enum used is the TypeDefKind enum

#

used during module registration

timber lark
#

oooh; so it's blowing up on the built in emum

chrome bay
#

yeah exactly

timber lark
#

so all scalar types will be broken

chrome bay
#

yeah lol looks like i screwed that up

#

trying to decipher where the arg gets lost

timber lark
#

two levels down

#
    protected function setArgument(string $argumentName, $argumentValue)
    {
        if (is_scalar($argumentValue) || is_array($argumentValue) || $argumentValue instanceof RawObject) {
            $this->argumentsList[$argumentName] = $argumentValue;
        }

        return $this;
    }
#

a backed enum isn't a scalar, array or raw object

chrome bay
#

oh where's that?

timber lark
#

grand parent class

chrome bay
timber lark
#

I don't think it's using that version

chrome bay
#

facepalm that would indeed explain the issue i guess

timber lark
#

the version I'm seeing is an older verison of that dependency I think

chrome bay
chrome bay
#

ohhh

#

but sai isn't

timber lark
#

ah

#

I think we might need to bump the minimum version in the php SDK to 1.14.1

#

as your change doesn't work with 1.14.0

chrome bay
#

ohhhh

timber lark
#

it's currently allowing any 1.14.x verison

chrome bay
#

right right, sorry, i think i remember looking at the changelog and not seeing it in there 😱

#

okay, at least it's an easy fix then

timber lark
#

yep

chrome bay
#

i can bump it?

timber lark
#

glad we've not totally hosed the PHP SDK ~5 days before my PHP UK talk 🀣

#

go for it

chrome bay
#

honestly kinda sad to not be going lol 😦

#

i'm not even a php dev πŸ˜„ it would just be fun to catch up

timber lark
#

if you're around in London, there's a pre conf social

chrome bay
#

i'm actually based in brum, so sadly not

#

hm, okay, so the problem is that we can fix this, but v0.15.4 is hosed for php support

#

this is not great, so close to your talk πŸ€”

#

when is your talk?

timber lark
#

Wed 19th

chrome bay
#

okay, i might look into running an emergency release, gimme a moment to consult

timber lark
#

I'm going to try something else first

chrome bay
#

it may just be possible to bump the sai dep?

timber lark
#

deleted the composer lock from sai

#

that forced it to update

#

I wonder if we should consider adding composer.lock to the default module .gitignore

chrome bay
#

okay! awesome, so the problem seems to be for updating older modules, but new dagger inits should fetch the newest dep right?

timber lark
#

and maybe even removing it when initilising the module

chrome bay
#

my main concern is i want to make sure users running the php guide after your talk won't hit this πŸ˜†

timber lark
#

yes a brand new module will work

chrome bay
#

okay, i'll hold off on an emergency release then, the next v0.16.0 release is aimed for wednesday πŸ™

timber lark
#

that's bumped a few other deps; might be worth testing it against a few existing projects before merge

chrome bay
#

do you have a collection that you tend to use?\

timber lark
#

I've only got my projects currently

#

Paul has the work he's been doing for symfony though

#

I'm thinking that we probably want to make changes to the SDK to ignore the module composer.lock - it's going to cause issues any time a dependecy in the SDK gets bumped

cosmic pasture
#

Sorry I wasn't around to help, I had an urgent appointment to get to. I'm catching up but it looks like I missed the action

timber lark
#

yeah, we dived in and figured it out :p

chrome bay
timber lark
cosmic pasture
#

Right, so the issue was us getting caught by the composer.lock snag again?

cosmic pasture
chrome bay
#

i guess this is a more generic problem though

#

we solve this in the go sdk by updating all the deps to minimum version in sdk/go/go.mod

#

maybe that could work here too?

#

(assuming we remember to keep composer.json up to date)

timber lark
#

no the module has it's own lock

#

at best it blows up as it cant resolve an installable set of packages from the lock

chrome bay
#

yeah that's what i mean - for go modules, we bump the module's go.mod min versions to the embedded known "good versions" that appear in sdk/go/go.mod

timber lark
#

hmmm

serene stream
cosmic pasture
timber lark