Target org specific .forceignore files #2257
Replies: 4 comments
-
I would really appreciate this feature. I have a more coarse-grained version of this. A version of .forceignore for scratch orgs and another for store-bought orgs. Various reasons for the differences. I would be interested in a more compose-able solution. These parts of the .forceignore file are applicable to all deployments but use these other parts based on org type or username/alias. I realize this could get to a very complicated place but it would reduce user errors we've seen as recently as last week. |
Beta Was this translation helpful? Give feedback.
-
Some of the problem here is that DX uses a NodeJS library to parse a .gitignore file and apply it so without larger changes they would be limited to the functionality of .gitignore. |
Beta Was this translation helpful? Give feedback.
-
@keirbowden Thank you for the feedback. I will add a story to our backlog and we will talk internally about how to build this. It might take us a bit but will definitely investigate a solution. d |
Beta Was this translation helpful? Give feedback.
-
Marking as wontfix. For a "consistent deployment" I'd recommend using |
Beta Was this translation helpful? Give feedback.
-
Is your feature request related to a problem? Please describe.
No. This is more around the deployment requirements that I have for my project. This is an accelerator, so the same codebase is deployed to multiple Salesforce customer instances, as well as a bunch of internal orgs.
What are you trying to do
I deploy my single codebase to multiple target orgs - scratch orgs, developer editions for demo purposes, sandboxes and production. Often there are features enabled in one org that are not present in another (Pardot in a demo org, for example). Some components will only be required when a feature is enabled, so are effectively org specific.
Describe the solution you'd like
I'd like to be able to have some way to specify a set of .forceignore rules that apply to an org without having to maintain multiple copies and swap them in and out depending on the target. Either a flag to override the default .forceignore, or a .forceignore file that contained a stanza/object per target org.
Describe alternatives you've considered
At the moment I handle this by having a configuration file that identifies files to be included/excluded on a per-org basis and create a copy of the package directory that only contains those files. The alternative I'm looking at is maintaining multiple versions of .forceignore files and copying the appropriate version in prior to the deployment/push. All of these require a non-standard Salesforce CLI command to be run before the deployment/push, which introduces the chance of user error.
Additional context
Beta Was this translation helpful? Give feedback.
All reactions