Job Information available in Task Containers

[Anthonyhawkins]

I'm looking for a way for a task container to be self-aware of what pipeline/job/task/build it's in, and possibly have that exposed in ENV somehow. This resource implements what I'm looking for https://github.com/SWCE/metadata-resource but it's a flawed approach, in my opinion as the issue we have with it is because resources are shared amongst the jobs and tasks which get it, the metadata for JOB A is showing up for JOB B etc. and it's a mess.

I don't know if it's available on the filesystem somewhere but was wondering if anyone had similar need. We want to avoid hard coding params into every task to tell it what pipeline/job/task it is as I think there might be a more elegant way of determining this.

Why do we need this info?
We have a lot of jobs which run tests and monitor our platform and when those jobs fail they send out an alert. The alert contains the team/pipeline/job name so whoever get's the alert has a pre-generated concourse link to immediately view.

Thanks for the help.

[evanchaoli]

See #3179

[Anthonyhawkins]

Thanks this answers the question. We're following the resource approach now but the issue we're seeing is that a resource version (which contains the build info) is being used for multiple jobs. i.e.

version X is being used for Job A-build-4, B-build-6, and C-build-4 etc.
but the metadata for the resource only contains info for Job-A-build-4 this means B and C are not accurate.

It seems the check runs every 1m but the first JOB which uses the resource gets to set the info and other jobs which also get the resource are stuck with it until another check runs, etc. Is there a way to ensure that when a job runs a get on a resource it's always running a check before it gets it to ensure the info is always accurate and one version of the resource always corresponds to one build ?

Thanks

[chenbh]

It sounds like the main reason you want access to these env vars is purely to generate a notification. The Concourse-y way to do this is probably to model the notification channel as a resource, and then put to this resource to generate the alert.

One possible solution is to create a custom resource type with no-op check and in scripts, and use the out script to send the notification. The concourse team uses a slack notifier resource to accomplish something similar in our own pipelines: https://github.com/concourse/ci/blob/67ca3a544bcc76857134f79e4a62091cc8d2faaa/pipelines/concourse.yml#L93-L97