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.

We had some very old jobs stuck in "queued" state for months, which were clearly never going to run. These jobs were not present on any nomad nodes, but could be seen via the API and the web UI. When I asked support how to get rid of them, they gave me instructions for how to use kubectl exec to log into a frontend pod and use the REPL to run circle.http.api.admin-commands/force-cancel-build on each job. That worked, but there should be a button on the frontend web UI to do the same thing. Jobs on Server can get lost into this kind of zombie state, and it's not practical to expect people to run a REPL directly on the frontend pod to clear them out - and it's also more risky to do so.

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/ .

Like the cloud feature request: https://circleci.canny.io/cloud-feature-requests/p/ability-to-specify-which-environment-variables-are-masked-by-secret-masking This is specific to bring this to Server, if brought to cloud.

how about using word break and showing everything instead of shortening and using ellipsis

As discussed in #132894, we can see number of skipped tests in the tests insights but not mentioned in the reported count of tests. There we can see only number of tests failed and number of tests considered to run.

It would be nice to support container runner on Server.

Allow for either nodeselector or nodeaffinity rules (preferred) so that circleci can be run on a unique node group within a shared cluster

Currently GitHub SSH is locked to port 22, so the ability to specify a different port in the Config section (along with the github hostname/secrets) and then have that fed through to the dispatcher, checkout scripts and whereever else uses ssh or uses ssh host keys for verification would be beneficial.

Both of CircleCI server3/4 don't support applying for ARM AMI images. (only one AMI image can be configured at the moment) https://circleci.com/docs/server/operator/manage-virtual-machines-with-vm-service/#linux-image-aws There are strong needs for companies already using x86 based AMI images, and want to add ARM customization images as well for users. If we can configure both x86 AMI and ARM AMI images on server4 would be worth it