Table of Contents
The Build functionality helps you to move your changes to an org directly from the IDE. It's available for the standard project metadata components (exept objects):
- static resources,
If you work with other types of metadata and need to move the changes in them to an org, use the functionality of deploying.
The Welkin Suite offers you multiple ways to execute the build, depending on your purpose, and volume of changes that you want to implement. You can find all the available options for the build in the context menu of a solution / project in the Solution Explorer, and in the
Main Menu ⇒ Build.
- Build Solution — to move all the changes from the entire solution to an org(s),
- Build Selection (the F5 hotkey) — to build changes only from a selected project,
- Build and Run Tests (the Ctrl+F5 hotkey) — to run all the tests right after a build is finished.
In addition, you can access to the build options via the Build toolbar.
Once you start a build process, the Output panel is displayed automatically reflecting all the changes of the build status. You are able to see an icon in the bottom right corner of the IDE window and the build status in the status bar. All the steps of the building process are described below one by one.
Step 1. Detecting changes locally
At the first step, TWS detects all the changes in the files locally. You can revise the complete list of such files that are going to be built in the Pending changes panel. In addition to these files, The Welkin Suite also gathers and sends on Salesforce all the dependent files that may relate to the changes.
If there are no changes, the build won't send any file to the Salesforce org.
Step 2. Detecting changes on Salesforce
At the second stage, The Welkin Suite checks the Salesforce org if files that were changed locally were not changed in the org.
If there are no changes on Salesforce, your files will be sent to the build.
Step 3. Updating local files
If during the build process TWS detects errors, they will be displayed in the Error List Panel and the build status will be Failed.
If no errors are returned, TWS redownloads the built files from SF if the data from their *-meta.xml files were changed.
After all these actions TWS calculates hash for downloaded files and store them in order to check for changes in SF on the next build.
When the build has finished successfully, you will see the following status in the Output Panel.
Cancel the current Build
If for some reason the build is taking too long, or it's stuck, or you've changed your mind and don't want to build the changes, you can cancel it by clicking on the
Cancel option in the Build menu or pressing the Ctrl+Break hotkey.
NB: The cancellation of the build depends on the current step of the process:
1. if the process is going locally (step 1), it will be successfully canceled,
2. if the build has already sent a request to Salesforce and queue that includes the building files, this request can be in queue also, so the cancellation may take some time,
3. if the build is completed on Salesforce, it won't be canceled in TWS.
In this section:
This also may be useful: