I see the attached screenshot, but I don’t see option in CircleCI that tells me what jobs are on version 1.0 and what jobs are on version 2.0.
See on the right-hand side of the Jobs page in the UI - jobs should all have
2.0 next to them.
You can also get a list of projects still using 1.0 configuration by using this script.
A column name like “CIrcleCI Version” on that field would be helpful. My junior developers are going to be completely lost when looking at their builds.
Hmm, not sure - the UI is busy enough on that screen already. But you can raise it if you wish.
2.0 is in the detail view as well, and has a tooltip of
This job ran on 2.0. Maybe there’s scope for extra on-screen info here, but this screen is also pretty brain-overload!
I’m thinking about the new developers that will be using the system.
If the column is not labeled, the number is non-sensical to them. I’m trying to minimize both a) training, and b) digging for clues. having the version number on the dashboard and labeled is a great idea. I may raise that one. When I hover on the job name to bring up the tooltip, I don’t see a version number. Just more information about the job name (See attached).
If I understand you, you’re saying the “Version:” line in the YAML file specifies what version of the CircleCI server to run the build on. There is nothing that I’ve seen that tells me this is what that line is for. I mistook it for a freeform version number that I can set to whatever version I want so I can version my own YAML config files.
Not telling you what to do, but anything “Easter egg” like or passed on through tribal knowledge doesn’t work well when the new hires have 10 minutes to figure out why a build failed. I’m just sayin.
Yep! That should be in the docs, is it not?
Indeed - and perhaps I should clarify, I am not a CircleCI employee. I’m a happy (free-tier) user and board-dweller. Where Discourse labels me as a Regular, CircleCI folks are marked as CircleCI Employee (see Sara’s usercard above).
It’s all good.
I’m looking at upgrading CircleCI so we can use it for our whole group. We’re trying to standardize on a single build server. So, one of the considerations for this production environment is to make sure people can quickly diagnose and solve issues in the dead of night when the builds stop working.
That’s why I’m interested in some “guard rails” on configuration parsing.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.