Submit a Feature Request
If you're unsure of which feedback category to select, please reference our guide in the changelog or use the ""uncategorized" bucket so we can get your feedback to the right team.
Expose GitHub Webhook Events, and Status Message API
Currently, CircleCI has the ability to build an app on the creation of a PR from a GitHub, and, as part of the build, can be directed to execute scripting that deploy builds to some platform service, like AWS. However, there doesn’t seem to be a way to execute scripts when a PR is merged/closed. It would be incredibly useful if CircleCI could expose that (and perhaps other) webhook(s), and allow for, scripting to run after a PR branch has been closed/merged, for example to clean up a temporary deploy to a platform, such as AWS. By way of example of the feature set I’m describing, here’s a link to Heroku’s Review Apps feature. Certainly it’s true that Heroku has a different business domain, where they are a fully fledged platform, however the feature hinges on GitHub API, for which there could be many pipeline related use cases, making it more relevant to CircleCI. To better illustrate the virtues of the use case I am eager to solve, temporary PR deploys are valuable in order to manually confirm PR change-sets, especially where QA of frontend applications is concerned: “Does this style change work responsively?” “How does it affect “x” feature, under “y” circumstances?” One peripheral aspect of this would be messaging a status back to the PR, with a link to the deploy. I can appreciate that the latitudes for this are something that would represent another feature enhancement to the CircleCI API, of a similar magnitude. Realted feature requests, both about exposing GitHub webhooks / custom status messages generally, and about merge actions specifically are pretty numerouse accross the CircleCI Discuss forum. I think there’s also an argument to be made to enrich integrations with services (klike AWS and GitHub) that represent a dominant market share in their respective domains. This all amounts to a compelling argument that there is demand for this feature-set, and that it relates to a multitude of use cases. Hope you’ll consider it! Many thanks for your continued committment to the community, and for the really awesome product! CCI-I-177
Behavior triggering pipeline of CircleCI project not set up to start building (Circle CI Test mode?)
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 * 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 : ## 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 ( , , 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)
Load More