RFC: Easy Taskcluster Setup

[sarah-clements]

As I read this, I realized that the original idea I had in my head for an onboarding tool is very tightly coupled with the taskgraph workflow changes, and the shared worker pool. This would let us make a lot of assumptions about worker types and other things that may simplify what we present to the user.

Reading this, I realize that we may require an extra abtraction layer, or maybe even a separate tool altogether for those assumptions to hold without baking them into Taskcluster itself.

This is not a blocker, and maybe tying this so tightly to the other work is a bad idea, but I wanted to call it out.

It might help if we get more specific about the level of detail and knowledge we expect the users of this tool to have and provide. Two extremes could be:

* users only need to provide information that is obvious to them -- what platforms they build/test on, the commands used to perform these things, etc.

* users will need to provide precise worker types and other task metadata. in this extreme, maybe the tool is teaching them about taskcluster at the same time?

I think the latter extreme would not really achieve the goal of making Taskcluster easier to bootstrap compared to competitors. I'm not a good proxy for all engineers, but when I was looking at the taskcluster docs my thought was that it seemed to require a lot of thinking and querying to get setup just to run basic python and js tests. So, I think we might want to aim for the former point.

[sarah-clements]

I love this! I think this is in line with other things we've discussed, although I can't find the documentation for those discussions now. At least some of those discussions took place in Whistler, iirc, so they may not be written down anywhere.

In general, I think this is a bit of an early-stage idea for an RFC. An RFC should have a clear scope and a proposed changes. So, perhaps after the UX surveys are done. It's fine to keep this open until then, of course!

A few pieces of data for your consideration:

* The current quickstart [uses](https://github.com/taskcluster/taskcluster/blob/d31391f4dbd43b56e252a7e335881fdb1abd1938/ui/src/views/Quickstart/index.jsx#L74-L76) a [site-specific value](https://docs.taskcluster.net/docs/manual/deploying/ui#site-specific-documentation) to determine which taskQueueId it should use.  I think it'd be fine to add a few more such variables to allow customizing the quickstart to a particular deployment.  But, I would lean toward not making that especially complicated, and focusing instead on getting a thing that works and runs a task.  Then users can get that taste of success and go on to improve it.  So, for example, I wouldn't advise any complex taskQueueId selection logic, but just defaulting to the tutorial workerPoolId.  In firefox-CI, that can be a dedicated, small pool that will run someone's first PR, and from which they can switch to a better pool later.

* Debugging `.taskcluster.yml` is currently quite difficult.  We have talked in the past about extending the quickstart to allow loading a `.taskcluster.yml` from a repository and allowing the user to test it in the browser by rendering it (with JSON-e) in various contexts.  In the dream scenario, we would generate those contexts from actual events that GitHub has sent for the given GitHub repository.  That would require storing those events, which might have some other benefits for debugging.  It might also have some security implications, especially for private repositories.

* [mozilla-releng/releng-rfcs#36](https://github.com/mozilla-releng/releng-rfcs/pull/36) is moving in a different direction from this RFC.  I'm not sure which one is best!  But, if as that RFC suggests we add a `baseConfig` property to `.taskcluster.yml`, then perhaps the better choice for improving the getting-started workflow is to present a menu of baseConfigs and their parameters.  I'm not sure if that would be best implemented in the Taskcluster UI or elsewhere.

Sorry for the delayed response and thanks for your feedback! @bhearsum and I were talking about this and we're thinking his RFC would still be a pre-curser to doing this work (improving the the quickstart guide with some presets and then if people need to manually modify the config, it'll be easier to do so). Were there any concerns about integrating the simplified config with the quickstart guide? Also, since you're leaving soon is there anyone else we should rope into this? We don't want to step on toes or catch anyone by surprise.

[djmitche]

The concern I would have with integrating the simplified config is, would that make sense in Acme, Inc.'s Taskcluster deployment, or would it be recommending things that only make sense at Mozilla? That could include simplified config if that's done in such a way that anyone can use it without further setup, and that it makes sense for non-Mozilla projects.

I think @imbstack and @petemoore are the resident authorities now.

[sarah-clements]

The concern I would have with integrating the simplified config is, would that make sense in Acme, Inc.'s Taskcluster deployment, or would it be recommending things that only make sense at Mozilla? That could include simplified config if that's done in such a way that anyone can use it without further setup, and that it makes sense for non-Mozilla projects.

I think @imbstack and @petemoore are the resident authorities now.

That makes sense. @bhearsum any thoughts about this?

[bhearsum]

The concern I would have with integrating the simplified config is, would that make sense in Acme, Inc.'s Taskcluster deployment, or would it be recommending things that only make sense at Mozilla? That could include simplified config if that's done in such a way that anyone can use it without further setup, and that it makes sense for non-Mozilla projects. I think @imbstack and @petemoore are the resident authorities now.

That makes sense. @bhearsum any thoughts about this?

I totally agree with Dustin, and I think this hinges on whether or not taskgraph is considered part of the Taskcluster platform. If it is, I think it's relevant to all Taskcluster deployments. If not, it's Mozilla-specific.

[ahal]

I can't remember where it came up, but I remember an idea was floated to have a generic taskgraph that is part of the platform, then a mozilla_taskgraph that consumes it (and implements all our current mozilla-isms. Personally I'd love to have taskgraph be a piece of the taskcluster platform, though I'm not sure how or whether it fits in with the "Releng for Mozilla" timeline.

[bhearsum]

I can't remember where it came up, but I remember an idea was floated to have a generic taskgraph that is part of the platform, then a mozilla_taskgraph that consumes it (and implements all our current mozilla-isms. Personally I'd love to have taskgraph be a piece of the taskcluster platform, though I'm not sure how or whether it fits in with the "Releng for Mozilla" timeline.

I think that was a conversation with Aki or maybe Dustin (I don't remember now). IMO I think we're definitely going to have a taskgraph, mozilla_taskgraph, and probably some project-specific ones (as we do now). In my head, the only questions are: 1) Where the simplified config stuff ends up (I'd really like that to be taskgraph) 2) Whether or not taskgraph is considered "core" taskgraph (this is more of a question for the Taskcluster team, I think?)

[djmitche]

To the extent I can still speak for that team, I think we'd like to have taskgraph be a part of the platform.

[sarah-clements]

Hi @petemoore and @imbstack, could you both please take a look at this, add your comments and mark this with the Final comment label?

[sarah-clements]

@petemoore Can you merge this please?

[petemoore]

@petemoore Can you merge this please?

Hi @sarah-clements, sorry I've only just seen this. I can have a look at it this week, and I'll try to get input from @imbstack too. It looks like neither Brian nor I have had a look it yet, sorry about that. After that we can move it to Phase: Final Comment.

[imbstack]

Hey, sorry I've been PTO for a few weeks. This looks great to me! I've moved it into final comment. I'd say let's give it a couple days and if nobody has yelled, we'll mark it accepted!

[sarah-clements]

Hey, sorry I've been PTO for a few weeks. This looks great to me! I've moved it into final comment. I'd say let's give it a couple days and if nobody has yelled, we'll mark it accepted!

Haven't heard any screaming :) Can you please merge it?

[imbstack]

Landed! Thanks for this!