circleci-archived/api-preview-docs

In-progress docs about the pre-release preview of CircleCI API v2

api-preview-docs's Issues

[Feature Request] Use codegen to create client libraries

Requested Feature

I would very much appreciate CircleCI generating some client libraries from its api spec. I'm imagining something like swagger-codegen or protobuf, or however it's implemented in the various clients aws provides (example).

Context

I've built / maintained several small services that use the CircleCI api. Generally when I'm building services like this (in python / golang / javascript) I want to use a client, since working directly with json can often be annoying. In many cases, I have opted to use client libraries provided by 3rd parties, such as

• https://github.com/jszwedko/go-circleci
• https://github.com/levlaz/circleci.py

I prefer 3rd party client libraries over using the json api directly, but I'm still not totally comfortable with using 3rd party libraries to access an API for a vendor.

Impact

If there were some automatically generated libraries available for this API, it would have the following effects:

• it would be more stable than using a json api directly, which would increase the reliability of the services I build on top of CircleCI
• it would be more trustworthy than using client libraries, which eliminates the cognitive / operational overhead that is currently incurred via us using client libraries from random open source contributors

Closing

I would very much like this feature, so please let me know when you add it ✨ 🙏 thank you for reading! 🙏 ✨

Typo in CircleCI API v2 Docs

In API v2 Developer's guide page, the Gather Insights section has a typo. It should be containing, not containg.

List projects by organisation

As a circle ci user, I would like to able to discover projects in any org via the API. Personally, this is so that I can do extended build statistics in a particular org.

Current workarounds

The current ways to get a list of repositories are very problematic.

1. The v1 API has an endpoint that lists followed projects https://circleci.com/api/v1/projects. But this lists only my currently followed projects meaning that any program needs maintenance in that its account needs to have all projects followed.

2. Using the GitHub API to list repositories https://api.github.com/users/cob16/repos and then trying to fetch all of these projects in circle ci. Of course, not all repositories will be set up to use circle ci to this is a very error-prone way to get a list

Suggested new route

The v2 API could have a way to list projects by the organisation

1. As there is already a GET v2/projects/gh/<org>/<project>route for a single project. An extension to this would be v1/projects/gh/<org> (without the repo name part) that returns a list of projects
2. The user route could list a user's projects via /v1/user/<org>/projects

Add v1 deprecation to v1 docs

Hi everybody. Seems like you have a problem with the old jobs API. I run something like this

curl -X POST --header "Content-Type: application/json" -d '{
  "parallel": 1,
  "job": "deploy-tag",
  "build_parameters": {
    "VALUE": "40Mi"
  }
}' https://circleci.com/api/v1.1/project/github/paperlesspost/kubernetes-deployments/tree/master?circle-token=$CIRCLE_API_TOKEN

This has worked for months, until today. Got this response from the API

{"message":"An internal server error occurred."}

Started digging around and after some googling I saw the deprecation notice in a blog post:
https://circleci.com/blog/a-deprecation-notice-on-job-triggering-with-api-v1-1/

I would have commented in the forum, and tried to make an account, but it prompted me for 2FA. That's a bit much for your forum, imo.

Anyways, this is the API I've been using:

https://circleci.com/docs/api/#trigger-a-new-job

It would be helpful if the deprecation notice was there, as well. As far as I can tell, it's just on your blog.

Desired: Ability to query (filtered) workflows for a project.

Current Preview endpoints include specific workflows (GET /workflow/:id) and project details (GET /project/:project_slug) but no way to get the list of workflows for a project. This feels like a gap given our V1 API allowed all jobs for a project, and without a listing/index I don't understand where the workflow_ID would come from unless running inside a job.

This endpoint is important for essentially any API call that needs to discover workflow IDs, statuses, etc.

It would be particularly useful for my Queuing orb to understand all running workflows for the current project since querying individual jobs can have a race condition in the transitions between jobs. eddiewebb/circleci-queue#26

curl command in README is incorrect

curl -u ${CIRCLECI_TOKEN} https://circleci.com/api/v2/me

results in password prompt

How to pass executor parameters

Hi, I could not find an example to override default parameter value in executors.
In the below example how can we override the default value for app_env parameter in base10 executor?

version: 2.1
orbs:
  cypress: cypress-io/cypress@1
parameters:
  app_env:
    type: string
    default: 'test'

