Improve the comprehension of "try" and "try-not-by-default" for Taskcluster Tasks

RESOLVED WONTFIX

Status

Firefox Build System
Task Configuration
RESOLVED WONTFIX
2 years ago
5 months ago

People

(Reporter: Callek, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [try-option-syntax])

(Reporter)

Description

2 years ago
With Bug 1286075, many tasks have a `run-on-projects` magic, which in cases where its NOT run on try by default, it omits listing `try`

This has caused a few concerns/pieces-of-confusion during review phases on the various patches there.

With IRC chat with :dustin, we came up with a rough plan for improving cognition on these definitions:

```(yml) [partially pseudo-code]
foo:
   try-style: explicit-only
   run-on-projects: all
bar:
   try-style: runs-when: <ref: build-linux64>
   run-on-projects: [release, try]
drunk:
   run-on-projects: try
   # Optional:
   try-style: all
sanity:
   run-on-projects: release, inbound
   # try-style here could be fatal, since not run on try
```

where foo is only run on try if specified, bar is run when specified or when build-linux64 triggers (*and* if file restriction is present, when those files are touched) drunk runs on -p all, and sanity never runs on try.

:dustin also suggested alternative format:

run-on-projects:
  integration
  try: explicit

===

This proposal includes runs-when: which can be a means to move the RIDEALONG_BUILDS logic closer to the actual task definition, but is not strictly required for the reasoning behind suggesting this improvement.
Whiteboard: [try-option-syntax]
As we get away from try-option-syntax, I think this is less critical.
Status: NEW → RESOLVED
Last Resolved: 9 months ago
Resolution: --- → WONTFIX

Updated

5 months ago
Product: TaskCluster → Firefox Build System
You need to log in before you can comment on or make changes to this bug.