You should use IDE for running builds only for development. IDE uses a limited pool of resources reserved for tests development only. For day to day build runs, use Builds section in console as it guarantees your builds run in new exclusive VMs that die once builds complete. Builds from console are unattended and don't start live preview, live output by default which otherwise happen in IDE.
Make sure you've gone through Introduction before going ahead.
There are several ways to productively run builds in IDE. IDE takes less than 10 seconds to connect to a running VM and start a build.
We understand that while debugging, builds have to be started quickly and without interruption. To facilitate this, there are some options in build config that we will discuss shortly. To begin with, look at following important notes about builds in IDE:
- Only tests that are loaded in explorer can be included in a build.
- Your build minutes quota is not used for VM boot time even if a new VM has to be booted (sometimes when there are no running VMs available). That allows you to run many builds in fewer build minutes. For instance, if you run 20 builds while debugging some tests, each taking 30 seconds to run tests, the total minutes spent would be around 12 with 2 additional minutes for asset processing and uploading. We've tried to make it easiest and cost effective for you to develop tests using live VMs.
- You can't name a build. Builds are identified only using a unique id. This is by design so that you can skip opening of build configuration every time a new build runs (discussed later in this chapter). IDE builds are primarily for development thus shouldn't require specific names.
When a new build request is initiated through any means such as using Run Build icon from top of the IDE, build config opens up requiring details to create and run build. Once configuration is complete and 'Run Build' button is hit, a VM is searched that would run the build.
Build starts as the VM is found and connected. Live preview and Build output console open up automatically delivering real time updates.
When the build finishes, it's detail would be available in 'Completed Builds' that's embedded into IDE.
IDE keep the values provided to build config in state and shows the last updated values each time it is opened. Normally build config is opened on each new build request to let you change config details if needed.
While developing, developers use same configuration options for a series of builds and don't want config to open every time to minimize interruptions. To do so following conditions must be fulfilled:
- You must enable Open Build Config Less Often in build config.
- Build capability and 'tests to run' must be available with build config.
When you do this, build config doesn't open anymore and same build capability and tests are reused every time a new build is triggered.
If at any point in time you feel like changing any of the value in config including tests and build capability, open Build Config from edit menu, make changes and close it. IDE always use your last update to config in all future builds. Now when you trigger new builds, new config changes are used.
Is there a way to change 'tests to run' without opening build config?
Doing any of the following will start a build for the specified test(s) only, ignoring tests that are selected in the config.
- Run build for a particular test from Editor Embedded Output Console. Build will be run only for the currently visible test in editor.
- From explorer, right click on either a file, test or a version and select option to run a build.
- Use Run Build icon from top of the IDE. This opens build config (unless skipped and required fields available) from where you can assign required tests to run.
- Use 'Run Build' from Editor Embedded Output Console. It will run build for current test only. Build config ignores the tests assigned to it and runs only currently shown test in editor.
- From explorer, right click on either a file, test or a version and select option to run a build. Build config ignores the tests assigned to it and runs only the selected test(s).
- Re run a build from Build output console.
- Re run only failed tests in a build from Build output console. Option to re run failed test appears only when last build has failed test(s).