Triggering pipeline via v2 api fails with 404 project not found

we have a cli tool that ulitimately uses a url like :

function getPipelineUrl({ user, vcs, repo }) {
  return `${vcs}/${user}/${repo}/pipeline/`;

// gets called with cli flags like --user, --vcs, --repo, --token etc.

we end up calling it like :

      - reckon/trigger_workflows:
          branch: <<pipeline.git.branch>>
          commit_ref_stash: ./development_commit
          enable_workflow_parameter: enable_development_build
          packagename_parameter: build_packagename
          packageroot_parameter: build_packageroot
          commitref_parameter: build_commitref
          tag_pattern: "^(@somereponame.*)@v.*-dev$"
          vcs_type: <<pipeline.project.type>>
            - reckon/process_changesets

which ends up calling :

        yarn deploy-tags

heres some parameter specs for this job:

    description: What is the VCS for this project
    type: env_var_name
    default: CIRCLE_TOKEN

    type: env_var_name
    description: The repo to trigger the workflow on

    description: Username for the Project
    type: env_var_name

    description: What is the VCS for this project
    type: string
    default: ''

These all get filled in nicely.

but for the last two days, a POST request with a correct CIRCLE_TOKEN to${vcs}/${user}/${repo}/pipeline/ results in a 404 project not found.

Urgently need assistance here.

Hi! Welcome to the CircleCI community!

Assuming that the variables are properly interpolated, this issue could be authentication related.

Are you using a project API token, as opposed to a personal API token?

Note that CircleCI API v2 only supports personal API tokens.


ugh. so what happens when I leave the company? all our CICD becomes broken?

What was the reasoning behind that?,

I can understand why project API tokens not being supported by our API v2 may be more challenging for some use-cases.

When the v2 API was designed, the decision was made to restrict access to personal API tokens.
Part of the motivation revolved around tying all access to a specific user and the pass-thru permissions of that user to the backing VCS (Github, Bitbucket).
This also allows a more obvious permissions path as there is now a 1-1 relationship between what a user can access and what the token can access.
In the case of the project token, there could be confusion about what specific actions that token could perform.

A suggestion would be to create a machine user (that has appropriate permissions to the repository/project) and use the token of that user.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.