CI_JOB_TOKEN and triggered pipeline status

Hi. I have posted this issue but got no response so far, so I’m hoping to have some discussion here.

I am using CI_JOB_TOKEN to trigger consecutive pipelines from a single job. These pipelines depend on each other, thus I implemented a mechanism to scan for triggered pipeline status. However for this scan I had to create a separate API token, since CI_JOB_TOKEN allows only to trigger.

IMO the CI_JOB_TOKEN should allow to check the triggered pipeline status (and maybe other some actions on it, but this is questionable). Triggering seems to be more powerful action than just reading the status.

@lukasz.sterkowicz - Thanks for the issue! I left a comment there for you to clarify the use case.

-James H, GitLab Product Manager, Verify:Pipeline Execution

Hi @lukasz.sterkowicz

Uhm, why don’t you just use the built-in feature trigger to start a child pipeline? There is no need for all that curl and while loops, because GitLab will do that for you.

A really simple example would look like:

start pipeline A:
  stage: pipelineA
  trigger: my-group/my-project
  branch: some_branch
  strategy: depend

start pipeline B:
  stage: pipelineB
  trigger: my-group/my-other-project
  strategy: depend

I use triggers but not everywhere, for there are certain differences:

  1. Using trigger does not enlist the child pipeline in the repo’s pipelines, and it’s sometimes desired to have it listed.
  2. Trigger disallows using any script in the job (including before and after) and it makes it much harder to configure the triggered pipeline. Yes, you can have additional jobs before and after, but:
  • it clutters the screen with jobs which you could avoid to have
  • it’s much slower to run 2, 3 or even more jobs (note I can call API multiple times from single job) instead of one (scheduling jobs, loading docker image)
  • sometimes even require to create dynamic (say proxy) pipeline which is looks not much less complex (the code) than calling the API.

Thanks for your comment and hope this explains.

I see your points, just to clear some it up in case someone else reads it. Child pipelines created using trigger are listed in “downstream” repo’s pipelines like any other pipeline

You’re right. Thanks for clarifying!