Add job label/display name

[Snaipe]

The build summary screen can become a hassle to read for projects with a complex build matrix.

It would be great if we could add names/labels to specific jobs in the matrix.

The visual result could be something like this:

And the .travis.yml config, like so:

matrix:
  include:
  - name: Build with foo as bar

Having no display name would simply blank out the relevant section.

This, if it were to be implemented:

• Would allow developers to see at a glance which builds failed an succeeded -- currently, I have to count the index of the job or read its log to see that a job cross compiles for architecture X or Y.
• Would allow developers to sum up the contents of the environment field to the right, which can become easily cluttered when you have 3+ variables defined in your matrix.
• Would allow developers to make a distinction between otherwise visually identical builds (e.g. builds that only differ by a secure variable, like builds testing on two specialized remotes machines with credentials, or builds that have the same environment variables but use different apt packages).

A possible workaround could be putting a _ environment variable -- with the name as a value -- at the start of the environment list (not tested), but this is hardly convenient and is visually inconsistent.

[jimdebeer]

yes please!

[BanzaiMan]

This attribute, if implemented, is meaningful only for those jobs that you explicitly include in matrix.include (because others are created as a cartesian product of matrix dimensions). In such cases, though, you can explicitly define just as easily an environment variable which will show up in the current display.

matrix:
  include:
    - env: NAME="Build with foo as far" VAR1=VAL1 VAR2=VAL2

[jimdebeer]

Its only a cosmetic feature --- since env vars don't really look nice

see the difference

looks pretty!

looks ugly!

[jayvdb]

While this may help individual teams, I think it detracts from the travis community, as it means there is no longer a common logic for understanding a build matrix screen. If it is done, I hope it is togglable, so someone can switch back to raw envvars.

Arch is already a separate column shown with an icon. Maybe add a variant icon for 32 vs 64 is needed?

IMO debug vs release should be a builtin travis feature (are there any supported languages where tbis doesnt make sense?) and shown in another column using an icon. Not sure about deploy.

[Snaipe]

@jayvdb

While this may help individual teams, I think it detracts from the travis community, as it means there is no longer a common logic for understanding a build matrix screen. If it is done, I hope it is togglable, so someone can switch back to raw envvars.

It should of course be completely optional. This is only relevant for non-trivial, hand-crafted build matrices (typically on multi-arch & cross-platforms projects w/ assembly)

Arch is already a separate column shown with an icon. Maybe add a variant icon for 32 vs 64 is needed?

Arch does not suffice by itself because of cross-compilation.

Here's my build matrix: https://travis-ci.org/Snaipe/Mimick/builds/141036082

Can you tell which builds are i386, x86_64, AArch64, ARM? Not being able to name jobs for what they simply are is a hassle. I am reluctant to add more architectures to the CI config precisely because of this.

IMO debug vs release should be a builtin travis feature (are there any supported languages where tbis doesnt make sense?) and shown in another column using an icon. Not sure about deploy.

I don't see working in practice, as this is highly dependent on both the language and the build system used. How would you make that work for projects using autotools for instance, where the debug mode is a user-defined flag?

[jayvdb]

As you are cross compiling, that should be in the Compiler column of Travis build matrix. Currently it says "gcc", but that isnt really true. The same is roughly true of multi-arch platforms.

Wrt your config specifically, wouldnt it be enough if Travis build env column said "CONFIGURATION=Debug, *i386-env", in which case it is a minor change to the UI to better show complex yaml. Then you could defined x86_64-linux-debug and it would appear as "*x86_64-linux-debug" in the env column -- at least then it isnt an arbitrary name; it is a defined name elsewhere in the yaml.

