fix: replace uses of Parameters.is_try() with level check#969
Conversation
|
I debated if this should be considered breaking or not.. I don't think it materially changes graphs, just might reduce artifact expiry in some cases, so I opted for not |
|
Actually, I just realized that gecko_taskgraph has its own |
BREAKING CHANGES: Must pass in the `--allow-parameter-override` flag to load try config This gives us a more explicit signal about whether we should use `try_task_config.json` than whether the string "try" happens to exist in the repo name. Bug: 2044330
BREAKING CHANGES:
- Removed `Parameters.is_try()`
- Level 1 repos may now have shorter artifact expirations for
docker-image tasks
In the Github world, what is considered "try" or not is much less
defined than it is on hgmo. Currently we have "enterprise-firefox-try",
"firefox-dev" and "staging-firefox" that are all "try-like" in that they
will run tasks on any arbitrary branch push.
We can no longer rely on the magic string "try" being present in the
repo name to determine this, and imo nor should we ever have been.
At least in this repo, all uses of `is_try()` are probably better off
just using `level == 1` instead.
Bug: 2044330
bhearsum
left a comment
There was a problem hiding this comment.
This is a good improvement. I think we should get rid of the very Mozilla-specific try_task_config_file in the future as well, but that's out of scope here.
Once the Git note is working well and Gecko is migrated to it we can remove support for the file. Though |
In the Github world, what is considered "try" or not is much less defined than it is on hgmo. Currently we have "enterprise-firefox-try", "firefox-dev" and "staging-firefox" that are all "try-like" in that they will run tasks on any arbitrary branch push.
We can no longer rely on the magic string "try" being present in the repo name to determine this, and imo nor should we ever have been.
At least in this repo, all uses of
is_try()are probably better off just usinglevel == 1instead.Bug: 2044330