Make validation optional

[hverlin]

Is your feature request related to a problem? Please describe. Having the validation check using the schema is nice. However, sometimes it fails to run a "valid" (as is "it runs on GitLab") pipeline.

I believe it might also be an issue if you are using a private GitLab instance which might not support the latest version of the schema?

Describe the solution you'd like Make all validation optional, or add an option to print a warning instead?

Describe alternatives you've considered Version later than 4.46.1 fails because of invalid schema or max. includes check

The workaround for me is to manually update the code or use

npm i -g gitlab-ci-local@4.46.0

[ANGkeith]

Having the validation check using the schema is nice. However, sometimes it fails to run a "valid" (as is "it runs on GitLab") pipeline.

yeah unfortunately because gitlab seem to perform the schema validation on their backend https://github.com/firecow/gitlab-ci-local/pull/1248#issuecomment-2146971764

to disable the schema validation export GCL_JSON_SCHEMA_VALIDATION='false'

on a side note, does #1248 fix your schema validation issue ?

[ANGkeith]

(Also, hard-coding it to 150 is not right. Maybe it should come from an env. variable as it can be configured in the GitLab admin) https://github.com/firecow/gitlab-ci-local/pull/1123#issuecomment-2152192377

Totally agree on this

[ANGkeith]

@hverlin regarding https://github.com/firecow/gitlab-ci-local/pull/1123#issuecomment-2152192377

Can we just print a warning instead?

Currently, this also act as a safety net to breakout of potential circular includes.

I don't think the check here is accurate, as gitlab-ci-local fails to run a pipeline which works in our GitLab instance (at least it might count includes a bit differently?

could you try to hack gitlab-ci-local src code to show whats the MAXIMUM_INCLUDES that gitlab-ci-local calculated?

[hverlin]

could you try to hack gitlab-ci-local src code to show whats the MAXIMUM_INCLUDES that gitlab-ci-local calculated?

@ANGkeith I am getting 156 includes :sweat_smile:

Also learned that it was updated to 175 internally, which is why it works on GitLab for me. So probably just making it configurable would be enough

[hverlin]

Other suggestion: maybe printing all the includes on error would help. In our case, it made pretty obvious which includes were included several times.

export class ParserIncludes {
  private static count: number = 0;
  private static allIncludes: Array<string> = [];

  static resetCount(): void {
    this.count = 0;
  }

  static async init(
    gitlabData: any,
    opts: ParserIncludesInitOptions,
  ): Promise<any[]> {
    this.count++;
    if (gitlabData?.include) {
      for (const incl of gitlabData?.include) {
        this.allIncludes.push(Object.values(incl).join(":"));
      }
    }
    assert(
      this.count <= MAXIMUM_INCLUDE + 1, // 1st init call is not counted
      chalk`This GitLab CI configuration is invalid: Maximum of {blueBright ${MAXIMUM_INCLUDE}} nested includes are allowed!.\n${
        this.allIncludes.sort().join("\n")
      }`,
    );

...

[hverlin]

For the validation, I think the error message could be updated:

const validate = ajv.compile(schema);
const valid = validate(data);
assert(valid, chalk`Invalid gitlab-ci configuration! ${ajv.errorsText(validate.errors)}.\nJson schema validation failed. Dump the following to the pipeline editor to debug: ${yaml.dump(data)}`);

For large pipelines, dumping to the console is not ideal, maybe in a file under .gitlab-ci-local instead?

The error that I am locally that is different from GitLab pipeline editor is the following:

job:
  script: 'echo "test"'
  artifacts:

which should be invalid

In GitLab, this is what I see (valid and wrong at the same time!)

[hverlin]

I have other repos which do execute on GitLab but are failing the validation. Their pipeline is also too big, so I think printing the full yaml directly to the console should be avoided.

I can make an MR if this works for you?

[ANGkeith]

I have other repos which do execute on GitLab but are failing the validation. Their pipeline is also too big, so I think printing the full yaml directly to the console should be avoided.

I can make an MR if this works for you?

yup please go ahead 👍, i don't mind this new addition too

while waiting, you can get them to use some bash magic

gitlab-ci-local 2> /dev/stdout | grep --color=never . | tail -n +3 | pbcopy

[ANGkeith]

For the validation, I think the error message could be updated: ... https://github.com/firecow/gitlab-ci-local/issues/1255#issuecomment-2155010429

Personally i would still use the pipeline editor, otherwise we might need to spend some effort for better display of the errors.

eg.

given:

test:
  tag:
    - true
  script:
    - echo 1

we have

vs