MadCap Software Forums

Hi all,

I was wondering if anyone know how the queue is ordered when you use a batch target?

I have recently updated my batch target to have 6 targets build at once, rather than the 2 I had before. However, I need one of the targets to build last, as it has a post-build event that takes the output from all the other targets and zips it up.

Unfortunately, that is the target that builds first. It wasn't a problem before, because it ran at the same time as the other one, but always finished after because it had more topics. Now that I have 6 targets, they get queued, and only 2 get built at once (I also can't find the location to change number of concurrent builds. Flare 2017 doesn't seem to have the File>Options menu as listed in the help...)

I thought that the order was alphabetically, so I decided to rename the build to "z-portal-target", which should in theory put it after "portal-target-2-7" for example. No such luck, it still was the first one to be built!

I have tried to be smart, and put a post-build event on another one of my targets, so that it can be built after that has finished. I used the following
It does work (kind of), but it doesn't queue it in the build window, it just does the build behind the scenes. And I get an odd error message saying that the Build fails, but after the post-Build event command has been done. Either way, it's not working enough, so I don't know if that code would publish the target or not.
My issue is that because it does it behind the scenes, not in the build window, if something goes wrong with that build, I can't tell.

Is there either a way to get the post-build event to start the build and publish within the actual build window, or can I force the batch target to queue items in a certain order?
I would like to avoid having to run my batch target, then run the "portal-target" by itself afterwards. It defeats the point of a batch target!

Any help would be most welcome. I thought it would be a simple job... Which it was, except for ordering!

I was wondering if anyone know how the queue is ordered when you use a batch target?

I suspect it is the order within the file itself (which may not reflect the UI). Try right clicking the batch target | Open With | Internal text editor. Then cut and paste the entire <target ... > tag to the end.

(I also can't find the location to change number of concurrent builds. Flare 2017 doesn't seem to have the File>Options menu as listed in the help...)

After you click File it is the button with the 'cog' icon and Options, right next to "X Exit" to the bottom right. The option you are after is Build | Maximum Concurrent Builds.

My issue is that because it does it behind the scenes, not in the build window, if something goes wrong with that build, I can't tell. ... Is there either a way to get the post-build event to start the build and publish within the actual build window

Your build approach should work in theory (i.e. chain other builds) - but you'd need to be comfortable with the command line. Results are published to the %ERRORLEVEL% global variable, and you can also view the build log separately by accessing it in the target directory.

Thank you GregStenhouse. You've really helped.

I changed the order within the file, and this seems to have worked. Oddly, when I put it right at the end of the file, it put itself back into its old position. I had to put it at the end of the set that were in "Online Output". If I put it after the "PDF" set that exists in my batch target, it reverted to its old location.

I've now also found the "Options" menu. I wasn't looking for a small cog.

As for the command line/post-build event approach, it does work, and although I feel fairly comfortable with the command line, I work as part of a team. Not everyone is so comfortable, and it does become a nuisance having to open the Output folder just to see if it works. Especially when the target I was trying to build has its own post-build event (to zip up all the files I have just built), which is prone to error due to a Gradle bug.

I've got to admit, I'm so glad though that Flare introduced these post-build events. We wouldn't be able to do what we currently do without it. It allows us to zip up all the outputs to produce them as offline HTML5 content. It's great!