Ask questionsAbility to detect user who initiated build


I am part of a team that maintains a suite of software used for deployment and CI/CD internally within my company. We maintain a set of hosted services that run the actual deployments, as well as a client application used to interact with those services. This client application can be run locally or run within the context of a Concourse pipeline for automation of these deployments. We are currently in the middle of a push to increase the visibility and auditability of deployments made using our tooling.

What challenge are you facing?

With the current stateless design of Concourse and the intentional limiting of information, I lack two very distinct capabilities that are limiting my team's ability to effectively use Concourse:

  1. We do not have the ability to link a particular build to the user who triggered it (or if it was automatically triggered), preventing us from auditing builds or back-tracing issues that arise from an erroneous build.
  2. We lack the ability to detect if we are running within Concourse, meaning we cannot enable selective behavior (such as only permitting certain actions within the context of a Concourse pipeline and not permitting those actions for a local run of the binary, or vice versa) without maintaining two separate editions of the binary in question (one for Concourse, one for local runs), a significant increase in project maintenance.

Of the two, the first one is the more critical for our use case. Our Concourse server is integrated with our corporate SSO system, but the user information is not exposed to the pipelines, so our build process cannot detect who initiated a particular build (or which pipeline initiated it, or if it was automatically triggered). This seriously limits our ability to audit deployments and builds, and do any sort of forensics if we encounter issues with a build down the line (especially since the pipeline-specific and build-specific information appears to be completely deleted if the pipeline itself is deleted). We can collect this information if the deployment is triggered using a local run of the client binary, but not if it is triggered via Concourse.

What would make this better?

Exposing the user information to the build process, perhaps through environment variables or some sort of local metadata service we could curl to. Implementing a solution to 1) will most likely effectively solve 2) at the same time.

Are you interested in implementing this yourself?

Unlikely I'd have the bandwidth to do so.


Answer questions kaedys

I'd rather it not depend on the CLI tool to access that information. User information should be available natively to the build itself, so that the build process can capture that data. It's absolute lunacy that Concourse effectively mandates that all builds are functionally anonymous.

Github User Rank List