Job naming consistency, Conditional workflow or jobs

Star · May 10, 2022, 8:18am

0

I’m trying to achieve 2 things:

I’d like to have a consistent naming convention for jobs in circle ci to enforce github rules before merging to release or production branches.
Im trying to have it all in 1 workflow, to avoid code repitition.

Ive made a file that looks something like:

version: 2.1

orbs:
  node: circleci/node@5.0.1

parameters:
  backend-service-job:
    type: boolean
    default: false
  frontend-service-job:
    type: boolean
    default: false

commands:

  run-install:
    parameters: 
      service_name:
        type: string
        default: admin
    steps:
      - checkout
      - run:
          name: Installing dependencies
          command: |
            cd << parameters.service_name >>
            npm install
  
  run-install-tests:
    parameters:
      service_name:
        type: string
        default: admin
    steps:
      - checkout
      - run:
          name: "Installing dependencies"
          command: |
            cd << parameters.service_name >>
            npm install
      - run:
          name: Running Tests
          command: |
            cd << parameters.service_name >>
            npm run test

  build-frontend-push-docker:
    parameters:
      service_name:
        type: string
        default: admin
      web_url:
        type: string
        default: admin
      sourcemap:
        type: boolean
        default: false  
    steps:
      - checkout
      - setup_remote_docker:
          version: 19.03.13
      - run:
          name: "Setup Cloud SDK"
          command: |
            gcloud setup ...
      - run:
          name: Docker build << parameters.service_name >>
          command: |
            cd << parameters.service_name >>
            docker build -t ....
      - run: 
          name: Push << parameters.service_name >> image to gcr
          command: |
            docker push ...

  build-backend-push-docker:
    parameters:
      service_name:
        type: string
        default: admin
    steps:
      - checkout
      - setup_remote_docker:
          version: 19.03.13
      - run:
          name: "Setup Cloud SDK"
          command: |
            gcloud setup....
      - run:
          name: Docker build << parameters.service_name >>
          command: |
            docker build -t ....
      - run: 
          name: Push << parameters.service_name >> image to gcr
          command: docker push ...

jobs:
  run-install-tests:
    docker:
      - image: circleci/node:14.4
    parameters: 
      service_name:
        type: string
        default: admin
    steps:
      - run-install-tests:
          service_name: << parameters.service_name >>

  install:
    docker:
      - image: circleci/node:14.4
    parameters: 
      service_name:
        type: string
        default: admin
    steps:
      - run-install:
          service_name: << parameters.service_name >>

  build-frontend-push-docker:
    docker:
      - image: google/cloud-sdk
    parameters: # parameters are at the job level
      service_name:
        type: string
        default: admin
      web_url:
        type: string
        default: admin
      sourcemap:
        type: boolean
        default: false
    steps:
      - build-frontend-push-docker:
          service_name: << parameters.service_name >>
          web_url: << parameters.web_url >>
          sourcemap: << parameters.sourcemap >>

  build-backend-push-docker:
    docker:
      - image: google/cloud-sdk
    parameters: # parameters are at the job level
      service_name:
        type: string
        default: admin
    steps:
      - build-backend-push-docker:
          service_name: << parameters.service_name >>
workflows:
  version: 2
  backend:
    when: << pipeline.parameters.backend-service-job >>
    jobs:
      - install: 
          service_name: 'backend'
      - build-backend-push-docker: 
          service_name: 'backend'
          requires:
            - install
  go-runner:
    when: << pipeline.parameters.frontend-service-job >>
    jobs:
      - run-install-tests: 
          service_name: 'frontend'
      - build-frontend-push-docker: 
          service_name: 'frontend'
          web_url: "go-runner.com"
          sourcemap: true
          requires:
            - run-install-tests
  go-runner-2:
    when: << pipeline.parameters.frontend-service-job >>
    jobs:
      - run-install-tests: 
          service_name: 'frontend'
      - build-frontend-push-docker: 
          service_name: 'frontend'
          web_url: "go-runner-2.com"
          sourcemap: true
          requires:
            - run-install-tests

In github i can see the persistance for following jobs, for example

run-install-tests
install
build-backend-push-docker

They always stay the same, which is ideal state,

The only thing that keeps changing is the docker-frontend-push-docker-NUMBER

and now we are back to my first 2 quesstions.

How can i make sure that docker-frontend-push-docker name stays consistent and doesnt change?
Is it possible to put all in 1 workflow, rather than go-runner and go-runner-2 and so on?

would appreciate any input

Star · May 10, 2022, 8:23am

Or a better question how could i make

go-runner:
    when: << pipeline.parameters.frontend-service-job >>
    jobs:
      - run-install-tests: 
          service_name: 'frontend'
      - build-frontend-push-docker: 
          service_name: 'frontend'
          web_url: "go-runner.com"
          sourcemap: true
          requires:
            - run-install-tests

How could i make it dynamic and supply web_url depending on what branch it is on? without replicating go-runner like 5 times

Star · May 10, 2022, 8:50am

Im getting slightly closer to a solution,

But it forces me to replicate the “Commands” section a few times, so still hoping someone from this forum could help with clean solution.

rit1010 · May 10, 2022, 5:30pm

Well not cleaner, but there are 2 options

Dynamic Configuration - This is where you generate an additional .yml file at run time and so you can just write the dynamic information into the created script and then call it.

CircleCI Configuration Cookbook - CircleCI
You separate your repo from the main build/test job - so when a change happens in the repo it can pass all the details onto the independent build/test job as parameter values. This is done by using a curl call into the API.

I’m currently using the second option as it means that I am not constantly changing the config.yml file within the main code repos - instead I work on independent repos that just contain the config.yml.

Star · May 10, 2022, 10:28pm

Yep I see,

I agree, they are not ideal solutions.

Would be great it just had normal if else statemets and execute jobs based on those.

Atm I see that you can have a conditional workflow, but conditional workflow executes only 1 job for the conidition.

Was hoping there would be something

workflows:
  jobs:
    run-my-workflow
        IF this and this
            params _1
            run that
       ELSE IF that and that
            params_2
            run that
       ELSE
            params_default
            default job

Such a bummer if its non existent

Topic		Replies	Views
Give orb jobs a name Orbs	3	2406	May 15, 2019
Run jobs based on changes in directory Build Environment circle-yml	3	1785	August 19, 2024
Working with Workflows - What am I missing? Build Environment workflow	4	2216	June 18, 2018
If you expected a workflow to run, check your config contains a top-level key called 'workflows:' Feedback & Bug Reports circle-yml , workflow	20	15911	June 18, 2019
Only the first job runs in a workflow, circleci/2.0 Build Environment golang	3	3469	July 24, 2018

Job naming consistency, Conditional workflow or jobs

Related topics