Closed atrancandoris closed 2 years ago
@davidmreed you may be interested in this issue. Thanks!
@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?
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
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?
Withdrawing the preceding; I'm able to reproduce with a clean install of SFDX.
@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.
Thanks for investigating! I will stick to that version for now as a workaround.
Before downgrading to sfdx-cli 7.110 as a workaround, be aware that it can stop working: see https://github.com/forcedotcom/cli/issues/1104. I have downgraded to 7.109 as a result.
I believe this was fixed in sfdx 7.114.0
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 intosfdx
, which places the results ofsfdx 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 fromsfdx.py/convert_sfdx_source
, am still getting errors. My workaround is to remove the addition of the-n
flag fromsfdx.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 ofsfdx
(7.71.0 works).Reproduction steps Steps to reproduce the behavior:
project.source_format: sfdx
cci flow run release_2gp_beta
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/python@3.9/bin/python3.9) Mac OS X 11.5.1