1370389 - TC DevEdition builds are running on mozilla-release

Status: RESOLVED FIXED

(Release Engineering :: General, enhancement, P2)

Description

[Ryan VanderMeulen [:RyanVM]]

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

[Aki Sasaki (not active)]

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

[Aki Sasaki (not active)]

Attachment: devedition-rel.diff

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.

Comment 3

[[e-mail] (:bhearsum)]

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.

Comment 4

[[e-mail] (:bhearsum)]

(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.

Comment 5

[[e-mail] (:bhearsum)]

Attachment: 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...

Comment 6

[[e-mail] (:bhearsum)]

(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

[Aki Sasaki (not active)]

Comment on attachment 8874889 [details] [diff] [review]
add run-on-projects to test definitions

Lgtm! Thanks for the extra verification.