Skip to main content
edited title
Source Link
Keith C
  • 137.3k
  • 29
  • 218
  • 458

Any way to point to an alternate sfdx-project.json just for the durationdeploy extra components on top of a sfdx force:source:push?

I'm deploying code to multiple orgs in parallel using a separately named project-scratch-def.json for each one. But I've come across a case where I can only deploy some triggers to one of those orgs because the triggers depend on a feature enabled in just one of the project-scratch-def.json files.

Ideally, for that one case, I'd like to be able to point to a separate sfdx-project.json in the sfdx force:source:push command where that file includes a second packageDirectories entry pointing to the triggers. Is that possible?

(An ugly way to achieve this is to use a sfdx force:mdapi:deploy -z zipFile command to layer MDAPI format content on top.)

Or could the triggers and their own sfdx-project.json just be located in separate folder in the project that the automation changes directory into and then does the sfdx force:source:push? Not much luck trying that so far...Or could the triggers and their own sfdx-project.json just be located in separate folder in the project that the automation changes directory into and then does the sfdx force:source:push? Not much luck trying that so far...

Any way to point to an alternate sfdx-project.json just for the duration of a sfdx force:source:push?

I'm deploying code to multiple orgs in parallel using a separately named project-scratch-def.json for each one. But I've come across a case where I can only deploy some triggers to one of those orgs because the triggers depend on a feature enabled in just one of the project-scratch-def.json files.

Ideally, for that one case, I'd like to be able to point to a separate sfdx-project.json in the sfdx force:source:push command where that file includes a second packageDirectories entry pointing to the triggers. Is that possible?

(An ugly way to achieve this is to use a sfdx force:mdapi:deploy -z zipFile command to layer MDAPI format content on top.)

Or could the triggers and their own sfdx-project.json just be located in separate folder in the project that the automation changes directory into and then does the sfdx force:source:push? Not much luck trying that so far...

Any way to deploy extra components on top of a sfdx force:source:push?

I'm deploying code to multiple orgs in parallel using a separately named project-scratch-def.json for each one. But I've come across a case where I can only deploy some triggers to one of those orgs because the triggers depend on a feature enabled in just one of the project-scratch-def.json files.

Ideally, for that one case, I'd like to be able to point to a separate sfdx-project.json in the sfdx force:source:push command where that file includes a second packageDirectories entry pointing to the triggers. Is that possible?

(An ugly way to achieve this is to use a sfdx force:mdapi:deploy -z zipFile command to layer MDAPI format content on top.)

Or could the triggers and their own sfdx-project.json just be located in separate folder in the project that the automation changes directory into and then does the sfdx force:source:push? Not much luck trying that so far...

added 36 characters in body
Source Link
Keith C
  • 137.3k
  • 29
  • 218
  • 458

I'm deploying code to multiple orgs in parallel using a separately named project-scratch-def.json for each one. But I've come across a case where I can only deploy some triggers to one of those orgs because the triggers depend on a feature enabled in just one of the project-scratch-def.json files.

Ideally, for that one case, I'd like to be able to point to a separate sfdx-project.json in the sfdx force:source:push command where that file includes a second packageDirectories entry pointing to the triggers. Is that possible?

(An ugly way to achieve this is to use a sfdx force:mdapi:deploy -z zipFile command to layer MDAPI format content on top.)

Or could the triggers and their own sfdx-project.json just be located in separate folder in the project that the automation changes directory into and then does the sfdx force:source:push? Not much luck trying that so far...

I'm deploying code to multiple orgs in parallel using a separately named project-scratch-def.json for each one. But I've come across a case where I can only deploy some triggers to one of those orgs because the triggers depend on a feature enabled in just one of the project-scratch-def.json files.

Ideally, for that one case, I'd like to be able to point to a separate sfdx-project.json in the sfdx force:source:push command where that file includes a second packageDirectories entry pointing to the triggers. Is that possible?

(An ugly way to achieve this is to use a sfdx force:mdapi:deploy -z zipFile command to layer MDAPI format content on top.)

Or could the triggers and their own sfdx-project.json just be located in separate folder in the project that the automation changes directory into and then does the sfdx force:source:push?

I'm deploying code to multiple orgs in parallel using a separately named project-scratch-def.json for each one. But I've come across a case where I can only deploy some triggers to one of those orgs because the triggers depend on a feature enabled in just one of the project-scratch-def.json files.

Ideally, for that one case, I'd like to be able to point to a separate sfdx-project.json in the sfdx force:source:push command where that file includes a second packageDirectories entry pointing to the triggers. Is that possible?

(An ugly way to achieve this is to use a sfdx force:mdapi:deploy -z zipFile command to layer MDAPI format content on top.)

Or could the triggers and their own sfdx-project.json just be located in separate folder in the project that the automation changes directory into and then does the sfdx force:source:push? Not much luck trying that so far...

Source Link
Keith C
  • 137.3k
  • 29
  • 218
  • 458

Any way to point to an alternate sfdx-project.json just for the duration of a sfdx force:source:push?

I'm deploying code to multiple orgs in parallel using a separately named project-scratch-def.json for each one. But I've come across a case where I can only deploy some triggers to one of those orgs because the triggers depend on a feature enabled in just one of the project-scratch-def.json files.

Ideally, for that one case, I'd like to be able to point to a separate sfdx-project.json in the sfdx force:source:push command where that file includes a second packageDirectories entry pointing to the triggers. Is that possible?

(An ugly way to achieve this is to use a sfdx force:mdapi:deploy -z zipFile command to layer MDAPI format content on top.)

Or could the triggers and their own sfdx-project.json just be located in separate folder in the project that the automation changes directory into and then does the sfdx force:source:push?