Builds in project converted to 2.1 syntax have numeric suffix

Feedback & Bug Reports
#1

I started converting a project to use some of the new syntax provided by the 2.1 configuration, and it broke some of our GitHub branch protection requirements for which builds are required to pass because some of the job names within the build were changed. In particular, of the 10 jobs within the workflow that I was working on updating, two of them had a -1 suffix added onto them, e.g. build became build-1 and integration_tests became integration_tests-1. I wasn’t able to find documentation on this anywhere.

One thing that might be related is that I was experimenting with the “reusable jobs” functionality to have several deployment jobs to different environments by parameterized, however those jobs in the workflow were not the ones that were renamed.

Any ideas what may be going on here?

#2

The job renaming is part of how the new parameterization works – when you use a job multiple times in a single workflow or parameterize the job we process your config to create fully deterministic “renderings” of your dynamic job invocation as static jobs. The renumbering is to prevent name collisions in the underlying machinery that executes your workflows. However, the system is designed to honor all branch filters, so if that’s not happening it might be a bug. If you’re game to share your config here or send to use privately we’d like to take a look (or send us a URL to one of your builds, and we can pull the config from that).

#3

Also worth noting is that you can pass a name to give each job invocation a deterministic, unambiguous name in the final config.

#4

That makes sense! I’ll try explicitly specifying the name then.

The strange thing here is that we are not using the jobs in question multiple times, it’s another job in the workflow that is reused. So I would expect that these jobs which are only used once maintain their names.

#5

A few weeks ago, I tried specifying an explicit name and the behavior persisted.

However, I just rebased that branch to update it, making no changes to the config, and on the new re-build the naming issue was fixed! And the correct behavior persisted even when I removed the explicit name specifications.

So I guess there was a fix in the CircleCI infrastructure? Anyhow, thanks for the pointers!

#6

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.