Debugging pipeline construction

GitLab CI/CD
1

I have a job defined as, (in part):

foo:
    only:
        variables:
            - $CI_PIPELINE_SOURCE == "push"
    script:
        - echo CI_PIPELINE_SOURCE is ${CI_PIPELINE_SOURCE}

that runs on schedule and prints that CI_PIPELINE_SOURCE is schedule.

How do I go about debugging what’s going on here?

In another place, the pipeline construction seems to be counter to what I’ve requested and I don’t understand why it’s done what it’s doing. I think the question is similar, though, wtf is going on here?

2

If the pipeline runs on a schedule, then foo won’t be triggered :

foo:
    only:
        variables:
            - $CI_PIPELINE_SOURCE == "push"

here you are checking that the pipeline source is a push, but in a scheduled pipeline the source will be schedule. These docs might be useful to you.

You can also turn on debug logging.

HTH,

Sarah

3

Debug tracing only helps once the job is running. It doesn’t help figure out why a job was run in the first place.

I already know that the variable was set to “schedule”. I’ve verified that with an echo, (shown in the example). I’m trying to figure out why gitlab ran it when it wasn’t “push”.

4

Right, sorry. I totally misunderstood your question. Is that all the config in the foo job?

5

No, there’s a lot more.

I think I’ve found this, finally, but it took a lot more time and effort than I think it should have. Whoever decided that a data format, (yaml), was suitable for writing code, should be shot, drawn, and quartered.

It appears in this case, that the idiosyncrasies of how yaml handles duplicate fields or merging of fields led to the “only” restriction being eclipsed. And the linter didn’t notice, which also seems odd.

So this particular issue may be solved for me, but my meta issue - that there’s no easy way to trace or debug this - stands. There should be some form of tracing that exposes reasons why stages are/are not scheduled in any particular context. Such a tracer should probably also be capable of dumping the internal state of this “data” after the yaml substitution and eclipsing has been done. Either one of those would have given me the data to pinpoint this problem in short order. As is, I was doing a lot of blind guessing which is expensive labor.

6

Yes, the linter is really very basic. There is a schema that you can use to verify the YAML in your editor. The pipeline editor can also help a little, but it’s really only for visualising stages and job.

Neither of these options offer the sort of semantic information that you are looking for (yet!).

There is an epic on improving the CI linter and you might want to add some comments to the issues there.