added support for build.env

[maxses]

The build scripts can create an file "build.env" in the build folder to feed back environment variables to laminar. After the build, the file is parsed by laminar.

The following variables are used by laminar:

• SOURCE_BRANCH branch used in the SCM-checkout (e.g git) for building
• SOURCE_VERSION release version of the build

[ohwgiles]

Thanks for the PR!

In its current form I'd prefer not to merge into mainline, for a couple of reasons:

• laminar itself shouldn't know about "branches" or "source versions", these are VCS concepts that might not be relevant
• Parsing build.env is kind of a new interface, not sure this can be justified over using laminarc which is the primary interface

I could imagine for example some kind of laminarc tag command that would allow attaching generic key/value metadata to a run.

What exactly are you trying to achieve with this? If it's just showing extra data on the frontend for the job, what is insufficient about echoing it to the console, or redirecting it to an artifact? Is it important that they get database columns?

[maxses]

Thanks for the comments.

Not merging this is fine for me. But i would like to have some discussion. Maybe i can implement it in another way.

Sure, laminar should not handle/know about branches/versions (really not even versions?). But not having this information available in the list of runs (job-view) is a bit uncomfortable.

LAMINAR_REASON could be misused to track this information, but at least "Version" is some information that may not be available at the timepoint of triggering a build (for example 'v0.1.6-7-g5a31-ID28' containing the laminar-RUN and part of the SHA).

Your suggestion to implement something like laminarc tag is probably an better idea to achieve this and more straight forward. build.env was just the simplest way I came up with.

Having the information in database columns is needed to show them in the list of runs (job-view) for example. Filtering could be nice in the future. Imagine an Sourcecode-Repository has multiple Feature-Branches, multiple (active) Release-Branches, a development branch and an main branch, all triggered via nightly builds and via commit.
It is super hard/impossible to find an specific build by having to look at each runs log output or artifacts in order to identify the sources branch.

One possibility would be to introduce "custom fields" for specifying user-defined key/values. In that way, the words "Branch" or "Version" do not show up in laminars sourcecode but can be configured in laminar.conf. e.g.:

LAMINAR_CUSTOM_FIELD_COUNT=2
LAMINAR_CUSTOM_FIELD_1=sourceBranch
LAMINAR_CUSTOM_FIELD_1_LABEL=Branch
LAMINAR_CUSTOM_FIELD_2=sourceVersion
LAMINAR_CUSTOM_FIELD_2_LABEL=Version
# (or some JSON-Syntax for having a single environment variable)

Scripts:

laminarc tag sourceBranch "$(git -C $WORKSPACE branch --show-current)"

In that way the user could extend the shown information to anything he wants (version, branch, GIT-SHA, SVN-Revision, Trigger-Commit-Message, used Toolchain, ...).

Regards, Max

[ohwgiles]

Yes, I think we can definitely provide some useful feature based along these lines with a bit of discussion, and thanks for the added context. I understand it's useful to be able to display extra data in the run list and appreciate LAMINAR_REASON isn't sufficient.

Imagine an Sourcecode-Repository has multiple Feature-Branches, multiple (active) Release-Branches, a development branch and an main branch, all triggered via nightly builds and via commit.

Typically I would suggest that each different type of build would be a separate laminar job. This reduces the need for additional metadata, and it is easy for jobs to share implementations, and easy to dynamically create jobs - you can even create a job on the fly that exists only for the duration of the parent job. This is usually a good fit for things like feature branches or nightly builds, or variant builds using a different toolchain/platform target, but is less appropriate for e.g. publishing version info

One possibility would be to introduce "custom fields" for specifying user-defined key/values. In that way, the words "Branch" or "Version" do not show up in laminars sourcecode but can be configured in laminar.conf.

I think we can do this without introducing environment variables. We could just have one new database column metadata, which would be populated by a json object, the key/value pairs of which would be set by laminarc tag, e.g. laminarc tag version 123; laminarc tag branch foo would result in { "version": "123", "branch", "foo" }. This JSON object would be sent unmodified to the frontend, which could convert it into columns/rows in the table. It would have to union all keys in all runs in the current view to know how many columns to create, because not all runs would necessarily have all the same tags - maintaining consistency here would be up to the administrator.

How does that sound?

[maxses]

Typically I would suggest that each different type of build would be a separate laminar job.

That may be a good solution for most scenarios. I already have >30 Jobs. Even if i split them up, there would still be some information i would like to have available (as you already mentioned). So i prefere the idea of metadata where someone can store the information needed/wanted. That way job is job and metadata is metadata.

We could just have one new database column metadata

That sounds nice. Although its a little bit "JSON-Table in SQL-Table" design, but i can life with that. It brings the benefit that there is no configuration necessary at all. And each job can have different metadata.

So i will implement the laminarc tag command first, if this is ok.

[maxses]

New PR is created. This one can be rejected then. https://github.com/ohwgiles/laminar/pull/208#issue-2211956939