1476856 - Switch several services to takscluster.yml v1

Status: RESOLVED FIXED

(Taskcluster :: Services, defect)

Description

[[:owlish] 🦉 PST]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180611134439

Comment 1

[[:owlish] 🦉 PST]

Description:

We need to assess the pain points and repeat steps of using taskcluster.yml v1. Then we need to summarize them and address the most pressing ones, if not all.

Tasks to complete:
Transition taskcluster-auth, taskcluster-lib-api, and taskcluster-cli to v1. Take note of annoying and repeating steps.

Comment 2

[[github robot]]

Commit pushed to master at https://github.com/taskcluster/taskcluster-auth

https://github.com/taskcluster/taskcluster-auth/commit/7a8edf6057a831bcf426281fabe6d86709aed9e4
Merge pull request #160 from owlishDeveloper/bug1476856

Use v1 taskcluster.yml

Comment 3

[[github robot]]

Commit pushed to master at https://github.com/taskcluster/taskcluster-lib-api

https://github.com/taskcluster/taskcluster-lib-api/commit/19c8bc7d9b5d99f9c0fb3adcee1a6c05feaaef06
Merge pull request #111 from owlishDeveloper/bug1476856

Use v1 taskcluster.yml

Comment 4

[[:owlish] 🦉 PST]

So, my experience:

1. The webhook payload shape quirks didn't actually bother me all that much. In fact, I remembered that we had a table for our translation ("even.head.something" etc.) - we could just have a similar table table for the github payload stuff. Doing their docs for them but oh well

2. The whole `$if-then-$else` interface is a bit of a pain. My nose was fully immersed into json-e documentation at all times, and getting indentation right might be tricky. I would love to address this one.

3. There was some boilerplate code (like worker type and whatnot) which I think could have some defaults in the context.

Comment 5

[Dustin J. Mitchell [:dustin] (he/him)]

(In reply to Irene S [:owlish] from comment #4)
> 1. The webhook payload shape quirks didn't actually bother me all that much.
> In fact, I remembered that we had a table for our translation
> ("even.head.something" etc.) - we could just have a similar table table for
> the github payload stuff. Doing their docs for them but oh well

Yeah, I think that makes a lot of sense.  There are probably 10 things that 99% of our users want.

> 2. The whole `$if-then-$else` interface is a bit of a pain. My nose was
> fully immersed into json-e documentation at all times, and getting
> indentation right might be tricky. I would love to address this one.

Jonas proposed https://github.com/taskcluster/json-e/issues/161

> 3. There was some boilerplate code (like worker type and whatnot) which I
> think could have some defaults in the context.

The workerTypes, in particular, are likely to be different for different deployments of Taskcluster, so I'd worry a little about hard-coding that.  But I bet we could find a creative way to have other defaults based on a context function.  We could also think of making a per-deployment default, but then it might be confusing to try to figure out why something works on one deployment but not on another.

Comment 6

[[:owlish] 🦉 PST]

> Jonas proposed https://github.com/taskcluster/json-e/issues/161

Nice proposal there from Jonas! I was thinking about a kind of a switch myself (I was so remembering the lovely `when` from kotlin as I was correcting my `$if-then-$else` errors!). I'd love to implement that.

> The workerTypes, in particular, are likely to be different for different deployments

Oh I see. In that case, I wouldn't bother with defaults. What about `created` and `deadline`?

Comment 7

[Dustin J. Mitchell [:dustin] (he/him)]

I think a `created` default is 110% a good idea.  The queue already defaults deadline, so no need for us to do that.

$when might be good, too -- then the conditions would be in the object keys?

Comment 8

[[:owlish] 🦉 PST]

> I think a `created` default is 110% a good idea.  The queue already defaults deadline, so no need for us to do that.

👍

> $when might be good, too -- then the conditions would be in the object keys?

I'm looking at the proposal. It seems to me that would like this in practice:

```
context: {event: {ref: "master"} }
template: {
  $switch: ${event.ref}
  "master":
      blablabla
      blablabla
}
```

Seems to be looking good to me. What do you think? 

(The `when` idea was similar just more verbose:

```
context: {event: {ref: "master"} }
template: {
  $when: ${event.ref}
  $is: "master"
     blablabla
     blablabla
}
```

I'm not insistent on it)

Comment 9

[[:owlish] 🦉 PST]

An update on this bug: I implemented the things we discussed above, and created a v1 taskcluster.yml for generic-worker. Indeed, $match operator simplifies matters a ton, and I'm really pleased with that. However, creating v1 taskcluster.yml for generic-worker revealed that for $match and v1 to be really great, we need short-circuiting for our boolean logic operators. There's an issue opened for that: https://github.com/taskcluster/json-e/issues/244 - and I started chewing on it.