Draft: pkg/step/gitlab: initial take on parsing `step.yml` with syntactic sugar

This tries to implement syntactic sugar syntax that is reduced to base Step Definition, and ensures that base Step Definition is still supported.

assigned to @ayufan

added 1 commit

• ab300a34 - pkg/step/gitlab: initial take on parsing `step.yml`

Compare with previous version

added 1 commit

• 68fc68a2 - pkg/step/gitlab: initial take on parsing `step.yml` with syntactic sugar

Compare with previous version

marked this merge request as draft

changed title from {-pkg/internal/expression: make expression to not depend on context instead Dig-} to {+Draft: pkg/step/gitlab: initial take on parsing step.yml with syntactic sugar+}

changed the description

Setting label grouptenant scale based on @ayufan's group.

added grouptenant scale label

mentioned in issue #4 (closed)

Setting label(s) devopsdata stores sectioncore platform based on grouptenant scale.

added devopsdata stores sectioncore platform labels

mentioned in epic &11525 (closed)

What purpose does externalizing the script step implementation serve? We all agree that something like type: exec is a necessary primitive because fundamentally everything boils down to that.

We only have two defined types: exec and steps. If we flip this around and make steps[].script the native API then we don't even need to expose type: exec in the user-facing API.

See comparison to GH Actions syntax here #10 (comment 1740726721)

@marshall007 at the bottom, whatever we do needs to expand to a Unix exec call. No shells. So we can provide steps[].script as sugar, but it needs to expand to a step that will exec something. And a step author needs to be able to define that exec. So I can't see how we get away from needing to expose that. We don't want to make exec "internal" because we want step authors to be able to tie into an exec without going through a shell script. Am I missing something?

@ayufan yeah, I agree. There isn't a lot of benefit in defining the sugared syntax in proto. It's not long lived like an artifact. It's not minimal. And we want to share the schema easily with the UI. I'm thinking more along the lines of defining it in a Golang struct with annotations and generated a JSON Schema proper. E.g. github.com/invopop/jsonschema which we use already for validating some GitLab Runner configs.

@ayufan and I decided to divide the work on Step Runner by having me take over creation of the sugared syntax mechanism. And he would work on the expression language implementation. I'll probably start over since I won't be putting my schema in proto. So I'm going to close this and open another MR.

closed