Repository navigation
Trigger pipeline and download artifacts from triggered pipeline #1021
Description
It should be a simple exercise, but in fact because of all the tokens it is not. There are few issues and I tried few variations, but to no avail. I am trying to trigger pipline and download artifacts of project A to pipeline that is running in project B and then use those artifacts to compile documentation.
Example I assembled based on documentation:
gl = gitlab.Gitlab('https://gitlab.melexis.com', job_token=os.environ['CI_JOB_TOKEN'])
project = gl.projects.get(project_id, lazy=True)
pipeline = project.trigger_pipeline('branchname', 'targetprojecttoken', variables={"VAR1": "True"})
# Start pipeline and wait for completion
while pipeline.finished_at is None:
pipeline.refresh()
time.sleep(1)
So, first problem was that I want to use CI_JOB_TOKEN to trigger the pipeline (not targetprojecttoken). This is something that can be done with curl, but here it does not work (tried with replacing targetprojecttoken with os.environ['CI_JOB_TOKEN'] but I get gitlab.exceptions.GitlabCreateError: 404: 404 Not Found).
Now for second more pressing issue here is that pipeline.refresh() returns gitlab.exceptions.GitlabGetError: 404: 404 Project Not Found although I confirmed that trigger_pipeline did trigger the pipeline.
Expected Behavior
trigger_pipelineshould work withjob_tokengiven toGitlabobject as based on https://docs.gitlab.com/ee/ci/triggers/#ci-job-tokenpipeline.refresh()should refresh status or request token.
Actual Behavior
trigger_pipelineworks withtargetprojecttokeninstead ofjob_tokenpipeline.refresh()returnsgitlab.exceptions.GitlabGetError: 404: 404 Project Not Found
Specifications
- python-gitlab version: 2.0.1
- API version you are using (v3/v4): v4
- Gitlab server version (or gitlab.com): private
Activity
max-wittig commentedon Feb 19, 2020
Where do you get
targetprojecttokenfrom?It really looks like the user is not able to access the project. Could you try to call pipeline refresh with curl? (Get pipeline status)
Letme commentedon Feb 19, 2020
targetprojecttokenis token of the trigger, not of the user. But my main expectation is thatCI_JOB_TOKENshould be enough?matthewcosgrove commentedon Jan 2, 2021
Also have been trying to get the documented example referenced above working with mixed results.
Related observations using GitLab Enterprise Edition 13.5.5-ee
project.trigger_pipelinedoes work for me withCI_JOB_TOKENso the downstream job triggering works finepipeline.refresh()returnsgitlab.exceptions.GitlabGetError: 404: 404 Project Not FoundSo it looks like the documented approach wont fully work with
CI_JOB_TOKENas I'm assuming the scope of its privileges don't cover the underlying API call needed forpipeline.refresh()Letme commentedon Jan 2, 2021
@matthewcosgrove That is also what I would assume, but I could not find any reference anywhere in the documentation about this.
matthewcosgrove commentedon Jan 2, 2021
Found a very good summary here:
Seems there are a ton of related issues too but I'm not seeing much sign of the chosen direction by GitLab yet.
matthewcosgrove commentedon Jan 2, 2021
More observations using the
CI_JOB_TOKENinstead of the "trigger token"Another alternative I will be investigating is a "bridge" job which removes the need for any API calls at all.
erakis commentedon Jul 9, 2021
Same problem on my side
nejch commentedon Aug 6, 2022
Hey folks, I just re-read this issue. This is basically expected upstream behavior, because
refresh()calls an API endpoint that job tokens cannot access (you can only trigger the pipeline using it).In the last comment above mine, it's even more limited as the Gitlab instance was initialized without a token, and only one API call was made with a trigger token. This will of course not work for other endpoints.
We also describe the job token limitation now in https://python-gitlab.readthedocs.io/en/stable/api-usage.html by linking to the upstream docs.
I think this is probably the best we can do, because the job token permissions change frequrently in GitLab's API, and it'd be hard to track/maintain that continuously in our own client via either docs or user warnings for all the relevant endpoints. So I think we can close this now and you can track the upstream issues linked above for more flexible job token permissions. But please reopen if you disagree.