Getting "-number" suffix appended to job names when converting to 2.1 config

Feedback & Bug Reports
,
1

I’m trying to convert an existing 2.0 config to 2.1, taking advantage of the commands feature. When doing this, jobs that I use in multiple workflows end up being renamed and duplicated. As an example, my test step is duplicated and shows up as test-1, test-2, and test-3.

CircleCI then reports job status of test-1 to GitHub, which breaks our existing branch protection check, ensuring that the test job is successful before allowing merge.

How can I get CircleCI to continue to report test in the dashboard and to GitHub?

2

EDIT: PLEASE IGNORE. I made this response without fully understanding the details of the original post. I apologize!

This isn’t a bug, its a feature. :slight_smile:

If you have the same job being duplicated multiple times its going to append a random number to the end unless you explicitly override the name as documented here: https://circleci.com/docs/2.0/configuration-reference/#job_name-1

3

I don’t see how this could be considered a feature. The name mangling is worse than useless.

I tried using the name feature you point out, but it doesn’t seem to have any effect. Is there an example that shows a config that works around this?

4

EDIT: PLEASE IGNORE. I made this response without fully understanding the details of the original post. I apologize!

If you are calling a job named test three times, and 2/3 of them fail how else would you know which test is the problem?

In addition, if you’re overriding the GitHub check for the same tests then it provides you with little value because if test-1 passes then test passes, if test-2 fails then test fails, if test-3 passes then test passes. This would lead you to think that it’s safe to merge when in fact you have a failure.

I would circle back and recheck your assumptions on how you want to protect this branch if you’re going to be calling the same job more than once.

Lastly, I don’t have an example config, but the name key should go in the workflow itself. Could you share a snippet of your workflows config?

5

Also seeing this; our configuration has not changed today, but these numbers are being append as of this afternoon. My guess is this is a regression from today.

Given:

version: 2.1
workflows:
  version: 2

  test:
    jobs:
      - job-a
      - other-job

  other-test:
    jobs:
      - job-b
      - other-job

  cron-test:
    triggers:
      - schedule:
          cron: "0 * * * *"
    jobs:
      - job-c
      - other-job

It is adding the numeric suffix to “other-job”. I believe this is not intended, since “other-job” is NOT used multiple times within the same workflow.

1 Like
6

Thanks for the additional report here. This may be a regression for sure.

1 Like
8

@scott113341 just to be clear I wasn’t just saying “thanks!”, Im checking with some folks to see what the issue might be :slight_smile:

Also, this is related but not the same problem as @chrisleck, forgive me if I am misreading things here.

9

Oh darn, sorry I think this actually is a bug. :frowning:

Sorry I misread the original post, the issue that I thought you were having is quite similar to a common issue that folks have due to a misunderstanding with how multiple jobs in the same workflow works.

However since are using the same job in different workflows, then this should not be happening.

Thanks for reporting this @chrisleck and I apologize for jumping to conclusions.

10

@scott113341 @chrisleck could you try this now without any changes and let me know if you’re still seeing this behavior?

Please make sure its a new commit and not a “rebuild”.

12

Fixed! Confirmed that integer suffix is no longer included if the same job is included in different workflows. Thanks for the quick resolution!

1 Like
13

I’m just the messenger, it looks like a bug was shipped and reverted now :slight_smile:

thank you again to @chrisleck for raising the issue.

14

Yep, the issue does appear fixed now. Thanks for the quick turnaround!

1 Like
15

Following up here – this was not a “bug” in that it behaved the way we intended. However, based on this feedback we’re going to change the behavior to only rename jobs if they are invoked multiple times in the same workflow (rather than invoked multiple times within the same config but across different workflows).

1 Like
16

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

17

Hi All,

I wanted to clarify when invoking the same job multiple times with parameters across any number of workflows, the build name will be changed (i.e. sayhello-1 , sayhello-2 , etc.). To ensure build numbers are not appended, utilize the name key. The name you assign needs to be unique, otherwise the numbers will still be appended to the job name. More info in our docs here