task-expires-after should be more broadly configurable

[bhearsum]

#409 added a task-expires-after to config.yml which only applies to non-try tasks, with other tasks defaulting to a hardcoded level of "1 year". This is confusing, because when you look at the configuration all you see is something like:

task-expires-after: 90 days

...which can be fairly interpreted to mean "all tasks expire after 90 days" (I'm not even sure most people would interpret it to mean "by default, unless overridden elsewhere", although that's probably a separate issue.)

To remedy this, I think task-expires-after should apply to all task defaults, and support being configured at least by-level and by-tasks-for (to allow things like try and pull requests to easily have separate expires configured). This would make the behaviour much more obvious to users, and have the benefit of getting rid of fully hardcoded values such as in

taskgraph/src/taskgraph/transforms/task.py

Lines 1084 to 1086 in 649bba5

	config.graph_config._config.get("task-expires-after", "28 days")
	if config.params.is_try()
	else "1 year"

.

[ahal]

Maybe we could also call it default-task-expires-after.

Though at this point, it seems like what we really want is a global task-defaults (just like you can have a task-defaults in a kind.yml that then gets used by all the files in tasks-from, except that this time it would work across all kinds).

This probably warrants a separate issue though.

[bhearsum]

Maybe we could also call it default-task-expires-after.

Though at this point, it seems like what we really want is a global task-defaults (just like you can have a task-defaults in a kind.yml that then gets used by all the files in tasks-from, except that this time it would work across all kinds).

This probably warrants a separate issue though.

I could go either way on this. I can see a case for treating something like expires in a special way (because it's always part of a task definition), whereas supporting task-defaults in general could end up getting weird because, eg: someone may want to set defaults or all things that go through the run transforms, which may not apply to something like fetch. I wouldn't try to veto this change if someone wanted to do it, and it would supercede this, but I agree it's a separate issue.