Why not respecting `working_directory` configuration since v2.7.0?

[r-plus]

If working_directory parameter is configured in CircleCI config.yml

executors:
  node:
    docker:
      - image: cimg/node:18.17.1
    working_directory: ~/my-original-working-directory

and use of git-shallow-clone checkout without path parameter.

  frontend_test:
    executor:
      name: node
    steps:
      - git-shallow-clone/checkout
      ...

thus, git-shallow-clone/checkout will checkout source codes to ~/project but our steps will do something in ~/my-original-working-directory that is empty directory.

circleci@965ef695fc70:~$ ls
bin  my-original-working-directory  project
circleci@965ef695fc70:~$ ls my-original-working-directory
circleci@965ef695fc70:~$ ls project/
<our_source_code_files...>

Why are you using hard coded path of ~/project since v2.7.0?

I'm thinking support of both respecting working_directory configuration and SourceCaching is possible by using $CIRCLE_WORKING_DIRECTORY environment variable instead of hard-coded ${HOME}/project.

https://circleci.com/docs/configuration-reference/#job-name:~:text=Processes%20run%20during%20the%20job%20can%20use%20the%20%24CIRCLE_WORKING_DIRECTORY%20environment%20variable%20to%20refer%20to%20this%20directory.

What do you think?

[guitarrapc]

Ah, thank you. I forgot about working-directory. You are right, it should use CIRCLE_WORKING_DIRECTORY.

[guitarrapc]

issue should be fixed with #59. Close issue when I add test for working_directory and pass it.

[guitarrapc]

@r-plus I've released v2.8.0. Could you try this version?

[r-plus]

@guitarrapc thanks! I just tried v2.8.0, it is perfect expected behavior with working_directory configuration. (I'm not using SourceCache)

Thank you again for your blazing fast response :)