sfdx v7.156.0 broke support for multiple .forceignore

[msimonis]

Summary

Prior to version 7.156.0 (7.155.1, for example) REST deploy was working as expected, as well as .forceignore files in subdirectories not being respected. Using 7.156.0 or later causes the following breaking changes:

• REST deploy does not work
• .forceignore files in subdirectories (not the root where the command was run) are used

Steps To Reproduce:

Repository to reproduce: sfdx-cli-bug

This example project shows the main issue with .forceignore files. The README in the repository has details for reproducing.

Expected result

.forceignore files in subdirectories are not respected - only the root one is.

Actual result

.forceignore files in subdirectories are being used, and the root one is not.

System Information

• Which shell/terminal are you using? zsh

This issue is reproducible on sfdx-cli 7.156.0 and it is working as expected on 7.155.1.

[github-actions]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[mshanemc]

this will fix the restDeploy issue: salesforcecli/plugin-source#535 (someone reported that outside of github so we it'll be in tomorrow's RC)

as to .forceignore...that's supposed to go at the project root. See the docs: https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_exclude_source.htm

Add the .forceignore file to the root of your project for the force:source:* tracking commands.

Are you saying that you've long had multiple forceignore and they used to work correctly? We've never intentionally supported that or intended it to work. Maybe you just got lucky? 🤪

Is there a reason you need to have several, separate .forceignore files

[msimonis]

@mshanemc I do not want several .forceignore files to be supported. The issue is that the one at the root is not being respected or used when there is another in a subdirectory, parent to the path mapped in the sfdx-project.json file.

The reason we have multiple .forceignore files in a single project is that we are developing using 2GP, and have separate repositories for each 2GP package (we tried mono-repo and decided against it).

To make working on multiple packages at the same time easier, we created a workflow where you start with a "workspace" project (as we call it) and run a command to clone the packages you want to work on (it handles the dependencies). This will clone each repository into an sfdx-source directory, which is then mapped to the sfdx-project.json file for deployment.

So the .forceignore is at the workspace root for that project, and should be used. But only after 7.156.0 it started using the .forceignore files in the subdirectories that are tied to the other repositories / packages.

We are already implementing workarounds because we can't wait for a fix, but it was a breaking change to how the cli was working previously. You can easily see the difference in functionality by using the sample project linked to in the original issue. If you are on 7.155.1, the permission set does not get deployed. 7.156.0 and later it is deployed.

[maggiben]

Hello, this issue has been fixed in the latesr-rc, you can instal the new rc and try again ?

[msimonis]

@maggiben The REST deploy issue does seem to be fixed on latest-rc.

The .forceignore issue is still present.

[RupertBarrow]

Hi @msimonis, as a rule, I always deactivate autoupdate of SFDX CLI and other tooling to make sure that I have a stable, consistent and reliable build environment.

Is there a reason why your tooling is using the latest SFDX CLI version ?

[msimonis]

@RupertBarrow we don't use @latest in any build environments. There was a different issue related to Quick Actions that was fixed in a version of the CLI, so we upgraded to a version with that fix.

It's sometimes hard to find a version with the fixes you need that don't break other functionality.

[RupertBarrow]

Thanks for the info.

…

Le 12 juil. 2022 à 19:28, Matt Simonis ***@***.***> a écrit : @RupertBarrow <https://github.com/RupertBarrow> we don't use @latest in any build environments. There was a different issue related to Quick Actions that was fixed in a version of the CLI, so we upgraded to a version with that fix. It's sometimes hard to find a version with the fixes you need that don't break other functionality. — Reply to this email directly, view it on GitHub <#1606 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALTAP5YELA62X2ONSDTDHLTVTWTLHANCNFSM5222NJ3A>. You are receiving this because you were mentioned.

[mshanemc]

@msimonis here's the forceignore code https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/resolve/forceIgnore.ts#L54

It's doing an upward search and will stop at the first one it finds. (see also https://github.com/forcedotcom/source-deploy-retrieve/blob/3af34cedbccb2725e934eceda82331798030ba82/src/utils/fileSystemHandler.ts#L46)

What would the ideal logic for your scenario?

• avoid using the findAndCreate and instead have consumers of forceignore pass in the top-level project information and require that forceignore live there?
• or have some way (config, env, etc) pass in an explicit forceignore path?

[msimonis]

@mshanemc I'm wondering if it makes sense to keep the context of where the command was run from, and use the forceignore at the root (like the documentation suggests). I think that would make things work like they used to, but also allow for defining the forceignore in subdirectories.

[mshanemc]

Can you explain your thinking in more detail, maybe with some examples, @msimonis

[github-actions]

This issue has not received a response in 60 days. It will auto-close in 7 days unless a response is posted.