Server

Server 2.x had a document on setting lifecycle policy and that helped to keep the s3 and storage cost low with deleting unnecessary data. However server 3.x and 4.x did not have these documentation and it would be greatly appreciated if there is a guide to set these. Also we are not sure what the object prefix is for job artifacts. It seems S3 prefix filtering also doesn't work with wildcard patterns, https://repost.aws/questions/QU0ssGaRmOQTCvPj0O0w6Cug/questions/QU0ssGaRmOQTCvPj0O0w6Cug/does-s3-filtering-allow-wildcards-for-prefixes-in-sqs-event-notifications , so we cant express say /artifacts/picard/* /artifacts/ .

This feature request is to create an API endpoint to allow CircleCI Server admins to query the API to receive a list of a followers for a project. Currently this requires REPL access.

Financial Institution: - image: our_ecr_image:latest aws_auth: aws_access_key_id: AWS_ACCESS_KEY_ID aws_secret_access_key: AWS_SECRET_ACCESS_KEY

When vm-service fails to create an instance, it would be great to know this to get ahead of incidents. It would be great if these could be tagged with docker-engine true/false.

When troubleshooting vm-service issues, it would be great to configure the timeout where it destroys the VM to easier troubleshoot any issues that are arising whether they are on the VM or the Cluster.

Server customers should be able to set retention periods (~1-2 years) so they can ensure that their databases have predictable sizes. This will also allow migrations to run much quicker and allow customers to control how much data they want to retain in their installations.

It would be helpful as a customer to have a Nomad Autoscaling check - a test that runs enough jobs that would cause nomad to spin up 5-10 instances and scale down afterwards

At the moment the metrics are very basic and don't provide a lot if insight into how CircleCI Enterprise is behaving at the user level.We would like to have the following metrics to be able to tune our installation to our user needs and build dashboards so the developer teams can monitor their workflows.- build lifecycle metrics: succeeded, failed, queued, paused, running builds count- build duration- filter by: repo name, job name and workflow name CCI-I-917

Request: Being able to obtain accurate and up to date Load Test Metrics on ALL internal services used by Enterprise Server. For new customers looking to develop a Proof of Concept, that require a deeper knowledge of build thresholds. Example of typical requests: Can CircleCI Queue 1000 jobs with a single stage for pool (1) that each sleep for 15 minutes. For existing customer, this will greatly improve support process and pipeline. Example: The output processor service its under constant strain, however we do not know the upper limits of what this service can handle. Which typically results, in support responses of "lets just increase the memory limits and hope that it works". Which is a horrible customer experience.

Right now, Cloud organizations can manage their storage usage retention period for artifacts, caches and workspaces. https://circleci.com/docs/persist-data#custom-storage-usage It would be great if this same feature can be available for Server instances. This way, various organizations on Server can also manage their data retention period easily. Right now for Server (3.x), there is an option to set overall storage expiry. However, this is Server-wide, and not granular at the organization or project level. https://circleci.com/docs/server-3-install#s3-compatible