Start separate job after workflow succeeded

Build Environment
, ,
#1

This is very similar to Run another workflow after a workflow succeeds?

What I want is to run cypress or selenium tests after deploy is done.

It needs to happen after deploy to be running on new code but it can’t happen right after deploy because there is a period in which CDNs are still having old version.

I’d like to have it in separate job/workflow because “deployment” workflow is successful when code is deployed. If I’d do it as last job in “deployment” workflow, workflow would be marked as successful couple of minutes after deploy which could introduce confusion (ie. workflow still in progress but new code already deployed).

I found such solution How to trigger a workflow via CircleCI API (v2) – CircleCI Support Center which probably could work. Is it the best option or there is any simpler solution to this problem?

#2

Hello,
There is some chatter internally about this kind of request and I hope something will be coming but nothing I can mention in the near term.

I would recommend the API as you mentioned, this is actually how we deal with building orbs today. We have two workflows in our config that have when conditionals and only run when the pipeline parameter is present.

The first workflow runs, then triggers the project again with the pipeline parameter, triggering the second workflow.

#3

Thanks for reply @KyleTryon

I was able to implement it like this:

workflows:
  build_test_deploy:
    when: << pipeline.parameters.triggered_by_push >>
    jobs: 
      # ...
      - trigger_another_workflow
  another_workflow:
    when: << pipeline.parameters.triggered_by_deploy >>
    jobs:
      # ...

What I’m using in trigger_another_workflow is:

    curl --request POST \
              --url https://circleci.com/api/v2/project/github/org/project/pipeline \
              --header 'Circle-Token: API_KEY \
              --header 'content-type: application/json' \
              --data '{"branch":"'${CIRCLE_BRANCH}'","parameters":{"triggered_by_deploy":true, "triggered_by_push":false}}'

Problem is, that only API_KEY that made it work, is my personal api token (that I was able to genere under “User Settings” → “Personal API Tokens”), not project api token (which are under “Project settings” → “API Permissions”). This seems wrong, anyway I can use project’s api_key for this or maybe there is something wrong with api endpoint that I’m using?

#4

Awesome :tada:

This is intentional with the need for a personal access token. Project level tokens are for read-only operations. Any run of a pipeline must be authenticated against the user triggering it so certain permissions can be checked. You will also notice, when you trigger a pipeline via the API, your username will still appear as the triggerer (as specified by the API token).

If you need a more generic solution that isnt tied to you in particular, we recommend using a “machine” user from GitHub. We as a part of this same example actually use a machine user as well to publish our orbs.

This is a GitHub user created as a “bot”, no user would log in to it (after setup), you would simply use the machine user to generate the needed API key for the CI task, and you can manage the user’s permissions directly on GitHub.