gitlab: nested maps in cache, service and default are written as blocks the parser rejects

[jccguimaraes]

Unparse turns any nested map into an HCL block, but the schema in provider/gitlab/config.go declares several of those keys as attributes. The HCL that comes out does not parse.

writeGenericMap (provider/gitlab/unparse_pipeline.go) does this for every nested map it meets:

if nested, ok := toStringAnyMap(value); ok {
    b := body.AppendNewBlock(key, nil)
    ...
}

Three cases from the GitLab schema, each one a full unparse-then-parse:

cache.key as a map (the documented key: files: form):

build:
  script: [make]
  cache:
    key:
      files: [go.sum]
    paths: [.cache]

cache {
  key {
    files = ["go.sum"]
  }
  paths = [".cache"]
}

Blocks of type "key" are not expected here. — hclCacheBlock.Key is hcl.Expression.

services[].variables:

build:
  script: [make]
  services:
    - name: postgres:16
      variables:
        POSTGRES_DB: test

Blocks of type "variables" are not expected here. — hclServiceBlock.Variables is hcl.Expression.

default.retry as a map:

default:
  retry:
    max: 2
    when: runner_system_failure
build:
  script: [make]

Blocks of type "retry" are not expected here. — hclDefaultBlock.Retry is hcl.Expression.

The job body path does not have this problem: writeJobBlock writes environment, parallel and variables as object attributes, and those roundtrip. Only the generic path inside cache, artifacts, service and default bodies is affected.

artifacts.reports is the one nested map that should stay a block, since hclArtifactsBlock.Reports is declared hcl:"reports,block".

So the writer needs to know which keys the schema declares as blocks rather than guessing from the value shape.

[jccguimaraes]

Two more of the same, found while probing the fix.

include with inputs (the CI component form):

include:
  - component: gitlab.com/c/t@1
    inputs:
      stage: test

include {
  component = "gitlab.com/c/t@1"
  inputs {
    stage = "test"
  }
}

Blocks of type "inputs" are not expected here. — hclIncludeBlock.Inputs is hcl.Expression.

And the mirror of the bug: a template body goes through writeGenericMap too, which writes every non-map value as an attribute. rules is a list, so it comes out as one:

.base:
  image: golang:1.26
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: always

template "base" {
  image = "golang:1.26"
  rules = [{ if = "...", when = "always" }]
}

An argument named "rules" is not expected here. — hclTemplateBlock.Rules is hcl:"rule,block".

So the generic writer is wrong in both directions: it makes blocks out of maps the schema wants as attributes, and attributes out of lists the schema wants as blocks. A template body is a job body and should be written by writeJobBlock, which already handles rules, cache, artifacts and services correctly.