sfdx.py/convert_sfdx_source yields incorrect path when name is provided

[atrancandoris]

Describe the bug
sfdx.py/convert_sfdx_source yields the incorrect path when the name argument is provided. The name argument passes the -n <name> flag into sfdx, which places the results of sfdx force:source:convert into a subdirectory of the same name (e.g., output/<name>.

The particular flow I'm having issues with is release_2gp_beta, but even after correcting the path that is yielded from sfdx.py/convert_sfdx_source, am still getting errors. My workaround is to remove the addition of the -n flag from sfdx.py:145 and that results in the flow working just fine.

I am guessing the addition of the subdirectory is a newer sfdx feature, as I do not seem to be getting the same behavior with an older version of sfdx (7.71.0 works).

Reproduction steps
Steps to reproduce the behavior:

1. cci project with project.source_format: sfdx
2. cci flow run release_2gp_beta

2021-08-06 19:44:35: [Error]: Package creation failed with error:
Run this command for more information about debugging errors: cci error --help
2021-08-06 19:44:36: package.xml: No package.xml found
2021-08-06 19:44:36: Exception in task create_package_version

Context

sfdx-cli/7.112.1 darwin-x64 node-v16.1.0
CumulusCI version: 3.41.0 (/usr/local/Cellar/cumulusci/3.41.0/libexec/bin/cci)
Python version: 3.9.6 (/usr/local/opt/[email protected]/bin/python3.9)
Mac OS X 11.5.1

[atrancandoris]

@davidmreed you may be interested in this issue. Thanks!

[davidmreed]

@atrancandoris Can you tell me any more about your use case? It sounds like you're probably using a monorepo containing multiple 2GP project directories; is that accurate?

[atrancandoris]

Just one directory:

From sfdx-project.json:

{
  "packageDirectories": [
    {
      "path": "force-app",
      "default": true
    }
  ],
  "namespace": "***",
  "sfdcLoginUrl": "https://login.salesforce.com",
  "sourceApiVersion": "51.0"
}

From cumulusci.yml:

minimum_cumulusci_version: "3.33.1"
project:
  name: ***
  package:
    name: ***
    namespace: ***
    api_version: "51.0"
  git:
    repo_url: https://github.com/***
  default_branch: main
  source_format: sfdx

[davidmreed]

I am not able to reproduce this issue using CumulusCI 3.41 and SFDX sfdx-cli/7.112.1 darwin-x64 node-v14.17.4. My Node version is different than yours, but I'm unclear on whether that makes a significant difference here. My plugins (sfdx plugins --core) are currently

@oclif/plugin-autocomplete 0.3.0 (core)
@oclif/plugin-commands 1.3.0 (core)
@oclif/plugin-help 3.2.2 (core)
@oclif/plugin-not-found 1.2.4 (core)
@oclif/plugin-plugins 1.10.1 (core)
@oclif/plugin-update 1.4.0-3 (core)
@oclif/plugin-warn-if-update-available 1.7.0 (core)
@oclif/plugin-which 1.0.3 (core)
@salesforce/sfdx-trust 3.6.0 (core)
alias 1.1.10 (core)
auth 1.7.1 (core)
config 1.2.14 (core)
generator 1.1.7 (core)
salesforcedx 52.0.0
├─ data 0.4.11
├─ custom-metadata 1.0.12
├─ apex 0.2.2
├─ schema 1.0.7
├─ limits 1.2.1
├─ templates 51.5.0
├─ @salesforce/sfdx-plugin-lwc-test 0.1.7
├─ org 1.6.6
├─ user 1.3.0
└─ salesforce-alm 52.0.0
sfdx-cli 7.112.1 (core)
source 1.0.6 (core)
telemetry 1.2.3 (core)

Would you be able to construct a minimal example repo that can cause this issue to share?

[davidmreed]

Withdrawing the preceding; I'm able to reproduce with a clean install of SFDX.

[davidmreed]

@atrancandoris This change was introduced by SFDX after version 7.110. If you roll back to that version, it'll be fixed. We're discussing solutions on the current version.

[atrancandoris]

Thanks for investigating! I will stick to that version for now as a workaround.

[georgeslater]

Before downgrading to sfdx-cli 7.110 as a workaround, be aware that it can stop working: see forcedotcom/cli#1104. I have downgraded to 7.109 as a result.

[davisagli]

I believe this was fixed in sfdx 7.114.0