More accurate insights/.../workflows endpoint
The insights/.../workflows/:BRANCH endpoint in V2 returns only completed (success or failed) endpoints; I'd like a way to programmatically find (and cancel) a currently-running workflow. Specifically: when one job fails due to flakiness (of our test suite), I want to immediate cancel-and-rerun the rest of the build, rather than wait for the build to finish, and _then_ rerun-from-failed. More ideal is to let users re-run failed jobs without having to wait for unrelated jobs to finish.
Programmatic Cache and Artifact Access
Give full access to the project cache and artifact buckets from within the project. Programmatic access will allow for more complex orbs which can intelligently and dynamically save and load cache based on inputs from the user. Example: https://github.com/CircleCI-Public/node-orb/issues/63 The node orb supports a command to cache for multiple package managers, each of which is handled differently. Currently the orb makes use of many "when" conditions to determine what paths to cache and load. this has been able to emulate program logic to a point, but has limitations. For example, the number of cache keys provided to the restore cache step, or the paths on the save step cannot be dynamically set via an orb or otherwise. Suggestion: give access to cache and artifacts via an API via a run-specific project level key.
Public API to get the last successful build for a specified job
Sometimes I need to get the last successful build for a specified job. Currently I use the API to list builds and filter by jq like below. $ curl -s " https://circleci.com/api/v1.1/project/:vcs-type/:username/:project?circle-token=:token&limit=100&filter=successful " | jq -r '[. | select( .workflows.job_name == ":job_name" )] | max_by(.build_num).stop_time' But it's complicated and it becomes more difficult in the case that the last successful build for a specified job is not in recent 100 builds. So it will be helpful if there is a public API to get information of the last successful build for a specified job. FYI, Jenkins has an easy way to retrieve last successful build. https://stackoverflow.com/questions/31508603/how-to-retrieve-build-id-of-latest-successful-build-in-jenkins CCI-I-693
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
Expose build artifacts for "latest build of the master branch", instead of for a specific build number
Build artifacts can produce useful information, such as documentation and performance graphs. However, there are typically two different scenarios where someone wants to look at a build artifact: I want to see how this change will modify the existing documentation/performance I want to see the documentation/performance for the latest commit on the master branch For either scenario, seeing the build artifacts for the latest commit on the master branch is important. However, there doesn't currently seem to be a way to expose that concept. Build artifacts are only exposed via URLs that contain the CircleCI build number. I would like CircleCI to expose URLs that contain a branch name, instead of a CircleCI build number. This URL could be used to refer to build artifacts in an arbitrary build. When a client resolves this URL, CircleCI should issue an HTTP redirect to the most recent CircleCI build for the latest commit of that branch. Here's a specific use case: My project builds HTML documentation. I would like to include a link in the README to point the reader to the latest version of this HTML documentation. I would like CircleCI to build and host this documentation for me via the build artifacts feature. I need a stable URL to put in the README file, that will reliably result in the latest version of this HTML documentation. CCI-I-228
Support parameters when triggering a pipeline
The new "trigger a build by project" endpoint in practice triggers entire workflows and not singular jobs. In other words, it does not support specifying a job to trigger via build_parameters the way the other API job trigger does.It would be greatly appreciated if the new endpoint could be made to support build_parameters so as to target particular jobs and not entire workflows. Our primary use case for wanting to trigger jobs outside of a workflow context via the API is ad-hoc mobile app submissions via our Hubot app in Slack. I imagine there would be other uses - there are plenty of opportunities for CircleCI-powered automation outside of a workflow context. This would be especially helpful given that the other API job triggering endpoint is not supported when using the 2.1 configuration. CCI-I-690
Created a pipeline level "updated_at" api value
Create an attribute of the pipeline API response that has an "updated_at" value which represents the latest execution state update of the underlying windows/jobs See https://discuss.circleci.com/t/updated-at-field-does-not-show-actual-updated-time-for-rest-apis-that-list-pipelines-get-a-single-pipeline-data/38316/11for more information.
Add deploy keys via API
Hey There,I read this https://circleci.com/docs/1.0/adding-read-write-deployment-key/ and have already been able to do this through the ui. I'm wondering is it possible to automatically do this for each project? or at the very least a way to do this through the api? We are a multi repo shop and having to add this to every build is very difficult with the number of repos we currently have (and it's growing!). CCI-I-154
Expose updated_at env var field
We currently return created_at, but not updated_at. The latter is a much more useful piece of data to return since it pertains to secret rotation/changes. It would be ideal to return both of these values in env var data, e.g. https://circleci.com/docs/api/v2/#operation/listEnvironmentVariablesFromContext We already have this data in our DB; it's just a matter of including it in internal and public API responses.
Expiry token for type: approval jobs
Example: - approve_release: type: approval requires: - checkout_and_build filters: branches: only: /master/ expiry: 24h Reasoning: Jobs with type: approval require manual confirm/cancel, and as such are a good control method for jobs that don't need to be run every build, or builds that require review before completion (e.g. releases). One use we have for these job types is to build docker images from successful builds on the fly. We don't need docker images for every build, and there are many builds in a day, so the approval jobs pile up. We don't need any builds older than 24hrs, so a suggestion to prevent a build up of on hold jobs (not sure what impact this has on a CircleCI cloud/personal server) is to introduce an expiry token as part of the workflow description. CCI-I-181