Can I pass artifacts across job from different projects- referring to commit SHA (needs:project keyword)?

Hello,
I am trying to use needs:project specifying a commit SHA in ref field. In following way:

job:
  stage: tests
  script:
    - ls
  needs:
    - project: namespace/myproject
      job: build
      ref: c443c50cee692309518ff624599e3dd2ce367293
      artifacts: true

Unfortunately I receive an error:

A similar job definition using tag and branch name in ref field, works fine for me. Also, I am sure that pipeline/job/artifacts exist for SHA that I’m trying to refer.

I wonder if commit SHA as ref for needs:project is supported or maybe I’m doing something wrong?

Unfortunately, I can not find information in documentation. However, similar context for ref field is used for include:project and documentation has a example with commit SHA as ref value. I wonder if behavior for needs:project suppose to be similar.

include:
  - project: 'my-group/my-project'
    ref: main                                      # Git branch
    file: '/templates/.gitlab-ci-template.yml'
  - project: 'my-group/my-project'
    ref: v1.0.0                                    # Git Tag
    file: '/templates/.gitlab-ci-template.yml'
  - project: 'my-group/my-project'
    ref: 787123b47f14b552955ca2786bc9542ae66fee5b  # Git SHA
    file: '/templates/.gitlab-ci-template.yml'

We are using self-hosted gitlab v15.8.4-ee. Gitlab runner: 15.2.1

Thank you,
P

Have you found any solution or alternative to this?

No,it looks like the api doesn’t support it either. There is a request that allow you to download a artifacts from job (lnik below), but description for ref_name says:

Branch or tag name in repository. HEAD or SHA references are not supported.

Thus, only workaround that comes to my mind, is to create a artificial branch or tag, for commit from which you are willing to get artifacts.

Yeah, those two were the only available options.

However, just now I happened to find this The artifacts are not found in the pipeline if they are created in the merge request pipeline (#267532) · Issues · GitLab.org / GitLab · GitLab

Basically, my requirement was to use MR (not SHA). And for that you have to pass this refs/merge-requests/1/head instead of just merge-requests/1. (I knew it should start with refs/ but didn’t know about passing head at the end.)

And this is working!!!

This is very annoying. A natural thing I is to use an artifact from a job of the pipeline associated with $CI_MERGE_REQUEST_DIFF_BASE_SHA. I understand that a commit could be associate with multiple pipelines which complicates this.

Rant: The error message for when an artifact can not be downloaded is horrendously bad. No info at all for debugging. (and this is also lurking: `needs:pipeline:job:artifacts: true` checks for job success instead of artifacts presence (#367229) · Issues · GitLab.org / GitLab · GitLab)

If you need to grab artifacts from job associated with MR, you can use $CI_MERGE_REQUEST_REF_PATH variable.
See: Downstream pipelines | GitLab Docs

+1 to rant

When trying to workaround this, the limited permissions of CI_JOB_TOKEN gets in the way. It can read artifacts, but does not seem to be allowed to look up commits (to find the pipeline).

Rant: At this point it feels like it would be more useful if GitlLab just exposed a simple key-value store with a simple API we could use in the pipelines.

Epic on making the job token permission configurable: Make pipeline permissions more controllable and flexible (#3559) · Epics · Epics · GitLab.org · GitLab

More rant: Why is there no documentation on the required scopes for the rest endpoints (eg.: Commits API | GitLab Docs)

Even more rant: the API appear to often return 404 instead of 401 if the token lack permissions. Coupled with incomplete/dispersed documentation on scopes and permissions and long interationt times it really create a miserable developer experience..

If anyone wonders: as of 2025-06-24 the CI_JOB_TOKEN does not have access to fetch artifacts from other pipelines. You need a token with developer role and read_api scope for this (I tried guest and developer)

Are you sure, that artifacts from last pipeline from last commit from MR is not enough? You need to have a artifacts from specific commit?

Thanks, that is a good point! Tunnel vision

Maybe that would work just as well (or better) in practice…

To be clear: my goal is to have a job which show type-errors introduced by the MR. Every pipeline store the type errors of that commit in an artifact.

But whether the errors are compared against the merge base or the previous commit is perhaps not crucial. Should still catch all new errors, but the user would have to inspect multiple jobs to see all (on the other hand - the what-is-new heuristic might work better for this “granularity”).

So you are saying the CI_JOB_TOKEN should have access to the artifacts created by the MR? Is there even a “ref” I can use to download this “declaratively”?

But one challenge is the first commit in the MR. This would need to compare against the merge-base commit.

Just for clarification, why artifacts from MR need to be downloaded? And by what?

See: Job Artifacts API | GitLab Docs

ref_name attribute: Branch or tag name in repository. HEAD or SHA references are not supported. For merge request pipelines, use ref/merge-requests/:iid/head instead of the branch name.