Once you tell tinderbox to build a list of ports it happily goes off and does it's work. But how do you know what it is doing? Well let's nosey around and see what we can find. Let's open a terminal and tell it to compile devel/p5-Log-Dispatch and see what happens.
Well that doesn't tell me much of anything. In fact during the wait between line 26 and 27 it gives no clue as to what it is doing. It turns out if you look inside the right build dir you will get some more info. With BUILDNAME=9.0-amd64-clang
That lock file tells tinderbox that this build is busy working. In case of severe breakage you will need to delete this to get started again. The duds file contains a list of ports that it won't be compiling (back to that in a sec). The Makefile has a list of dependancies for the port that is being compiled and the make.0 (and make.1 if it is there) is a log file giving a general overview of what is happening, you will see the environment settings and the current port being made (at least the distname of the source package which often matches the portname). tail -f make.0 will let you watch as things progress. make.0 logs stage0 progress while make.1 logs stage1.
If wou want to see more detail then you will find the working system installed inside /usr/local/tinderbox/$BUILDNAME Of most interest will be the tmp dir where you will find pieces of log files that will be joined into the final log that you can access later. Each step of the build is in a separate piece so you get one for extract, one for patch, one for configure...
Now why would tinderbox list ports in the duds file and how do you build a port that gets listed there? Well the duds file contains ports that are marked BROKEN or IGNORE. For the reason and a way to find a solution you probably need to look inside the Makefile for that port (within the ports tree). There are several reasons for a port to be marked as broken, sometimes it is broken for a specific ARCH, sometimes it is because it is incompatible with another installed port or that two options are incompatible with each other. This would be more likely if you are configuring options for your ports rather than just the defaults. A port may also be marked as ignore if an option is turned on but the supporting port is not installed. While normally that is handled by the ports dependencies I have found at least one port that breaks with that inside tinderbox. It appears that the Makefile is parsed before the dependencies are in place. Also if you set options and create a dependancy loop the make.0 in the builds dir will quickly grow to several gigabytes in size. Killing the make process will then start stage 1 repeating the same thing. The quick growing log size is the only way I found to spot this - well you probably notice the constant disk access slowing things down if you are using the machine at the time. If you use zfs setting a quota on the filesystem for tinderbox can be very helpful.
Inside /usr/local/tinderbox/logs/$BUILDNAME you will find log files of every build that has finished. If there was any errors you will also get a link inside /usr/local/tinderbox/errors/$BUILDNAME
find /usr/local/tinderbox/errors -name "*.log" will list all error logs.
With the default config of tinderbox the webui is turned on. If you turned it off because you don't want apache installed then choose one of the smaller web servers as the webui is helpful. The webui is accessed from http://localhost/tb - if setup on your current machine. If you setup and use tinderd then you can also get access to that through the webui. That includes adding ports to the queue.
The homepage gives a nice table listing each build name with a range of counts for number of ports, failed ports etc and a link to the packages directory. If your building to create your own packages site then you can use this link. While most descriptions for the counts are pretty obvious, unknown status is a count of ports you have added to the datastore but there is no data available for it - the data is only added to the database after the first compile runs. The remake count is how many ports are currently queued to be compiled. Using the example above - when starting to compile devel/p5-Log-Dispatch there is a total of 25 dependancies that need to be installed for that port. When you start the compile on a clean build remake will start at 25 and count down as each dependant port is completed. Ports that need to be updated will also be included in this number. While remake is only a displayed number, the others are links to a list of details.
Most of the other pages are lists that vary only in the search criteria and are pretty straight forward. The latest builds page is good to keep open while building - while a port is compiling it will refresh every minute so you can watch the progress - more helpful when you have a lot of dependancies. A green filled box for reason is no errors, red means failed build and orange means a dependancy failed. The link to show the log file with markup is also helpful - it is pretty good at locating errors in the log files and gives you a list of links at the top to each error line as well as highlighting them in red.