And this is what less than first class support looks like:
The thing to realize is that first class support really isn’t all that it is made out to be. Go necessarily execs all tasks, first class or not. If the exec returns an exit code of zero, the task is considered successful, else the task (and job) are failed. The task specific GUI is merely a scaffold. At the time of job execution, it makes no difference whether you defined an Ant task via the GUI or via a custom command. In fact, it is not possible to make this out from the execution log for the task. The Go config xml will differ slightly based on whether you used the task specific GUI or custom command but it really doesn’t matter.
However, it may take a bit of effort to get the arguments in the custom command exactly right. Would it help if we hosted a task repository for this purpose? Something like this? Note that this is currently totally experimental, unsupported and may disappear any time. But we’d like your feedback on this (via comments to this post please). I think this has potential for community participation and may evolve into a useful repo of reusable tasks that serve as a useful starting point for your own tasks.
On the other hand, it is good practice to keep the definition of a Go job very light. Instead of defining ten different tasks under one job, just write a script (or a build target) for the ten tasks and hook it into Go with a bare bones custom command that calls the script/target.
This lets you keep the script/build file under version control and change what a Go task does without touching the pipeline config. In fact, there are some advanced folks out there who use Puppet to push config changes to the Go Server and keep the entire config.xml under version control.