executors:
  base10:
    parameters:
      app_env:
        type: string
        default: << pipeline.parameters.app_env >>
        description: application environment
    docker:
      - image: 'cypress/base:10'
    environment:
      CYPRESS_app_env: << parameters.app_env >>

The API's build parameter is overriding only pipeline parameter but not executor parameter.

curl -u ${CIRCLECI_TOKEN}: -X POST --header "Content-Type: application/json" -d '{ 
  "build_parameters": {
    "app_env": "uat" 
  } 
}' https://circleci.com/api/v2/project/gh/etc/etc/pipeline

can anyone please help?

Desired: ability to use `unless` key

My use case is that I have 2 workflows and I would like to run only one of them based on the api call, and run only the second one based on the trigger from github.
Currently, when using unless it gives me the following config error:

#!/bin/sh -eo pipefail
# Config does not conform to schema: {:workflows {:build_deploy_frontend_backend {:unless disallowed-key}}}
# 
# -------
# Warning: This configuration was auto-generated to show you the message above.
# Don't rerun this job. Rerunning will have no effect.
false
Exited with code 1

Simpler way to get state of most recent workflow

I'd like to know the state of the most recent workflow for each of my projects.

The only way I can figure out how to do this right now is:

1. GET /project/:project_slug/pipeline and parse out items[0].id (assuming the first item is the most recent - that's not entirely clear in the docs)
2. GET /pipeline/:pipeline_id and parse out workflows.ids[0] (The fact that ids is an array, but so far I've only ever seen a single value in it, suggests there's a level of potential complexity here that I don't understand)
3. GET /workflow/:workflow_id and parse out status (This bit is feels intuitive as it uses the same language as the UI)

Whilst this may work, I have a couple of problems with doing it that way:

• It requires 3 separate calls to the API, none of which can be done in parallel as they rely on data from the previous call.
• It introduces the concept of "pipelines" which really aren't clear to me. Even after reading https://circleci.com/blog/coming-soon-a-preview-on-pipelines/ I'm none the wiser. I'd rather stick with words that I'm familiar with from the UI, eg "projects", "workflows" and "jobs" (though in this case, jobs are too granular for what I care about)

Can I suggest a new endpoint? For example: GET /project/:project_slug/workflows
It'd return an array of workflows, sorted by most recent first. Each workflow would be an object containing the data currently surfaced in /workflow/:workflow_id

This would allow a single call to be made for each project and I wouldn't have to get my head around new concepts just for navigating the API.

Workflow jobs and Workflow runs documentation

Hi,

When calling: https://circleci.com/api/v2/insights/{project-slug}/workflows/{workflow-name}/jobs/{job-name} or https://circleci.com/api/v2/insights/{project-slug}/workflows/{workflow-name}

The documentation specifies credits-used but the payload is actually credits_used (see below).

The payload received is:

    {
      "id": "REMOVED",
      "started_at": "2020-03-19T03:20:55.139Z",
      "stopped_at": "2020-03-19T03:25:23.275Z",
      "duration": 268,
      "status": "success",
      "credits_used": 44
    },

/me results in "you must login first" error

1. define New API Token for the project
2. run export CIRCILECI_TOKEN=<token>
3. run curl -u ${CIRCLECI_TOKEN}: https://circleci.com/api/v2/me

Result:

{
  "message" : "You must log in first."
}

Paging control on pipeline API

Is there a way to control the paging (if any?) on the pipeline API? For example, can I request 100 at once? Can I request item 100 - 200? etc

I'm aware of the next page token, but it doesnt seem to be otherwise documented

"Auto-cancel redundant builds" should be smarter about conditional workflows

Hello, we are attempting to us conditional workflows and pipeline parameters so that we can easily deploy our website. So we have two workflows: 1) a full build and 2) just deploy the site.

Problem steps:

1. Merge a change to to origin/production, which triggers a full build (default pipeline parameters)
2. Soon after, make a change to the blog which uses the circleci API to trigger a pipeline build (i.e. parameters: { "build": false, "deploy-site": true })
3. Observe on the circleci site that the first build has been canceled.

Since the selected workflows aren't the same, I don't think these builds should be considered "redundant".

Triggering Workflows with boolean parameters no longer works

I've been toying with running a bot to trigger conditional workflows via slack (as described by the the docs) As of this morning, boolean parameters are being automatically converted into strings. previously working curl command:

