Hi Jesse,
thanks again for the fast response!
On Wed, May 02, 2018 at 06:20:34PM -0400, Jesse Glick wrote:
> On Wed, May 2, 2018 at 10:50 AM, <
thomas.w...@de.amadeus.com> wrote:
> > The goal I am trying to achieve is a deep insight into the CI/build/etc
> > pipeline.
> > So if for example a user of the platform complains about slow builds, we can
> > see exactly where time is spent.
> > Waiting for executors, running a certain shell script, a single maven step
> > and
> > so on.
> > And all of this would be stored in a uniform way for queries and analysis.
>
> All of that metadata is already available via `workflow-api` metadata
> calls. It is unclear to me why it would need to be made available to
> steps inside the build itself as environment variables, as opposed to
> via REST endpoints on the build URL or something (akin to what Blue
> Ocean uses).
The steps are supposed to report their own internal information too.
By exposing the id of the current state from Jenkins to the build step both
executions can be correlated and an end-to-end trace of the complete
build-infrastructure can be shown.
For this it is important that each single step has its own identity, that can
be accessed from within the step (eg maven in the `sh` step).
I am honestly not sure how it would be possible to get information for a
specific step from the REST API without having a way of knowing the identity of
the current step in the first place.
By passing this identity via environment variables I hoped to keep the changes
to the code of the users of build-infrastructure minimal to non-existent.
At the same time it would provide optional extensibility for the users to also
instrument their own code and hook it up to the existing information about the
Jenkins build.
The whole data collection can be extended far before and after the build pipeline,
including the original trigger of the build, external message queues, non-Jenkins
resource provisioning etc.
> > As everything goes through a shell fair enough.
> > I somehow thought `sh` would be like plain `execve`
>
> There is JENKINS-44231, though the most straightforward implementation
> would not handle prohibited environment variables.
The restriction is not an issue. It was a problem of understanding on my part.
Thanks for the pointer though, as I personally much prefer executing things
without having the mess of a shell in between.
(Except in the many valid cases where it is necessary)