curated githubactions schema has broken #Job and #Step definitions

[mvdan]

# So that auth to the central registry works.
env CUE_CONFIG_DIR=/home/mvdan/.config/cue

# So that we can download and extract modules.
env CUE_CACHE_DIR=${WORK}/.cache

exec cue mod init foo.test
exec cue mod get github.com/cue-tmp/jsonschema-pub/exp1/githubactions

exec cue eval showschema.cue

exec cue export good.cue

! exec cue export bad.cue

-- showschema.cue --
package main

import "github.com/cue-tmp/jsonschema-pub/exp1/githubactions@v0"

out: githubactions.#Step
-- good.cue --
package main

import "github.com/cue-tmp/jsonschema-pub/exp1/githubactions@v0"

out: githubactions.#Step & {
    run: "some command"
}
-- bad.cue --
package main

import "github.com/cue-tmp/jsonschema-pub/exp1/githubactions@v0"

out: githubactions.#Step & {
    fieldOutsideSchema: "this should fail"
}

The testscript above should pass. Yet it fails:

> exec cue eval showschema.cue
[stdout]
out: _
> exec cue export good.cue
[stdout]
{
    "out": {
        "run": "some command"
    }
}
> ! exec cue export bad.cue
[stdout]
{
    "out": {
        "fieldOutsideSchema": "this should fail"
    }
}
FAIL: repro-cuemod.txtar:14: unexpected command success

Note in particular how #Step is equal to _, which Marcel correctly pointed out.

We have this bit of extra CUE published as part of the curated module:

// Export some parts of the schema that aren't defined
// directly in the JSON Schema.

#Job:  ((#Workflow & {jobs: _}).jobs & {x: _}).x

#Step: ((#Job & {steps: _}).steps & [_])[0]

This appears to have been broken ever since JSON Schema started using matchN; since validators only return either top or bottom, and they return top when unused, trying to get a sub-schema through a validator results in top as well, given the use of & {steps: _} and so on above.

It seems to me like we need to find a way to fix the #Job and #Step definitions above to work correctly, as well as adding some tests that they actually work as expected. If they suddenly become top, we need tests which expect failures like the one in this report.

[mvdan]

Note that this is a problem with the existing default evaluator, not evalv3, so it is not related to any evalv3 regressions or behavior changes.

cc @rogpeppe @myitcv @mpvl

[mvdan]

The best approach here might be to surface sub-schemas to the top level without going through matchN, for example:

#NormalJob: #Workflow.#normalJob
#ReusableWorkflowCallJob: #Workflow.#reusableWorkflowCallJob

Ideally we surface #Step or #NormalJobStep in a similar way without resorting to hacks to work around optional fields or lists.