When a Circle CI project is not "setup to start building", and you never the less use the Circle CI API to trigger a Pipeline execution for this project, what does the Circle CI API v2 answers ? HTTP Response is 201 Created !!!! What an un-expected test result !!!
* If I had to give a suggestion, I would say that in this case, the Circle CI API v2 should return :
* an HTTP Response code 403 , which is not an authentication error meant code, like 401 : The HTTP 403 Forbidden client error status response code indicates that the server understood the request but refuses to authorize it. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401
* along with a JSon response payload including an explicit error message, something like :
```Json
{
error_mesage: "You tried to trigger a Pipeline Execution for the <project_slug> project,but this project is not setup to start building"
}
```
Finally note, and this is most important :
pipeline_number
gets incremented by this unlegitimately triggered pipeline execution, which hurts a lot any CI CD System's Accountability, if based on Circle CI.
Finally, please find all details here on github : https://github.com/gravitee-lab/GraviteeCiCdOrchestrator/issues/28
## 5 days later : an actual idea
I 5 days later, add an actual new feature idea for Circle CI :
* I kind of felt like hacking on CircleCI engineering team minds... and
* maybe you left that anomalistic behavior,because it is covenient, to run tests.
* And related to that, the accoutability matter (very important),I suddenly comeupwith one, I thinkvery valuableidea for Circle CI API :
Why not a "Test mode", for the Circle CI API ?
Many APIs have such a test mode, especially coming from the payment / e-commerce industry (stripe.com, snipcart.com, etc...) :
Well actually this Test mode pattern naturally extends to all business' who sell their API consumption, and in the Circle CI case, would be very valuable, especially for the case I above described.
Anyway, for any API, which is sold with things like subscribe plans, well the concept of a Test mode, totally makes sense, doesn't it ? (An "ON/OFF" button for test mode)
Running Circle CI API in test mode", would be soooooo valuable : imagine your customers, they can now run "dry runs", and manage those dry runs so easily... just using :
* either an on/off button , turning on and off "test mode" :
* for a given pipeline (CircleCI "project")
* or for all "projects" in an org
* or for a given User ("Test mode" only turned on when using a CCi Token from this user, others are running normally)
* and accountability/analytics clearly separates the executions that were in test mode,(and those who were not)
* that's gonna be a huge money saver for your servers : we all run Circle CI pipelines "just to test the CI", and at least for30% of them, we just care about checking if config.yml is fine, so no need to actually run any executor). That'd be a "flat test mode/fat test mode" (yourjusttesting if you are using properly the Circle CI API,andif thecofnig.yml is fine, or webhooks, etc... ). Fat test mode:you actually run the executor, flat test mode, you don't run the executor.
Anyway, for any API, which is sold with things like subscribe plans, well the concept of a Test mode, totally makes sense, doesn't it ? (An "ON/OFF" button for test mode)