curl -X POST \
  'https://circleci.com/api/v2/project/:projectslug/pipeline?circle-token=TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{"parameters": {"mark": true} }'

error in circle

#!/bin/sh -eo pipefail
# Type error for argument mark: expected type: boolean, actual value: \"true\" (type string)
# 
# -------
# Warning: This configuration was auto-generated to show you the message above.
# Don't rerun this job. Rerunning will have no effect.
false
Exited with code 1
CircleCI received exit code 1

"message" : "Project not found"

following the simple example you give on the front page.

curl -u ${CIRCLECI_TOKEN}: -X POST --header "Content-Type: application/json" -d '{
"parameters": {
"param1": "foo",
"param2": "find-me"
}
}' https://circleci.com/api/v2/project/gh/myorg/myproj/pipeline

"message" : "Project not found"

The project is found just fine by the 1.1 api
This doesn't work either:

curl -u ${CIRCLECI_TOKEN} https://circleci.com/api/v2/me
Enter host password for user 'mytokenhere':

I try it like this and I get the spew:

curl -u ${CIRCLECI_TOKEN}: -X POST --header "Content-Type: application/json" -d '{
"parameters": {
"param1": "foo",
"param2": "find-me"
}
}' https://circleci.com/api/v2/project/myorg/myproj/pipeline

