Fly Containers show check types as none

[goldstar611]

Bug Report

When running fly -t target containers the output that is given for check containers is incomplete. Specifically it shows all stats for check containers as "none" which makes it hard to seek out a specific check container for debugging/development purposes.

(summarize the issue)

Steps to Reproduce

fly -t target containers

Expected Results

Output from fly containers should have pipeline and name fields populated

Actual Results

Output from fly containers shows pipeline and name fields as "none"

Additional Context

user@concourse-dev:~$ fly -t local containers
handle                                worker          pipeline  job   build #  build id  type   name  attempt
4ad24e07-5175-42f7-4426-234a18bcce0c  kernel-builder  none      none  none     none      check  none  n/a
6c0d486f-7420-4147-4b7b-dc2511ee132a  kernel-builder  none      none  none     none      check  none  n/a
73712e9d-f668-4846-4238-4c93317d96f3  kernel-builder  none      none  none     none      check  none  n/a
903f6271-2106-4b06-7852-9cacf9c2b1ed  kernel-builder  none      none  none     none      check  none  n/a
ac4cf4a4-fa67-4c29-4459-afdb54d90972  kernel-builder  none      none  none     none      check  none  n/a
d9186a6d-0d50-4dc8-566b-9c6cb5962300  kernel-builder  none      none  none     none      check  none  n/a

Version Info

• Concourse version: 5.1.0
• Deployment type (BOSH/Docker/binary): binary
• Infrastructure/IaaS: bare metal
• Browser (if applicable): N/A
• Did this used to work? I don't think so

[clarafu]

Check containers are shared between teams and pipelines that have resources with same source configuration and type, which is why the check containers do not have the name or pipeline fields populated. We could try to go backwards from the shared check container to find the specific resources or pipelines that use it?

[vito]

I don't think we'll be doing anything about this; it's been like that for years for the reasons @clarafu mentioned, and we're actually on a different path now which would likely remove them from fly containers altogether: #3079

[goldstar611]

Check containers are shared ... that have resources with same source configuration and type,

That "resource type" information is exactly what I'm looking for when I run fly containers and I think displaying that would be a step in the right direction for debugging/development, but the fly containers columns don't really allow for that as-is (although the name column would be the closest if I was forced to choose).

Since the issue is being closed as I type, I'll go ahead and say we're developing a custom resource now that concourse ci is no longer a single fat binary and fly containers is useful to then hijack the right container when things get weird.

[vito]

@goldstar611 We're thinking about further debugging improvements for resource checking, fwiw - we want to get away from hijacking check containers because there are legitimate security concerns once they start being shared across teams. We're planning to instead have some sort of fly debug-resource command which will provision you a fresh check container. We don't have an issue written for this yet, though.

[clarafu]

Not sure if it'll help but as a workaround you could use the database to find the right container with queries such as SELECT c.handle FROM containers c JOIN resource_config_check_sessions rccs ON c.resource_config_check_session_id = rccs.id JOIN resources r ON rccs.resource_config_id = r.resource_config_id WHERE r.name = ?.

[goldstar611]

YES! That is absolutely helpful for development. Thanks for the insight, I had not thought about deferring to postgresql for such information.