Closed
Bug 1370389
Opened 7 years ago
Closed 7 years ago
TC DevEdition builds are running on mozilla-release
Categories
(Release Engineering :: General, enhancement, P2)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: RyanVM, Assigned: bhearsum)
Details
Attachments
(2 files)
3.58 KB,
patch
|
Details | Diff | Splinter Review | |
9.38 KB,
patch
|
mozilla
:
review+
bhearsum
:
checked-in+
|
Details | Diff | Splinter Review |
It would appear we aren't restricting them to only Beta :\ https://treeherder.mozilla.org/#/jobs?repo=mozilla-release&filter-searchStr=devedition&fromchange=0641fc6ee9d1fc9c22780545f7937f339a8f80ae
Comment 1•7 years ago
|
||
This is probably because mozilla_release_tasks just returns the output of mozilla_beta_tasks. Why would those two ever diverge? Maybe they both should call a shared helper function. https://hg.mozilla.org/releases/mozilla-release/file/tip/taskcluster/taskgraph/target_tasks.py#l238
Comment 2•7 years ago
|
||
Stab at fixing. For some reason this didn't seem to get rid of devedition on m-r in my testing, though. No idea why.
Updated•7 years ago
|
Priority: -- → P2
Assignee | ||
Comment 3•7 years ago
|
||
This is really weird, the devedition builds have run-on-projects set to ['mozilla-beta',] (which is how we ensure they are disabled on mozilla-central et. al). I confirmed that that is still set after the uplift, too. I wonder if we need blocks like https://hg.mozilla.org/releases/mozilla-release/file/tip/taskcluster/ci/test/tests.yml#l55 for devedition everywhere? I can't imagine the task graph generator would add tests for builds that don't already exist, but it's possible? A quick short term hack might be to filter out anything matching 'devedition' in your new target_tasks_mozilla_release function.
Assignee | ||
Comment 4•7 years ago
|
||
(In reply to Ben Hearsum (:bhearsum) from comment #3) > This is really weird, the devedition builds have run-on-projects set to > ['mozilla-beta',] (which is how we ensure they are disabled on > mozilla-central et. al). I confirmed that that is still set after the > uplift, too. I wonder if we need blocks like > https://hg.mozilla.org/releases/mozilla-release/file/tip/taskcluster/ci/test/ > tests.yml#l55 for devedition everywhere? I can't imagine the task graph > generator would add tests for builds that don't already exist, but it's > possible? Sounds like this is the file we need to fiddle in based on a conversation with dustin: 11:13 < bhearsum> we recently added new builds/tests to mozilla-beta for the "devedition" builds. we marked the builds as run-on-projects: ['mozilla-beta'], but not the tests. after we uplifted to mozilla-release, we have those builds and tests running. do we need to mark all of the tests with run-on-projects as well to prevent this? curiously, the same code landed on mozilla-central doesn't cause the builds to run 11:13 < bhearsum> there 11:17 <@dustin> bhearsum: the default for run-on-projects for a test is "built-projects" 11:17 <@dustin> which means basically copy run-on-projects from the build for that platform 11:17 <@dustin> but I don't think that's been uplifted to beta yet 11:17 < bhearsum> ah 11:18 < bhearsum> yeah, i don't see that being set for these tests on release 11:18 < bhearsum> and i guess if the tests are included, the build implicitly gets included even if it was filtered out? 11:19 <@dustin> bhearsum: yeah 11:19 < bhearsum> ah, ok 11:19 <@dustin> that's why we added this setting 11:19 <@dustin> the run-on-projects for tests were getting pretty huge I think we'll only need to backport to mozilla-release. ESR will not have devedition build definitions until the next ESR cycle (which will have the new defaults for tests), and the next beta uplift will also have the new defaults. I'm working on a patch.
Assignee | ||
Comment 5•7 years ago
|
||
I did a before and after run of "taskgraph target-graph" of this. I compared the keys spit out, and all of the devedition jobs were removed. It's difficult to be certain that no other tasks were modified. There's tons of changes in the diff because of sorting, but I think we end up in the same place in the end? I'm going to try to do a bit more verification by removing all of the devedition tasks from the "before" side and re-diffing...
Attachment #8874889 -
Flags: review?(aki)
Assignee | ||
Comment 6•7 years ago
|
||
(In reply to Ben Hearsum (:bhearsum) from comment #5) > Created attachment 8874889 [details] [diff] [review] > add run-on-projects to test definitions > > I did a before and after run of "taskgraph target-graph" of this. I compared > the keys spit out, and all of the devedition jobs were removed. It's > difficult to be certain that no other tasks were modified. There's tons of > changes in the diff because of sorting, but I think we end up in the same > place in the end? I'm going to try to do a bit more verification by removing > all of the devedition tasks from the "before" side and re-diffing... I did some more verification by: - comparing task names (only devedition ones were removed) - comparing altered "taskgraph target" output (after removing "devedition" from the "before" side, no changes) - comparing altered "taskgraph target-graph" output (after removing "devedition" from the "before" side, no changes) - comparing sorted (via bash "sort") raw json after removing "devedition" from the "before" side - no changes 99% sure this patch is correct now.
Comment 7•7 years ago
|
||
Comment on attachment 8874889 [details] [diff] [review] add run-on-projects to test definitions Lgtm! Thanks for the extra verification.
Attachment #8874889 -
Flags: review?(aki) → review+
Assignee | ||
Updated•7 years ago
|
Attachment #8874889 -
Flags: checked-in+
Assignee | ||
Updated•7 years ago
|
Assignee: nobody → bhearsum
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Component: General Automation → General
You need to log in
before you can comment on or make changes to this bug.
Description
•