<title>Continuous Integration and Deployment</title><script type="text/javascript">var circleEnvironment = "production";var circleHost = "circle-www-api-v1-797f7b6f99-hfkrj";var current_manifest_version_key = "frontend-releases/v3/849abd7c6a90753f6e72f2ad94ef6639062f3b8c.json";var optimizelyUrl = 'https://dmmj3mmt94rvw.cloudfront.net/assets/js/hosted/optimizely-a65329d34bab22eca38ab10d36eafc5b.js';var segmentWriteKey = 'AbgkrgN4cbRhAVEwlzMkHbwvrXnxHh35';var CSRFToken = '2wD4d5HJ4gv65cgh-kJU3KMpQBS8mC-LbhURFj5-IzdbUHD1aXFYWAdgSGy6f2UYp08k2FEsaU4u57fP';var OAuthCSRFToken = 'm2PWp1wKaQqicNzKN2LqVNxWmsgpV_stETitYUB9yh40qhSWFZli0Ttxyg_uTC0q_7Tjzg-7l_JVZ6Wy';</script><script type="text/javascript">var renderContext = JSON.parse(document.getElementById('bd3da3ad-9fc1-41c5-9ffd-f7774640b5c1').content);</script> <script type="text/javascript"> !function(){var loadOptimizely=function(){var e=document.createElement("script");e.type="text/javascript";e.async=!0;e.src=optimizelyUrl;var n=document.getElementsByTagName("script")[0];n.parentNode.insertBefore(e,n)}; window.addEventListener('load', loadOptimizely, false); }(); </script> <script type="text/javascript"> !function(){var analytics=window.analytics=window.analytics||[];if(!analytics.initialize)if(analytics.invoked)window.console&&console.error&&console.error("Segment snippet included twice.");else{analytics.invoked=!0;analytics.methods=["trackSubmit","trackClick","trackLink","trackForm","pageview","identify","reset","group","track","ready","alias","debug","page","once","off","on"];analytics.factory=function(t){return function(){var e=Array.prototype.slice.call(arguments);e.unshift(t);analytics.push(e);return analytics}};for(var t=0;t <script src="//d3dy5gmtp8yhk7.cloudfront.net/2.2/pusher.min.js" type="text/javascript"></script><script type="text/javascript">var launchDarkly = JSON.parse(document.getElementById('41ab3d53-0222-4eca-ab87-25f79a418933').content);</script><script type="text/javascript">var launchDarklyPlans = JSON.parse(document.getElementById('19b2a2e0-e532-40de-9c39-ec7dfb877ee0').content);</script><script type="text/javascript">var _rollbarConfig = JSON.parse(document.getElementById('1762bc15-e58c-4dae-837b-f1a022ac042d').content);</script><script>!function(r){function o(n){if(e[n])return e[n].exports;var t=e[n]={exports:{},id:n,loaded:!1};return r[n].call(t.exports,t,t.exports,o),t.loaded=!0,t.exports}var e={};return o.m=r,o.c=e,o.p="",o(0)}([function(r,o,e){"use strict";var n=e(1),t=e(4);_rollbarConfig=_rollbarConfig||{},_rollbarConfig.rollbarJsUrl=_rollbarConfig.rollbarJsUrl||"https://dmmj3mmt94rvw.cloudfront.net/assets/js/hosted/rollbar-4fcef5ccc29985d4878f2e7c5676180b.min.js",_rollbarConfig.async=void 0===_rollbarConfig.async||_rollbarConfig.async;var a=n.setupShim(window,_rollbarConfig),l=t(_rollbarConfig);window.rollbar=n.Rollbar,a.loadFull(window,document,!_rollbarConfig.async,_rollbarConfig,l)},function(r,o,e){"use strict";function n(r){return function(){try{return r.apply(this,arguments)}catch(r){try{console.error("[Rollbar]: Internal error",r)}catch(r){}}}}function t(r,o){this.options=r,this._rollbarOldOnError=null;var e=s++;this.shimId=function(){return e},window&&window._rollbarShims&&(window._rollbarShims[e]={handler:o,messages:[]})}function a(r,o){var e=o.globalAlias||"Rollbar";if("object"==typeof r[e])return r[e];r._rollbarShims={},r._rollbarWrappedError=null;var t=new p(o);return n(function(){o.captureUncaught&&(t._rollbarOldOnError=r.onerror,i.captureUncaughtExceptions(r,t,!0),i.wrapGlobals(r,t,!0)),o.captureUnhandledRejections&&i.captureUnhandledRejections(r,t,!0);var n=o.autoInstrument;return(void 0===n||n===!0||"object"==typeof n&&n.network)&&r.addEventListener&&(r.addEventListener("load",t.captureLoad.bind(t)),r.addEventListener("DOMContentLoaded",t.captureDomContentLoaded.bind(t))),r[e]=t,t})()}function l(r){return n(function(){var o=this,e=Array.prototype.slice.call(arguments,0),n={shim:o,method:r,args:e,ts:new Date};window._rollbarShims[this.shimId()].messages.push(n)})}var i=e(2),s=0,d=e(3),c=function(r,o){return new t(r,o)},p=d.bind(null,c);t.prototype.loadFull=function(r,o,e,t,a){var l=function(){var o;if(void 0===r._rollbarDidLoad){o=new Error("rollbar.js did not load");for(var e,n,t,l,i=0;e=r._rollbarShims[i++];)for(e=e.messages||[];n=e.shift();)for(t=n.args||[],i=0;i</script>

Hello there noscripter!

CircleCI uses JavaScript pretty heavily to provide a good experience and to allow us to develop code a lot faster. We recognize that the tradeoff is that people using noscript get a worse experience, and we apologize for that.

So let us pitch you quickly on why you should enable JavaScript and view our site. CircleCI is powerful, fast, and easy-to-use Continuous Integration and Deployment for web applications.

CircleCI is easy to set up, incredibly fast, allows you to get your code to customers faster, and will even automatically parallelize your tests over many machines to get results to you faster. If that sounds useful, we'd encourage you to whitelist us in noscript and read about it yourself :)

<script crossorigin="anonymous" src="https://dmmj3mmt94rvw.cloudfront.net/assets/js/frontend-production-8fe95c42e3e87a3b6e5fad1d633978da.js" type="text/javascript"></script>

<script id="ze-snippet" async src="https://static.zdassets.com/ekr/snippet.js?key=d6a46f2f-db01-4e4e-a20e-5c089096bfe3"> </script>

Desired: Run a pipeline on a specified branch

Currently we have an endpoint to which you can make a POST request:
POST /project/:project_slug/pipeline. This runs a pipeline on a default branch. Is it possible to run a pipeline on a specified branch, using the 1.1 structure? eg.
POST /project/:project_slug/tree/:branch/pipeline

Bug: New /project/project-slug/pipeline getting 404

What is the Problem?

I am seeing 404 "project not found" messages on new API endpoint

What was expected behavior?

I expected a 200/202 and listing of recent pipelines

Can you recreate it?

Yes. Using the API url in these docs, or the generated openAPI schema |

Below is curl snippets that can be used.

# i can trigger pipelines (you can too if you want
curl --request POST   --url 'https://circleci.com/api/v2/project/gh%2Feddiewebb%2Fcircleci-queue/pipeline?circle-token=minenotyours'   --header 'accept: application/json'
{"number":34,"state":"pending","id":"1ca33a79-8711-40bd-999d-e4308bab1ed3","created_at":"2019-08-06T21:24:12.143Z"}

# but not list them
curl --request GET \
  --url 'https://circleci.com/api/v2/project/gh%2Feddiewebb%2Fcircleci-queue/pipeline?circle-token=minenotyours' \
  --header 'accept: application/json'
{"message":"Project not found"}

a few other v2 project APis like checkout keys work fine as well.

Better error responses

Currently, when request has some error in it, api returns some html page with a js scripts in it.

It is hard to understand what is the error exactly, when trying to use api from command line/scripts.

Artifacts data types requested for PowerShell examples

Hello,
I was working on your artifact API using PowerShell and hit some issues due to the API returning EDF type data and not JSON. The API documentation says nothing about this being an option. Please see the issue that has prompted me to ask you to add to your documentation of the API and examples on how to request data returned in a different format, EDF vs JSON, for Windows PowerShell so your new Windows Container customers can use the API without issue.

https://stackoverflow.com/questions/57730091/how-to-download-artifacts-from-circleci-via-powershell-command-invoke-restmethod

Consistent URL pluralisation

There's a few oddities with resource naming in the URLs, alternating between singular and plurals. This is minor, but annoying when trying to build clients against the API.

For example:

# Retrieve a list of Pipelines
GET /project/:project_slug/pipeline/

# Retrieve a list of Jobs
GET /workflow/:id/jobs

Generally speaking, REST uses pluralised resources for the base i.e.

# Retrieve a list of workflows
GET workflows
# Retrieve a single workflow
GET workflows/:id

Is there any plan to follow standards here, or at be consistent within your own definitions?

Question: Filtering scheduled pipelines by branch name

Hello, I'm digging through the new scheduled pipelines feature documentation.

When converting from the old scheduled workflows syntax, I noticed that there doesn't seem to be an equivalent way to ensure that scheduled pipelines only trigger for specific branches.

Old trigger:

daily-run-workflow:
  triggers:
    - schedule:
        # Every day, 0421Z.
        cron: "21 4 * * *"
        filters:
          branches:
            only:
              - main  # <-- Only run on the main branch
  jobs:
    - test
    - build

But there doesn't seem to be an equivalent way to filter workflows by branch name:

daily-run-workflow:
  when:
    and:
      - equal: [ scheduled_pipeline, << pipeline.trigger_source >> ]
      - equal: [ "my schedule name", << pipeline.schedule.name >> ]
      # Missing mechanism to filter by branch name
  jobs:
    - test
    - build

I hope I'm not misunderstanding how scheduled pipelines work with respect to branches, but please correct me if that's the case.

Is there an existing way to filter on branch name? Maybe something like:

daily-run-workflow:
  when:
    and:
      - equal: [ scheduled_pipeline, << pipeline.trigger_source >> ]
      - equal: [ "my schedule name", << pipeline.schedule.name >> ]
      - equal: [ "main", << pipeline.branch.name >> ]  # <-- only match when pipeline.branch.name equals "main"

Or is this on the development roadmap?

Scheduled pipelines look like a very cool feature, I'm looking forward to fully utilizing them! Thank you!

Edit: Fixed YAML syntax and reworded a bit for clarity.

Invalid conditional workflow example

In the example for conditional workflow there is a job that is conditionally added to the workflow based on parameter

workflows:
  version: 2
  integration_tests:
    when: << pipeline.parameters.run_integration_tests >>
    jobs:
      - mytestjob
      - when:
          condition: << pipeline.parameters.deploy >>
          steps:
            - deploy

On practice though this results in the invalid configuration: Cannot find a definition for job named when when validated with circleci 0.1.5830+2bb45a0

Changefeed?

Probably the biggest addition from my point of view would be the ability to subscribe to some sort of changes or event driven API; maybe an arbitrary webhook? At the moment the best thing I could figure out is polling and parsing the data.

Body parser is not tolerant of whitespace??

The docs have this example request:

curl -u ${CIRCLECI_TOKEN}: -X POST --header "Content-Type: application/json" -d '{
  "branch": "dev"
}' https://circleci.com/api/v2/project/${project_slug}/pipeline

However, whenever I include "branch" in my request body (even just {"branch": "master"}) I get a response that says {"message": "Invalid JSON body."}.

What I really want to do is pass a git commit hash, to trigger a parameterized pipeline for a specific commit, is that intended to be supported?

Pipeline Parameters Ignored with API

I'm having issues triggering jobs with pipeline parameters, I created a simplified example config to recreate.
config.yml

version: 2.1
parameters:
  mark:
    type: boolean
    default: false

executors:
  go:
    docker:
      - image: circleci/golang

jobs:
  read-parameters:
    executor: go
    steps:
      - run: echo << pipeline.parameters.mark >>
workflows:
  version: 2
  if-mark:
    when: << pipeline.parameters.mark >>
    jobs:
      - read-parameters

  if-not-mark:
    unless: << pipeline.parameters.mark >>
    jobs:
      - read-parameters

Triggering with

curl -u "${CIRCLECI_BOT_TOKEN}:" -d '{"parameters":{"mark":true}}' -X POST https://circleci.com/api/v2/project/:PROJECTSLUG/pipeline

or

curl -u "${CIRCLECI_BOT_TOKEN}:" -d '{"parameters":{"mark":false}}' -X POST https://circleci.com/api/v2/project/:PROJECTSLUG/pipeline

always runs the if-not-mark, as configured above, but if I change the default value in the config it runs the if-mark, so I think it is an API issue.

Also I should add that i've been using this successfully before, so I think it is a regression with a recent behind the scenes update of v2. (I know its beta! 😁 )

Trigger workflow in different repo with same user

First I would like to say that I really like the new API for pipelines.

A feature I really would like is to be able to from a workflow/job A trigger a workflow B in a different repo using the same user as in workflow A. The first is possible now, but the automatic feedback is somewhat lost since the executing user on workflow B is different than on workflow A.

Does this make sense?

Backport note about Accept header to v1 docs

At the bottom of your preview docs for v2 API it says:

If you do not provide an ACCEPT header, the v2 API will return JSON. This is a change from 1.1, which would default to EDN.

This is a really useful bit of information that I spent ages struggling with when using the v1 API. Would it be possible for that to be added to the docs for v1? I couldn't find mention of it anywhere. (Apologies if this is wrong place to mention this - I know you're probably focusing on the new API, and less about the existing one)

Endpoint to fetch all project workflows

Hey folks,
v1.1. has GET /projects endpoint to fetch all projects of the token verified user and with that I was able to read the current states (success, failures and running) for my whole context to be shown in dashboard.
The endpoint has the problem, that jobs "on hold" were displayed as "failed" and after approval the continued workflow will not be shown in the json data...

So I searched for option to use v2 instead, but it has completely no additional information to v1.1 and has no option to get all projects or workflows.

Perhaps you can enhance your endpoints to this request...
Best regards
Sven

Pipeline updated_at field not actually updating

Hi,

This may just be that I don't really understand the updated_at field within a pipeline, but when I restart a workflow within a pipeline, the updated_at value doesn't change... It would be nice if this changed if any one of its descendants (workflow or job within the pipeline) changed status themselves. It would also be nice if the .../pipeline endpoint returned a list of pipelines sorted based on a query parameter. For instance, I'd sort based on updated_at vs. created_at. Any suggestions?

Schuyler

Passing environment variables in API v2?

Is it possible to pass environment variables in JSON body of API v2 call?

Even with pipelines parameters, I want to use environment variables, so I tried to make api v2 call

https://circleci.com/api/v2/project/:vcs-type/:username/:project/pipeline

and tried something like this to send in body:

{
	"branch": "circle_ci_api_v2_test",
	"parameters": 
	{
    	  "my_mystical_param": "Hello from postman mystic",
    	  "my_legendary_param": "Hello from postman legendary"
	},
	"build_parameters":{
	  "envVar": "kuku iopta",
    	  "testVar1": 27
	}
}

But circle ci build does not see any variables. Is there any way to pass them? Beacuse, I think that making assignment env_var_name=parameter_name is not good idea.

Triggering a pipeline by tag doesn't trigger any workflows

I am trying to use the new API to trigger a pipeline by tag or commit and neither seem to work. It looks like the API doesn't support passing a commit/revision but it looks like tag is supported:
https://github.com/CircleCI-Public/api-preview-docs/blob/master/specs/v2-sketch.yaml#L750

However when I try to trigger via a tag, it doesn't end up triggering any workflows.
Here's the request body being sent

{ 
  parameters: { 
    'run-lint': false,
    'run-build-linux': false,
    'run-build-mac': false,
    'upload-to-s3': '1',
    'run-linux-x64-publish': true
  },
  tag: 'v8.0.0-nightly.20191016' 
}

And the response I get back:

{ 
  workflows: [],
  id: '84f3fc12-6fbf-47ac-85ea-9c977f071b39',
  errors: [],
  project_slug: 'gh/electron/electron',
  updated_at: '2019-10-17T14:09:40.081Z',
  number: 15408,
  state: 'created',
  created_at: '2019-10-17T14:09:40.081Z',
  trigger: { received_at: '2019-10-17T14:09:40.056Z',
     type: 'api',
     actor:
      { 
        login: 'jkleinsc',
        avatar_url: 'https://avatars0.githubusercontent.com/u/609052?v=4' 
      } 
  },
  vcs:
   { origin_repository_url: 'https://github.com/electron/electron',
     target_repository_url: 'https://github.com/electron/electron',
     revision: 'e06b0aa73b91ef90a40616f2ad4554117c69d7ee',
     provider_name: 'GitHub',
     tag: 'v8.0.0-nightly.20191016'
  } 
}

Cannot access job output

I can't seem to find a way to access job logs using API V2.

For v1.1 the following query returns the job including all actions with their "output_url" attribute. Perfect!

curl -H 'Content-Type: application/json' "https://circleci.com/api/v1.1/project/gh/nbedos/citop/37?circle-token=$CIRCLECI_API_TOKEN"

However the corresponding query using API V2 returns much less information. No job step, no action, no "output_url".

curl -H 'Content-Type: application/json' "https://circleci.com/api/2/project/gh%2Fnbedos%2Fcitop/job/37?circle-token=$CIRCLECI_API_TOKEN"

Am I missing something? How can I get the log of a job using API V2? I tried a few other endpoints without success.

Thanks

Conditional Job Support

With current features we can use parameters to have conditional workflows and conditional steps

The latter (steps) gets a little ugly with the amount of nesting, but in the use case that I have an optional job I can work around this by redefining the entire workflow again, and include the extra job, but the permutations here could explode.

Use case - only publish asset when version is provided.

version: 2.1

parameters:
  publish_target:
    default: "" #empty values considered FALSEY
    type: string

workflows:
  basic:
    jobs:
      - sample_job:
          name: Build It
      - sample_job:
          name: Share It
          when: <<pipeline.parameters.publish_target>>

only 'master' branch is triggered using v2 API

I'm trying to trigger a build on specified branch using such v2 API call:

curl -u ${CIRCLECI_TOKEN}: -X POST "Content-Type: application/json" -d '{"branch": "some-branch"}' https://circleci.com/api/v2/project/${project_slug}/pipeline

EXPECTED RESULT:
I expect the branch specified in branch parameter will be triggered.

ACTUAL RESULT:
Instead of specified branch master always trigger.

Project build replaced?

I noticed in the API Docs the project build API is being replaced. Is that an accurate statement?

POST /project/:vcs-type/:username/:project/build
Replaced by POST /project/:vcs-type/:username/:project/pipeline

If so, will the ability to trigger a build at a certain branch/commit or tag be introduced through a different feature? We're using this capability to implement sane environment/version management using the grace-circleci-builder. This API feature is exceptionally useful, save for the lack of being able to provide build parameters at execution-time (ie: secret injection).

Unable to trigger pipeline to build forked Pull Request via V2 API, error message: *Branch not found*

Post on discuss forum as well.

I'm encountering problem when triggering a pipeline by v2 API endpoint, which returns error message of "Branch not found" with 400 status code. My goal is to setup a mono-repo with services in individual directories and triggering the workflow only when the services are modified. Thanks to the discussion forums , I found some helpful discussions and explanation which give me great heads up.

Here is a simpler version of the config snippet

version: 2.1
parameters:
    trigger:
      type: boolean
      default: true
    
    service1:
      type: boolean
      default: false
    
    service2:
      type: boolean
      default: false

jobs:
   trigger_pipelines:
     ...
     steps:
        - checkout
        - run:
            name: trigger service workflow if modified
            command: |
                // Filter the modified service
                ...
                // trigger modified service workflow 
                curl -u "${CIRCLE_TOKEN}:" \
                       -H "Content-Type: application/json"
                       -d "{\"branch\": \"$CIRCLE_BRANCH\", \"parameters\": {...} }" \
                       https://circleci.com/api/v2/project/gh/org/repo/pipeline

workflows:
    version: 2
    
    analysis:
        when: << pipeline.parameters.trigger >>
        jobs:
           - trigger_pipelines

        service1:
            when: << pipeline.parameters.service1 >>
            ...
        service2:
            when: << pipeline.parameters.service2 >>
            ...

The default workflow(analysis) was triggered from a forked Pull Request (I switch on the setting Build forked pull requests) which created a pull/1 branch on the CircleCI server. However, when the changes of service1 workflow was detected and triggered by the POST /pipeline endpoint, I got the error message "Branch not found" in the build step terminal. I also tried to try to POST the endpoint through postman to ensure the branch value equals to pull/1 but the same error remained. I was wondering if I missed something in the document. Let me know if you need more informations for investigation. Thanks for your patience to read the post!

List projects API (v2) is missing

Hello 👋

I am looking for an endpoint which can help us list all the projects within an organization (or the projects the user has access to). However we have an endpoint(v1/projects) in CircleCI API (v1) which returns the projects followed by the user.

A route like GET /v2/projects should list all the projects the user has access to.

Pipeline API get id of triggered workflows

We have a Slack bot to trigger jobs using the old build API, after it was triggered the bot would reply with a link to the job. The new pipeline API works well as a replacement, but from what I can see we don't get anything back that we can use to build a link for the user.

Unable to access v2 APIs with project-specific API tokens

CircleCI v1 API supports both project-specific API tokens and user's API tokens to get and start jobs on our private repositories. Although we can use personal API tokens to manage our private repository on v2 API, project-specific API tokens do not work.

For v1 APIs, we can get job information on our private projects by the following curl:

$ curl -sSfL -u"${CIECLE_TOKEN}:" "https://circleci.com/api/v1.1/project/$PROJECT_SLUG/${BUILD_NUM}"
{
  "compare": null,
   ...
}

where CIRCLE_TOKEN is allowed with both project-specific API tokens and personal API tokens.

For v2 APIs, we can use personal API tokens to access our private repository:

$ curl -u"${PERSONAL_TOKEN}:" https://circleci.com/api/v2/project/$PROJECT_SLUG/job/$BUILD_NUM
{
  "web_url" : "https://circleci.com/gh/our-org/repo-name/123456",
  ...
}

but using project-specific tokens returns 404:

$ curl -u"${PROJECT_SPECIFIC_TOKEN}:" https://circleci.com/api/v2/project/$PROJECT_SLUG/job/$BUILD_NUM
{
  "message" : "Job not found"
}

The v2 API should also supports project-specific API tokens.

POST /pipeline Returns 201 When No Actual Workflow Is Triggered

Example: In my org for certain projects we have a special workflow that is API triggered (via the POST /pipeline endpoint with pipeline params) and reserved for only certain branches (filtered by regex in the .circleci/config.yml for affected projects).

Today we had an issue where somebody was trying to trigger that workflow for a branch that didn't match the filter, and my API wrapper didn't catch it because it wasn't an error response from the API, but rather a 201 instead of the usual 202.

Because the response code differs, we seem to have some ability to discern when the call actually launched a workflow and when it did not. My view: a reasonable API consumer expects a workflow to be actually launched when a successful response code is returned, and if it isn't, they would want an error response to alert them to potentially update their .circleci/config.yml.

Right now I'm in the somewhat uncomfortable position of needing to handle a 201 as a failure, which just feels wrong.

Any chance we could return an error in this case?

Retrying workflows

In v1.1 there was the /retry endpoint which is about to be removed in v2.

Is there a replacement endpoint to support this?
I consider this an important feature.

See also this forum post.

typo in orb reference in docs

https://github.com/CircleCI-Public/api-preview-docs/blob/master/docs/setup-workflows.md#full-example

orbs:
  continuation: circleci/continuation:0.1.2

i believe should be: ('@' symbol)

orbs:
  continuation: circleci/[email protected]

Conditions should allow operators

I'm trying to use the conditional workflows addition proposed here in a real project but I'm finding that it is really inflexible due to only allowing single value truthiness evaluation.

I would really like to be able to do equality comparisons and use logical operators.

It looks like you basically have to introduce lots of extra pipeline parameters because you can't write expressions that would capture the same condition more simply.

when: << pipeline.parameters.build_project >> == "subproject" || << pipeline.parameters.build_always >>

Something like that.