Job labels (name:) improvement proposal

Travis CI Discussions & Feedback
, ,
1

Thanks for implementing this nice feature along with more complex improvements!

I’ve tried it out and it seems to be introducing some UX discomfort when looking at the job list in UI:

  1. These new labels effectively mask other useful information: current stack with language version (Python:3.7) and env var values.
  2. It’s not obvious what’s the label on job page when someone gets a link to such (job log), to figure this out one needs to go back to the list and connect the dots.
  3. It’s incompatible with matrix-generated jobs, based on env vars in particular.

Those nitpicks could be addressed fairly easily:

  1. Add this label to UI @ https://travis-ci.com/{{ org }}/{{ repo }}/jobs/{{ job_id }} page

  2. / 1.
    The first thing which comes to my mind is to leverage the usage of env vars. It doesn’t have to be a full evaluation as during runtime: there’s already a mechanism, which works with those outside of jobs on build level — conditions.
    Think of the following example:

     env:
   matrix:
   - BUILD_WITHOUT_EXTENSIONS=
   - BUILD_WITHOUT_EXTENSIONS=1

    This would generate a number of jobs for different envs. But there’s no way to indicate on UI the differences:

    name: Tests

    This would hide that Python 3.7 . . . . . . . . . . . . BUILD_WITHOUT_EXTENSIONS=1 hint from UI and to figure out those things one would be forced to go to a job and either read-through the log or read JSON-formatted config.

    However, should you enable smth like

    name: [Python:${TRAVIS_PYTHON_VERSION}] Tests with ${BUILD_WITHOUT_EXTENSIONS}

    It would be a game changer and it seems like it shouldn’t be hard to implement taking into account previous experience with conditions feature.

–Sviatoslav

1 Like
2

Hey @webknjaz! Thanks so much for the suggestions - it’s a good point… We’ve been thinking of job names as a sort of quick label for jobs that are explicitly showing up in a matrix.include section or jobs.include (for stages), but I think generating names for generated jobs based on env vars, is a good way to make them translate to more situations - especially when you have large matrices testing many different components? That sound like the right summary/use case?

Definitely will keep this in mind for the future, and I’m super interested to if this comes up from other folks as well. It seems like it might be a really broadly applicable improvement.

1 Like
3

Yes, that’s exactly what I meant :slight_smile:
Thanks!

1 Like
4

Hey!

I saw newly added info on the job pages. It looks great! Thank you! You rock!

Oh, by the way, do you consider that part of my proposal about env vars interpolation?

1 Like