As for debug, on most languages, it is quite easily set with an env var.
For C/C++, it is CFLAGS and CXXFLAGS respectively, and the usual approach is to use -g or -O2. autoconf understands those. With direct clang invocation, I think llvm-config needs to be used, but I am rusty on that. The build script could still fiddle with those defaults env vars for project specific preferences wrt debug/release, but it isnt hard to have sane defaults which tease out bugs. (and then it would be possibly to add support for fancy config, such as building only debug versions by default for branches (so it is quicker), and enable release builds on master.

[swarren]

We're hitting this issue in U-Boot too, and the proposed feature is exactly what I was searching for. It seems like a good generic fix for the issue to me.

Naming jobs as an implicit side-effect of the environment variables that are set seems like a hack to me, especially if I wanted to just run different scripts instead rather than setting environment variables to influence the operation of a different script.

For reference, the WAR I applied to U-Boot's Travis config:
https://patchwork.ozlabs.org/patch/686225/
[U-Boot,1/2] travis-ci: set env vars to name jobs

[mdeguzis]

What I really am looking for, is the ability to have labels for each env outputted as a clean label. Instead of just "Build stats: passing" I want sub labels for each job/env that runs. This would be ideal for folks who run multiple passes. My use case here is multi-distro builds via Docker images.

[joshk]

I like the idea of supporting this, and would be interested in adding it when explicitly listing jobs and their configurations.

I'll be adding this to our Roadmap for Q1 of next year.

[JohannesBeranek]

@joshk did anything happen on this?

Another reason an env var doesn't always work: As soon as env vars are different, the cache can't be shared anymore (which IMHO is a different issue - would be good to ignore certain things for cache dependency or define the exact cache dependency)

Especially with the new Travis Stages feature this has become more relevant again.

[simonvanderveldt]

Another reason an env var doesn't always work: As soon as env vars are different, the cache can't be shared anymore (which IMHO is a different issue - would be good to ignore certain things for cache dependency or define the exact cache dependency)

This has just tripped me up. Eventually I noticed the mention of it in the cache docs, but I totally didn't expect env vars to have an impact on which cache is shared.

This means I'll have to remove those env vars and I only used them to identify what each job in the matrix was doing, so now I'm back to a list that doesn't really tell me anything about what each job does :(

@joshk Are there any updates on this? We're past Q1 2017 already ;)

[gnzlbg]

It's 2018. Any updates on this? @BanzaiMan ?

[shs96c]

Adding to this: without job labels, this build provides very little actionable information unless someone delves into the outputs themselves:

https://travis-ci.org/SeleniumHQ/selenium/builds/331260746

We don't want to use environment variables since the cache warming stage can be expensive and is slow, but without them it's impossible to tell which of these are the JS tests, and which ones are the Java tests (or which browser is being used)

[gr2m]

As a workaround, we do this

script: npm run $COMMAND
jobs:
  include:
    - stage: test
      env: COMMAND=test:unit
    - env: COMMAND=test:integration

instead of this

jobs:
  include:
    - stage: test
      script: npm run test:unit
    - script: npm run test:integration

Example: https://travis-ci.org/octokit/fixtures/builds/336419815

[azu]

I have similar problem on Travis CI API.
https://developer.travis-ci.com/resource/job#Job
API does not includes env variable.
I want to get custom name or env value from job id.

[pauldraper]

@gr2m the problem with that as @JohannesBeranek, @simonvanderveldt, and @shs96c have stated, the env variable "workaround" affects caching behavior.

In short, there is no possible way to mark a job as "test", "lint", or "integration" without structurally altering how Travis treats the build.

[wking]

The Travis GitHub App Checks support includes a table with columns for matrix variables. For an example with a Rust-version column, see here. I don't know if changing script will create a new column or not.

[plata]

I'm currently using build stages to mitigate this issue, i.e. I put single jobs into their own build stage to name them. Of course, this is not really a solution because it means that the jobs cannot be executed in parallel anymore. However, the alternative is that people do not know what's wrong with their pull requests, so I'm willing to accept that issue for now.

[jakul]

Travis now supports naming jobs within a build matrix - https://docs.travis-ci.com/user/customizing-the-build/#naming-jobs-within-matrices

[ojab]

Unfortunately job names is not displayed on github checks page, so it's not possible to see what exactly fails without going to travis

Is there plans to add it to notes?

[plata]

+1 for @ojab. Just noted the same.

[swarren]

Another issue: The list of builds includes the job name, which is great:
https://travis-ci.org/swarren/u-boot/builds/409925753
However, as soon as you click a link to an individual build which has a name:
https://travis-ci.org/swarren/u-boot/jobs/409925755
... the job name isn't shown anywhere, so you have to remember which link you clicked. The job name probably should be displayed prominently in the header, e.g. along with commit/compare/branch details (just below the ToT commit description text), but certainly somewhere.

[ianha]

Would really love to see this supported in a robust way. It would help save our team time debugging and make us more productive. Supporting this would really help all the teams that use Travis.

[joshk]

@swarren we are working on this right now, and hope to have something ready in the next week or two.

In general, since Job naming is supported, can we close this issue?

[swarren]

Yes, I'm fine with closing this if you open another issue to cover displaying the job name within the job page itself. Note that I'm not the original issue requester here though.

[Snaipe]

I'm fine with this being closed. Thank you for addressing this. :)

[joshk]

@swarren we should have this deployed in the next week or two max

[joshk]

@Snaipe thanks for closing the issue :)

[drdavella]

This is awesome, thanks for the work! Is there any chance you'd be able to continue displaying the environment variables in addition to the name? It seems like in most cases there's plenty of room.

[giampaolo]

How do we use this? What's the directive name? "name"?