Job-number naming is breaking github status checks

Bottom line:

I’m having an issue referenced in the two bug reports linked below but the solution does not seem to solve the underlying problem.

More Details:

I have a build job that (due to differences in our dev/prod/release environments) changes the parameters i pass into our build script slightly from one branch to another. I solve this problem by filtering the appropriate workflow jobs and passing in the parameters appropriate to each filter.

The problem, though, is that now my build jobs are being reported to github as build-number instead of just build

To be clear, I am not using the same job multiple times in one workflow but one time in each workflow.

In Github our branch protection requires that PR’s pass the circleci build job

the renaming option doesnt really work because if we rename each version of the build job, when we add branch protection to, for example, master… we say that the circleci master-build job must pass… thats fine! but then in circleci the build job for release branch (and thus, PR’s into master) and the build job for hotfix (another way to PR into master) need different build parameters because they have different testing environments and variables etc. So, we must have 2 separate workflows for this case as far as i know but github’s check expects them both to be named the same when its following the branch protection rules.

i am not sure im explaining it well but essentially, in github the branch protection is set based on the TARGET of a PR but in CircleCI the filtering is based on the SOURCE of the PR. which is fine for most cases except those where there are two separate valid sources of pr’s for one target branch.

as far as i know there is no way to have the branch protection in github be an “or” operation.

is there any way to get all the build jobs to show in github as build since each workflow only has one build job?

id be happy to learn that there is some other way to go about configuring this but i cant imagine what it is at this point.

here is a snippet with the configuration im referring to:

workflows:
  version: 2

  prototype-branch-workflow:
    jobs:
      - build:
          <<: *prototype_branch
          <<: *common_post_steps
      - deploy:
          <<: *require_build_success
          <<: *prototype_branch
          <<: *common_post_steps

  feature-demo-branch-workflow:
    jobs:
      - build:
          <<: *feature_demo_branch
          <<: *common_post_steps
      - deploy:
          <<: *require_build_success
          <<: *feature_demo_branch
          <<: *common_post_steps

  feature-branch-change-workflow:
    jobs:
      - build:
          <<: *feature_branch_change
          <<: *common_post_steps