Allow setting Validation & Deployment behavior at the module/org level
Issue #380
resolved
It would be helpful to be able to specify the validation & deployment behavior at the module or org level rather than for all of IlluminatedCloud. I want to auto deploy to my dev environment, but never to production. Right now, I manually change those settings as I go between the 2 projects. Maybe there's a better way to do that than I realize?
Comments (7)
-
repo owner
-
reporter
It's quite possible that I am running into this because I'm still such a salesforce newbie. I have a Prod project that I use simply to pull down all the metadata from production. I also have a Sandbox org that I am doing my work in. I want to completely disable saving to prod, but I want to deploy on save for everything in my sandbox, so the issue is less about which api to use, and whether or not to save/deploy at all. I'm just editing the defaults as I bounce back and forth between the projects now, but I am paranoid that I won't remember to sometime and end up deploying something to prod inadvertently. Is this just impossible and I am worried about nothing?
-
repo owner
Whichever connection is configured with the module is the one that will be used for deployment (including on-save deployment) unless you explicitly choose a different configured connection in the deployment dialog. You don't need to worry about accidentally saving to your production org as long as the connection to that org isn't associated with a module. Let me know if you're not sure how to verify the module<=>connection associations.
-
reporter
Sounds like I don't! I assumed because I was using the Prod connection to pull the code down for that module that it was the associated org. Can I have a module with a retrieval but not an associated deployment org?
-
repo owner
No, unfortunately you can't make a module/connection read-only right now. I'm not sure if this will work for you, but what I would do is create a project/module against the sandbox connection, then add a connection for the production connection. When you do any explicit deployment or retrieval operation that results in the deployment/retrieval dialog box, you'd need to change the connection for it to operate against the production org. That way you can retrieve from the production org when you need by starting a retrieval and changing the connection (which doesn't stick across invocations to avoid "oops"-ing!) and work against the sandbox org, then finally deploy to the sandbox org by starting a deployment and changing the connection. If that won't match your workflow, let me know and we can discuss other options.
-
repo owner
FYI, what I've decided to do for the original issue is to route all deployment paths to use the metadata API when the organization type for the connection is Production. Right now I'm looking at the user-configured organization type, but I'm also looking to see whether that's something I can discern authoritatively through the API.
UPDATE: Looks like I can query the
OrganizationSObject to get this info. I'll make this more authoritative. -
repo owner
- changed status to resolved
This was delivered in 1.7.3.6. Only orgs reported as Sandbox or Developer Edition can use the Tooling API. Other org types always use the Metadata API.
- Log in to comment
Hi, Margaret! So interestingly someone else brought this exact point up earlier. That user was asking for me to default to the tooling API for prod orgs even when the metadata API is selected. I think what I may do is just update the "prefer" logic to only allow that deployment path against orgs that support it. That way it'll stay a project-agnostic setting, but it'll be tied to the capabilities of the target org associated with the connection. Definitely something to address, though...