Sometimes it's helpful to be on the same machine as your tasks so that you can profile or inspect them as they run or see the state the machine at the end of a run. Due to Concourse running tasks in containers on remote machines this would typically be hard to access.
To this end, there is a
fly intercept command that will give you an
interactive shell inside the specified container. Containers are identified
by a few things, so you may need to specify a few flags to hone down the
results. If there are multiple containers that the flags could refer to, an
interactive prompt will show up allowing you to disambiguate.
fly hijackis an alias of
fly intercept. Both can be used interchangably.
For example, running the following will run a task and then enter the finished task's container:
$ fly -t example execute $ fly -t example intercept --step build
Be warned, if more than one person is using a Concourse server for running one-off builds then you may end up in a build that you did not expect!
Containers are around for a short time after a build finishes in order to allow people to intercept them.
You can also intercept builds that were run in your pipeline. By using
--step you can intercept a specific
step from a build of a job in your pipeline. These flags also have short
forms, like so:
$ fly -t example intercept -j some-pipeline/some-job -b some-build -s some-step
--build can be omitted, and will default to the most recent
build of the job. One-off builds can be reached by passing in their build ID
--build which can be found on the build list page.
--step flag can also be omitted; this will let you pick the step
interactively if you don't know the exact name.
Resource checking containers can also be intercepted with
$ fly -t example intercept --check some-pipeline/some-resource
A specific command can also be given, e.g.
fly intercept ps auxf or
fly intercept htop. This allows for patterns such as
intercept ps auxf, which will continuously show the process tree of the
current build's task, even as the "current build" changes.
The working directory and any relevant environment variables (e.g. those
having come from
params) used by the original process will also
be used for the process run by intercept.