https://netsuiteprofessionals.com logo
Join Slack
Powered by
What problem exactly is the --dryrun command suppo...
# sdf
w
What problem exactly is the --dryrun command suppose to solve? It doesn't give you the errors that will occur when you actually deploy. It seems to only give you a log of the order it will try to deploy it in.
s
aye, I that particular command is a bit misnamed
although, if it shows exactly what it's about to do then that'd be good
I don't think I could expect it to know about errors it may hit with runtime deploy
being a dry run and all
w
I was hoping it would kind of perform a deployment but without storing all the objects. And give me the errors. Like I tried to deploy a project with a custom record and a workflow that had some setmandatory-actions on the custom record. The workflow couldn't be deployed together with the custom record. I had to deploy the workflow separately. That is an error that it could give me. Or that custcentercategory can't have links to customlists.
s
does it show you exactly what is being uploaded in detail? If so I'll have to upgrade to the latest
IIRC, dry-run didn't even give you the details of what it was about to attempt to do, let alone errors that might occur
a
@stalbert have you try running dryrun? It should show you the preview of deployment What will be created, deleted, uploaded
For errors, there is a dedicated validate command
w
Yeah but the validation does not catch the errors I described.
a
@Watz did you run validate against account?
Or local validate?
w
--server
a
Well that might be the issue with validate command. Answering your original question --dryrun is supposed to show the changes that will occur in your account on deployment. To analyze your use case for validation, you need to open a case with NS support so the concerned team can check why validae --server is not catching errors.
Ideally validate --server should show you the same output as when you deploy.
w
Ok, will do that then.
a
For me 
--dryrun
also gives validations. I don't know what you are expecting. If you can share some screenshots, and your expectations from --dryrun, just so I can understand better. cc @stalbert @Watz
w
Will try to gather some of the logs tomorrow. I hope they're still in the terminal.
👍 1
a
So if i resolve the errors shared in previous screenshot, and I run --dryrun again. This is what it shows me that will happen in the account without actually doing it.
👍 1
s
Is this 'dry-run' option only available in cli?
a
Its available in latest suitecloud cli for nodejs
in SDFCLI its 
preview
command
We don't have it in IDE's It was most voted feature on github, it was requested for SuiteCloud CLI for NodeJS
s
yes, I'm sure I probably voted for that - thanks for getting it in there. I've been lazily using webstorm lately but need to go back to the CLI just for this feature.
IMHO it's critically useful to know what you're about to do to the target account before you do it.
a
I will convey this to the team, so probably we can add this as nice to have for WebStorm
Thanks for the suggestion.
Have you checked the new run/debug configs in WebStorm? its one of the nicest features we have added in WS recently.
Would love to get your feedback on that.
You will have 
preview
here in 
Action
so it will partially resolve your request.
s
interesting use of 'run/debug config'
I didn't know that was there.
a
It was added in the latest 
2021.1
version
s
right off the bat I can give some feedback- would be nice if the project and authid were defaulted to the current project
(provided the current project has a default authid assigned)
assuming they are required fields?
a
Well they are supposed to be global, and if i am not wrong you can even select projects which are not open in WS. We have more enhancements planned for it, we can definitely look into it.
s
the template is global - but any concrete run config will be tied to a specific project/authid according to the fields in that dialog box.
for those of us that work with many NS accounts across many customers anything I do to prevent myself from making mistakes by crossing between accounts would be helpful.
i.e. if I open an account customization project, I'd love to be unable to accidentally deploy it elsewhere.
I already have to be careful because all the NS credentials are in one big list - it would be very easy to accidentally choose 'deploy to Account' and select the wrong one via human error.
(referring to the WS plugin in all the above comments)
my semi-solution is to set a default account, and since that's saved locally it's safer.
a
Yes, and that's why you can save the template once and use it. It will be a one time process to save a project and the authid and name it accordingly. IMO, saving the config onetime carefully with the project and related authid, will have less risk as compared to selecting an authid every single time.
s
agreed on that second point.
though the same effect is had by setting a 'default' authid for the project in the NS settings.
right?
a
Yes. But with this config, you can have multiple parallel deploys (running in background). You can be very creative with this by creating a chain of configs.
It totally depends on the needs of the users.
And its still the first version, and we want to improve it. So your suggestions are more than welcome.
s
good stuff
w
@Ali Syed (NS DevTools QA) Here is the –dryrun in green and then the start of the deploy. The initial validation only gives me a couple warnings for custom role-fields that are not supported yet.
Here is the end of the validation and beginning of deploy
Here is the first error that stopped the deployment half-way through (another issue is that in a failed deployment, the deployed objects are now in the environment). The issue was that a field in a record had filtering that referenced another field in the same record. The other field however was being deployed after the first field. I had to change the order of the fields within the .xml to get passed this
Second error. The issue here was that a field in the child record, vtal, was referencing a field in the parent record, vtar, and that field was getting deployed after the child records field. I solved this by putting the parent record, and it’s dependencies in a separate folder and putting that folder first in deploy.xml
Third error. Apparently you can have links in custcentercategory to custom records, workflows etc. But not to custom lists in SDF. I had to remove the links to custom lists from the xml and add them manually once deployed.
Fourth & fifth error. The issues with these workflow actions are not clear to me at all. The fields that the workflows were referencing had been created earlier in the same deployment. I tried redeploying just because I thought that since the fields now exists in the account it should be deployable. But I got the same error. In this case it worked when I deployed the workflow completely separately with adding dependencies to the manifest.
None of these were caught in the validation. And I think that some of them should be resolved within the deploy. The fields that had dependencies on other fields. The deploy mechanism should be able to figure out what should be deployed in what order... ooor deploy everything and check for unresolved references afterwards.
s
I definitely also experience deploy issues not picked up by server validation and also thought the dry run was specifically for this 😞
a
If your deploy xml has <objects> tag like this
Copy code
<objects>
        <path>~/Objects/*</path>
 </objects>
It should auto resolve dependencies. But if its not working I would recommend to open a case with NS Support. Secondly if 
validation --server
is not catching errors but deploy does, this is a separate issue and also should be filed with NS support. Actually 
--dryrun
is also validating server side + showing changes going to happen in account. So the problem should be fixed from serverside validation. Please open the 2 cases with NS support ASAP.
w
Thanks for looking at this. Will do, but I'm afraid I'm gonna get stuck in NS support because I cannot reproduce this with the same setup.
Case #*4157356*
3 Views
Open in Slack
PreviousNext
Powered by