Debugging resources

I am a newbie trying to use concourse.
I have setup a resource of type git which does not seem to be properly setup.
What is the recommended way to check/debug resources setup/functioning ?

Thanks

You can use fly intercept to get into any container that Concourse creates.

It’d be really handy if the payloads to gets and puts were stored somewhere. I can see that this could be a security vulnerability, but then if you’ve got access to that container, you could probably do naughty things anyway?

Does such a log exist?

Reading the documentation, I did not understand that fly hijack could be used for resource containers. Can you point me to more details ?

I found this: https://concourse-ci.org/global-resources.html#intercept-admin-only

Recently, another user was asking for help on Discord about debugging resources, so I thought I’d share some of the information I provided there.

In debugging resources, the idea is to try to be able to call the check, in, and/or out code just like how Concourse would call them. You will need to pass the script the correct request parameters (see https://concourse-ci.org/implementing-resource-types.html for the interface). To get the parameters, some resources are written to save the parameters into a temporary file on the container, so you can use that temp file. Other resources do not log the parameters to a file, so you might be able to temporarily replace the check, in, or out code with a script to capture the request parameters.

Once you have the parameters, you have several options. You can modify the script on the container itself to increase the amount of logging (e.g. set -x for bash scripts), and then call the script with the parameters to see what the resource is doing. e.g. cat /tmp/resource-request | /opt/resource/check. Alternatively, once you have the parameters captured, you can download the code locally and run the tests on your local machine or run it on a docker container on your machine which may make debugging a bit easier.

If you modify anything directly on the hijacked resource container when debugging, make sure you back out any changes after you’re done, as the resource may use the modified code for a while.

That being said, as @DeejayEngineerBetter mentioned, this could be a security vulnerability, so you’ll want to make sure that access to hijack containers is secured.

edit: To hijack a check container, you can run fly -t your-target hijack --check=your-pipeline/your-resource-name. To hijack resources that are get (in) and put (out), you hijack the job the resources are associated with as follows: fly -t your-target hijack --job=your-pipeline/your-job-name. fly will then ask you which step of the job you want to hijack.

2 Likes

@edtan Thanks for this long and useful answer !

However, I still do not get how to use hijack to debug get and put.

I have some jobs without any task that build docker images.
In that case, fly -t your-target hijack --job=your-pipeline/your-job-name returns

no containers matched your search parameters!

they may have expired if your build hasn't recently finished.

( I do use my pipeline and job :wink: )

If I add a dummy task, guessing that hijack does not like taskless jobs, I get right into the container of the dummy task. But does not get asked which step to hijack. Could it be because check has found no new versions ?

It’s possible that the get and put step containers are getting cleaned up before you’re able to hijack into them. You could try adding a sleep 60 to your dummy task - this might keep the get and put containers around long enough for you to hijack them.