support writing decision tasks
Categories
(Firefox Build System :: Task Configuration, task)
Tracking
(Not tracked)
People
(Reporter: bhearsum, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(4 files)
Updated•8 years ago
|
Comment 1•8 years ago
|
||
Reporter | ||
Comment 2•7 years ago
|
||
Comment 3•7 years ago
|
||
Comment 4•6 years ago
|
||
Updated•6 years ago
|
Comment 5•6 years ago
|
||
Comment 6•6 years ago
|
||
http://hg.mozilla.org/users/mozilla_hocat.ca/ci-taskgraph is ready for review. The last few commits exists for testing without configuring having a repository with proper permissions set up.
The following is probably a useful command in reviewing this.
git diff --no-index --diff-filter=AM ../mozilla-central/taskcluster/taskgraph/ src/taskgraph
Also, I've tried to make the commit history readable.
It generates https://tools.taskcluster.net/groups/Oe1nA7IiTEW6EBi1WGICrA
The intention is for this to live at https://hg.mozilla.org/ci/taskgraph
Comment 7•6 years ago
|
||
This looks great!
It looks like this includes:
- overall graph generation process
- parameters (but fewer)
- docker image builds
- multiple "projects" in the same repo
- verifications framework (but not all verifications)
- hg specificity (pushlog_id, at least)
- optimization
- some of the existing hierarchy of transforms (task description, job)
- treeherder support
(wow, that's a lot out of the box!)
and excludes:
- actions
- try support
- some specific optimizations
- release-related stuff
- generic-worker (at least in task.py)
(all of that's fine, I'm just trying to get a handle on the scope)
How do you see users of this software interacting with it? "Vendoring" it into their repo? "Hard forking" it into their repo? Depending on it as a requirement?
What do you think are the next steps?
Comment 8•6 years ago
|
||
(In reply to Dustin J. Mitchell [:dustin] pronoun: he from comment #7)
This looks great!
It looks like this includes:
- overall graph generation process
- parameters (but fewer)
- docker image builds
- multiple "projects" in the same repo
Note that project
is how taskgraph talks about branches (in the sense that m-c and m-b are branches).
- verifications framework (but not all verifications)
- hg specificity (pushlog_id, at least)
- optimization
- some of the existing hierarchy of transforms (task description, job)
- treeherder support
(wow, that's a lot out of the box!)and excludes:
- actions
This and cron are high on my list of follow ups.
- try support
I want to support some sort of try, but at least for the initial projects, just running all the tasks is reasonable. I'm not sure what kind of support is needed for this.
- some specific optimizations
- release-related stuff
I think the removed optimizations and release related stuff is gecko specific. I do want to figure out how to introduce customization to handle similar things, but I'll need some use cases.
- generic-worker (at least in task.py)
Given that there aren't generic windows workers, this is lower priority.
(all of that's fine, I'm just trying to get a handle on the scope)
How do you see users of this software interacting with it? "Vendoring" it into their repo? "Hard forking" it into their repo? Depending on it as a requirement?
That is what the decsion-user
docker image for. It includes the taskgraph package in it. My thought is that people will pin to a particular version (I've got some thoughts on changing the index used to be based on the commit hash) of the image, and use it that way.
What do you think are the next steps?
I'd like to get a repo landed, and this code landed an working, and the corresponding code in ci-admin.
actions and cron support are high priority. After that, I have a trello board tracking improvements I have in mind (invite sent). I'll probably start looking at some of our mobile products, and see what is required to port them to taskgraph.
Comment 9•6 years ago
|
||
Awesome! It's probably good to get this "in use" in a wide array of contexts to help suss out any remaining specific bits. I can volunteer to try to use this for the TC monorepo (which is currently using some fancy json-e in .taskcluster.yml). But that's a github repo so might already require some tweaks.
Comment 10•6 years ago
|
||
We are very intested in adding a decision task for wpt on GitHub, so would be very happy to try this out once it's ready for GitHub-backed usage.
Comment 11•6 years ago
|
||
Comment 12•6 years ago
|
||
Comment 13•6 years ago
|
||
Comment 14•6 years ago
|
||
Comment 15•6 years ago
|
||
Comment 16•6 years ago
|
||
Updated•6 years ago
|
Reporter | ||
Comment 17•6 years ago
|
||
For it's worth, my original problem (having tasks that depend on other tasks) is solveable with the tc-gh v1 schema via as_slugid().
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Comment 20•3 years ago
|
||
The bug assignee didn't login in Bugzilla in the last 7 months.
:ahal, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 21•3 years ago
|
||
This is fixed :)
Description
•