milo: Add SwarmBucket templating.

buildbucket/swarmbucket/tasktemplate/template.go

Index: buildbucket/swarmbucket/tasktemplate/template.go
diff --git a/buildbucket/swarmbucket/tasktemplate/template.go b/buildbucket/swarmbucket/tasktemplate/template.go
new file mode 100644
index 0000000000000000000000000000000000000000..bf423e35009e87e0bd79a77d620ab1650afb52ac
--- /dev/null
+++ b/buildbucket/swarmbucket/tasktemplate/template.go
@@ -0,0 +1,43 @@
+// Copyright 2017 The LUCI Authors. All rights reserved.
+// Use of this source code is governed under the Apache License, Version 2.0
+// that can be found in the LICENSE file.
+
+// Package tasktemplate resolves Swarming task templates.

[nodir, 2017/02/18 07:00:54]

a swarming task template is a JSON object that is turned into a swarming task
request. This package does not deal with that. Rather, it deals specifically
with "log_location" swarming tag.

+//
+// Templated strings may be passed to Swarming tasks in order to have them
+// resolve task-side parameters. See Params for more information.
+package tasktemplate
+
+import (
+	"github.com/luci/luci-go/common/data/text/stringtemplate"
+)
+
+// Params contains supported Swarming task string substitution parameters.
+//
+// A template string can be resolved by passing it to a Params instance's
+// Resolve method.
+type Params struct {

[nodir, 2017/02/18 07:00:54]

i think DM would use the same log_location swarming tag with the same value
format to specify where Milo should find the annotations. Therefore this is not
really swarmbucket specific, but rather swarming. If we have other tags,
unrelated to logging, but that has to have the task id, we'd probably use this
code again.

Even having said that, I am not sure there is a well-defined abstraction level
for this, therefore I am not sure this deserves its own package or whether it
should be extracted out of Milo. I'd move this code to milo/appengine/swarming/,
and, honestly, make it a simple func(template, runid string) to keep things
simple and not overgeneralized. Most of the value of this package was the
parameter substitution which is now moved to a better place.

[dnj, 2017/02/18 07:42:48]

Well, I want Kitchen to import this too, since it needs to do the same
substitution with the "logdog-annotation-url" flag.

[nodir, 2017/02/18 15:40:31]

you are right, this code has to be extracted to a separate package.

still, nothing in this file is about swarmbucket, there is no single mention.
All swarmbucket parameters are resolved by swarmbucket and no other
buildbucket/swarmbucket parameters will appear in log_location tag, or any other
swarming tag. DM would use the same template format.

can we move this to //swarming?

+	// SwarmingRunID is the substitution to use for the "swarming_run_id" template
+	// parameter.
+	//
+	// Note that this is the Swarming Run ID, not Task ID. The Run ID is the
+	// combination of the Task ID with the try number.
+	SwarmingRunID string
+}
+
+func (p *Params) substMap() map[string]string {
+	res := make(map[string]string, 1)
+	if p.SwarmingRunID != "" {
+		res["swarming_run_id"] = p.SwarmingRunID
+	}
+	return res
+}
+
+// Resolve resolves v against p's parameters, populating any template fields
+// with their respective parameter value.
+//
+// If the string is invalid, or if it references an undefined template
+// parameter, an error will be returned.
+func (p *Params) Resolve(v string) (string, error) {
+	return stringtemplate.Resolve(v, p.substMap())
+}