split tagging into en-US and other

RESOLVED FIXED

Status

P4
normal
RESOLVED FIXED
8 years ago
3 years ago

People

(Reporter: bhearsum, Assigned: massimo)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2066] )

Attachments

(5 attachments, 21 obsolete attachments)

7.09 KB, patch
rail
: review+
massimo
: checked-in+
Details | Diff | Splinter Review
14.53 KB, patch
rail
: review+
massimo
: checked-in+
Details | Diff | Splinter Review
5.87 KB, patch
rail
: review+
massimo
: checked-in+
Details | Diff | Splinter Review
671 bytes, patch
rail
: review+
massimo
: checked-in+
Details | Diff | Splinter Review
3.76 KB, patch
rail
: review+
massimo
: checked-in+
Details | Diff | Splinter Review
There's no technical reason why we need to block the start of non-l10n builds/source packages on l10n repositories being tagged. We should parallelize en-US and l10n tagging, and start en-US builds, source packages, and xulrunner builds as soon as en-US tagging finishes.
(Reporter)

Updated

8 years ago
Duplicate of this bug: 540035
bug 708656 is adding a builder that runs prior to tagging. I think it will be easier to do this once it lands.
The bulk of this work is in tag-release.py. There's a couple ways we can approach it:
1) Add --tag-sourceRepo, --tag-l10n, --tag-other flags to the script, and make the associated blocks conditional on those flags.
2) Pass in a list of repositories as arguments, and check all repos against that list, skipping those that don't exist.

I'm not sure which is better, etiher is probably OK.

Updated

7 years ago
Assignee: nobody → bugspam.Callek
Created attachment 592974 [details] [diff] [review]
[tools] v1

This is the attempt at doing the tagging script change, still have the necessary buildbotcustom change to do.
Attachment #592974 - Flags: review?(bhearsum)
Comment on attachment 592974 [details] [diff] [review]
[tools] v1

Review of attachment 592974 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me. This can probably land right away ,considering it defaults to the old behaviour.
Attachment #592974 - Flags: review?(bhearsum) → review+
Created attachment 594332 [details] [diff] [review]
[buildbotcustom] v1

This should do it, I don't have a Firefox buildmaster test setup anywhere yet to verify that it doesn't cause any problems (even with checkconfig) though.
Attachment #594332 - Flags: review?(bhearsum)
Comment on attachment 594332 [details] [diff] [review]
[buildbotcustom] v1

Review of attachment 594332 [details] [diff] [review]:
-----------------------------------------------------------------

All the builder/scheduler changes look OK to me, but this code is fresh in Rail's mind so I'd like him to double check it. r- because of the small issue noted below.

::: process/release.py
@@ +390,3 @@
>              scriptRepo=tools_repo,
>              scriptName='scripts/release/tagging.sh',
> +            extra_args=("--tag-source",),

This won't quite do it...these extra args are passed to tagging.sh, not tag-release.py. You'll need to find some way to pass them through.
Attachment #594332 - Flags: review?(bhearsum) → review-
Created attachment 594814 [details] [diff] [review]
[tools] Part 2, use EXTRA_DATA

I realized we have extra_data as an option to ScriptFactory, and this looks perfect for our use here.
Attachment #594814 - Flags: review?(bhearsum)
Created attachment 594818 [details] [diff] [review]
[buildbotcustom] v2

This should adjust it as requested. Rail, ben wanted you to do a final review of it since this stuff is fresh in your mind.
Attachment #594332 - Attachment is obsolete: true
Attachment #594818 - Flags: review?(rail)
Attachment #594818 - Flags: feedback?(bhearsum)
Comment on attachment 594818 [details] [diff] [review]
[buildbotcustom] v2

This is not a real review for now. Can you add a check if we really want to tag l10n repos? For example Fennec 11.0b1 was en-US only, so there will be no need to tag nor run repacks. Something like "if releaseConfig['l10nPlatforms']".
(In reply to Rail Aliiev [:rail] from comment #11)
> Comment on attachment 594818 [details] [diff] [review]
> [buildbotcustom] v2
> 
> This is not a real review for now. Can you add a check if we really want to
> tag l10n repos? For example Fennec 11.0b1 was en-US only, so there will be
> no need to tag nor run repacks. Something like "if
> releaseConfig['l10nPlatforms']".

The tag_l10n also does the tagging of "other" repos. I think the optional "don't do l10n repacks/tag l10n" should be a different bug. If you disagree I can try and fold that here, but I'd rather keep the logic separate to different bug.
Sounds good in this case. Fennec handles fine en-US only releases (with {} in the l10n json file). Not sure if en-US only Firefox should be a blocker here (another bug?). I'll review the patch in in a couple of days. Thanks for the patch, btw. It should reduce end-to-end time of the release procedure for another 10-20 minutes!
(In reply to Justin Wood (:Callek) from comment #12)
> (In reply to Rail Aliiev [:rail] from comment #11)
> > Comment on attachment 594818 [details] [diff] [review]
> > [buildbotcustom] v2
> > 
> > This is not a real review for now. Can you add a check if we really want to
> > tag l10n repos? For example Fennec 11.0b1 was en-US only, so there will be
> > no need to tag nor run repacks. Something like "if
> > releaseConfig['l10nPlatforms']".
> 
> The tag_l10n also does the tagging of "other" repos. I think the optional
> "don't do l10n repacks/tag l10n" should be a different bug. If you disagree
> I can try and fold that here, but I'd rather keep the logic separate to
> different bug.

I think it makes sense to handle the tagging portion of this here. It should just modify which flags you pass in extra_data, no?
(Reporter)

Updated

7 years ago
Attachment #594814 - Flags: review?(bhearsum) → review+
Comment on attachment 594818 [details] [diff] [review]
[buildbotcustom] v2

Review of attachment 594818 [details] [diff] [review]:
-----------------------------------------------------------------

::: process/release.py
@@ +1500,5 @@
> +            repack_upstream = [
> +                builderPrefix('%s_build' % platform),
> +                builderPrefix('%s_tag_l10n' % releaseConfig['productName']),
> +            ]
> +            repack_scheduler = AggregatingScheduler(

Hmmm, if you're switching to AggregatingScheduler here you should remove the Trigger steps from the en-US builds, too. Even though its based on Triggerable, AggregatingScheduler functions like the Dependent Scheduler in terms of how builds are actually triggered. When you trigger() an AggergatingScheduler you actually reset its state, which would probably be bad here!

Rail, any other gotchas to watch out for?
Comment on attachment 594818 [details] [diff] [review]
[buildbotcustom] v2

> Hmmm, if you're switching to AggregatingScheduler here you should remove the
> Trigger steps from the en-US builds, too. Even though its based on
> Triggerable, AggregatingScheduler functions like the Dependent Scheduler in
> terms of how builds are actually triggered. When you trigger() an
> AggergatingScheduler you actually reset its state, which would probably be
> bad here!

+1
 
> Rail, any other gotchas to watch out for?

I think that --tag-other should be done as a part of source tagging. Mobile builds would fail since they require tagged mozharness.
Attachment #594818 - Flags: review?(rail) → review-
Created attachment 595161 [details] [diff] [review]
[buildbotcustom] interdiff (v2 vs v3)
Attachment #594818 - Attachment is obsolete: true
Attachment #594818 - Flags: feedback?(bhearsum)
Created attachment 595163 [details] [diff] [review]
[buildbotcustom] v3

This should address all review comments:

* Don't do tagging unless we have l10nPlatforms (instead do a Dummy* for tagging)
* Do --tag-other in the source tagging. (Added a comment why)
* Removed the Trigger directive from the Build.
Attachment #595163 - Flags: review?(rail)
Comment on attachment 595163 [details] [diff] [review]
[buildbotcustom] v3

Review of attachment 595163 [details] [diff] [review]:
-----------------------------------------------------------------

Yay! Thanks a lot for the patch.

There are just 2 nits. Otherwise it looks fine and passes test_masters.sh.

Let's land it once we're done with the 10.0.1 release.

::: process/release.py
@@ +419,5 @@
> +                scriptRepo=tools_repo,
> +                scriptName='scripts/release/tagging.sh',
> +                extra_data={"tag_args": "--tag-l10n"},
> +            )
> +    

Please remove trailing spaces from this line.

@@ +609,4 @@
>                  unittestBranch=unittestBranch,
>                  clobberURL=branchConfig['base_clobber_url'],
>                  triggerBuilds=True,
> +                triggeredSchedulers=None,

You can drop this parameter completely since it's None by default.
Attachment #595163 - Flags: review?(rail) → review+

Updated

7 years ago
Attachment #594814 - Flags: checked-in+

Updated

7 years ago
Attachment #595163 - Flags: checked-in+
Just pushed these, and had to do a followup for c#19 nits that I forgot to qref.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Didn't work as expected for 11.0b3. Tagging ran twice for all repos. Since tagging.sh runs without "set -x" it's harder to debug it.

Some additional information:

* download_extra step worked, what indicates that extra_data was passed
* there is no data.json file on the slave
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I suspect clobberer, adding "-s data.json" to our boilerplate script wrappers should help here...
Yes, I blame clobberer:

rel-m-beta-firefox-tag-source:Clobbering...
Skipping scripts
Removing buildbot-configs/
Skipping last-clobber
Skipping buildprops.json
Removing mozilla-beta/
Removing data.json

Comment 24

7 years ago
I currently suspect this bug for breaking linux repacks (script_repo_revision not set anymore.)

Comment 25

7 years ago
(In reply to Aki Sasaki [:aki] from comment #24)
> I currently suspect this bug for breaking linux repacks
> (script_repo_revision not set anymore.)

s,linux,all,
script_repo_revision isn't set and branch is incorrect.
Not having the branch set also breaks clobberer:

Checking clobber URL: http://build.mozilla.org/clobberer/index.php?master=http%3A%2F%2Fbuildbot-master08.build.sjc1.mozilla.com%3A8001%2F&slave=mv-moz2-linux-ix-slave02&builddir=rel-m-beta-lnx-rpk-2&branch=None&buildername=release-mozilla-beta-linux_repack_2%2F6
...
rel-m-beta-lnx-rpk-2:Our last clobber date: 2012-02-14 20:52:40
rel-m-beta-lnx-rpk-2:Server clobber date: 2012-01-27 16:05:40

vs

Checking clobber URL: http://build.mozilla.org/clobberer/index.php?master=http%3A%2F%2Fbuildbot-master08.build.sjc1.mozilla.com%3A8001%2F&slave=mv-moz2-linux-ix-slave10&builddir=rel-m-beta-lnx-bld&branch=mozilla-beta&buildername=release-mozilla-beta-linux_build
...
rel-m-beta-lnx-bld:Our last clobber date: 2012-02-14 10:26:49
rel-m-beta-lnx-bld:Server clobber date: 2012-02-14 20:52:40
rel-m-beta-lnx-bld:Server is forcing a clobber, initiated by asasaki@mozilla.com
Created attachment 597368 [details] [diff] [review]
[buildbotcustom] fix bustage

Not sure which one of you needs to look, but this *should* fix my bustage here.

I did not test since I have no staging area to use
Attachment #597368 - Flags: review?(rail)
Attachment #597368 - Flags: review?(aki)
Created attachment 597369 [details] [diff] [review]
[buildbotcustom] fix bustage

(this time without typo)
Attachment #597368 - Attachment is obsolete: true
Attachment #597369 - Flags: review?(rail)
Attachment #597369 - Flags: review?(aki)
Attachment #597368 - Flags: review?(rail)
Attachment #597368 - Flags: review?(aki)
Comment on attachment 597369 [details] [diff] [review]
[buildbotcustom] fix bustage

branch is a required parameter. On IRC we agreed to backout the patches and land them when they are ready and tested.
Attachment #597369 - Flags: review?(rail)
Attachment #597369 - Flags: review?(aki)
Attachment #597369 - Flags: review-
Comment on attachment 594814 [details] [diff] [review]
[tools] Part 2, use EXTRA_DATA

backout http://hg.mozilla.org/build/tools/rev/34ee54fea8e4
Attachment #594814 - Flags: checked-in+ → checked-in-
Created attachment 598711 [details] [diff] [review]
[buildbotcustom] v3

This replaces all previous patches on this bug, and [hopefully] corrects all issues.

This is applied on top of bug #727489 and uses that design as branch=
Attachment #595161 - Attachment is obsolete: true
Attachment #595163 - Attachment is obsolete: true
Attachment #597369 - Attachment is obsolete: true
Attachment #598711 - Flags: review?(rail)
Created attachment 598713 [details] [diff] [review]
[tools] v3

This patch incorporates all previous patches in this bug, and does the following:

* Fixes -z to -n
* makes the use of EXTRA_DATA add to clobberer excludes
* set -ex instead of set -e
Attachment #592974 - Attachment is obsolete: true
Attachment #594814 - Attachment is obsolete: true
Attachment #598713 - Flags: review?(rail)
Created attachment 598714 [details] [diff] [review]
[buildbotcustom] v3.1

(add in nits from previous review here)
Attachment #598711 - Attachment is obsolete: true
Attachment #598714 - Flags: review?(rail)
Attachment #598711 - Flags: review?(rail)
Created attachment 598881 [details] [diff] [review]
[buildbotcustom] v3.2

I got to get better at saving and qref-ing before attaching lately.
Attachment #598714 - Attachment is obsolete: true
Attachment #598881 - Flags: review?(rail)
Attachment #598714 - Flags: review?(rail)
Comment on attachment 598713 [details] [diff] [review]
[tools] v3

Review of attachment 598713 [details] [diff] [review]:
-----------------------------------------------------------------

::: scripts/release/tag-release.py
@@ +183,4 @@
>      if err:
>          sys.exit(1)
> +    
> +    # Non-fatal warnings only after this point

Please remove trailing spaces above.

@@ +214,5 @@
> +                       help="Tag the source repo(s).")
> +    parser.add_option("--tag-l10n", dest="tag_l10n",
> +                       help="Tag the L10n repo(s).")
> +    parser.add_option("--tag-other", dest="tag_other",
> +                       help="Tag the other repo(s).")

The options above expect argumets, if you try to run the script using command line you get:
tag-release.py: error: --tag-l10n option requires an argument

You need to use action="store_false/true" here.

"tag-release.py ... --tag-source --tag-other" works, but it doesn't tag "other" repos, since optparse interprets --tag-other as an argument of --tag-source.
Attachment #598713 - Flags: review?(rail) → review-
Created attachment 599148 [details] [diff] [review]
[tools] v4
Attachment #598713 - Attachment is obsolete: true
Attachment #599148 - Flags: review?(rail)
Callek, could you also update mozilla/release_templates to reflect the changes in the builder names?

Please, also remove trailing spaces from the tools patch.

I'm running a staging release right now. Tagging worked fine. Waiting for other builders to be triggered properly (l10n).
Mass move of bugs to Release Automation component.
Component: Release Engineering → Release Engineering: Automation (Release Automation)
Flags: checked-in-
(Reporter)

Updated

7 years ago
No longer blocks: 714371
Comment on attachment 599148 [details] [diff] [review]
[tools] v4

r+ if you remove trailing spaces from the patch.
Attachment #599148 - Flags: review?(rail) → review+
I'll be happy to review unbitrotten builbotcustom and buildbot-configs patches with template changes. ;)
Created attachment 611360 [details] [diff] [review]
[buildbot-configs] v1 - Updates templates

Sorry it got lost in my queue.
Attachment #611360 - Flags: review?(rail)
Created attachment 611361 [details] [diff] [review]
[buildbotcustom] v4 - Unbitrotted

This was re-created by hand based on the previous diff here, since I couldn't quickly remember how to rebase properly since my local repo was also newer enough to make the last copy of the patch fail to apply. A re-run of staging release is probably worth it
Attachment #598881 - Attachment is obsolete: true
Attachment #611361 - Flags: review?(rail)
Created attachment 611362 [details] [diff] [review]
[tools] v4.1 - Updated (no trailing whitespace)

Last patch was old though had review, just re-requesting for the trio
Attachment #599148 - Attachment is obsolete: true
Attachment #611362 - Flags: review?(rail)
Attachment #611362 - Flags: review?(rail) → review+
Testing the patches in staging...
Attachment #611361 - Flags: review?(rail) → review+
Created attachment 611473 [details] [diff] [review]
[buildbot-configs] v2 - Updates templates

Interdiff: https://gist.github.com/2284520

* We still need tag_change, it used by http://hg.mozilla.org/build/buildbotcustom/file/309e0a7cddbd/process/release.py#l1818, then hardcoded here http://hg.mozilla.org/build/buildbotcustom/file/309e0a7cddbd/process/release.py#l219

* No need for *_tag_{source,l10n}_change templates, *_change templates are used only by ChangeNotifier, which uses hardcoded "tag" prefix.

Ship it once you r+ this one!
Attachment #611360 - Attachment is obsolete: true
Attachment #611473 - Flags: review?(bugspam.Callek)
Attachment #611360 - Flags: review?(rail)
Comment on attachment 611473 [details] [diff] [review]
[buildbot-configs] v2 - Updates templates

r+ for the changes, but f- since this didn't preserve the hg rename/copies I explicitly did in my patch. If you don't beat me to it I'll land in my unpaid time later today though.
Attachment #611473 - Flags: review?(bugspam.Callek)
Attachment #611473 - Flags: review+
Attachment #611473 - Flags: feedback-
Created attachment 611525 [details] [diff] [review]
[buildbot-configs] v3 - Updates templates

(In reply to Justin Wood (:Callek) from comment #48)
> Comment on attachment 611473 [details] [diff] [review]
> [buildbot-configs] v2 - Updates templates
> 
> r+ for the changes, but f- since this didn't preserve the hg rename/copies I
> explicitly did in my patch.

Ouch... I use git to generate the patches, which doesn't handle explicit file renames... The current patch should be fine.

> If you don't beat me to it I'll land in my unpaid time later today though.

Sure thing, no rush.
Attachment #611473 - Attachment is obsolete: true
Attachment #611525 - Flags: review?(bugspam.Callek)
Comment on attachment 611361 [details] [diff] [review]
[buildbotcustom] v4 - Unbitrotted

http://hg.mozilla.org/build/buildbotcustom/rev/cdda75585a84 <-- Pushed with rail as author instead of me, not sure how that happened, but not worth the backout and reland imo.
Attachment #611361 - Flags: checked-in+

Updated

7 years ago
Attachment #611525 - Flags: review?(bugspam.Callek) → review+
Comment on attachment 611362 [details] [diff] [review]
[tools] v4.1 - Updated (no trailing whitespace)

http://hg.mozilla.org/build/tools/rev/bf37aabfd936
Attachment #611362 - Flags: checked-in+
Sending a mail to release@ for a heads up, and this is now fixed.
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → FIXED
Made it to production today.

Comment 55

7 years ago
I believe this broke Fennec l10n tagging.

Updated

7 years ago
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to Aki Sasaki [:aki] from comment #55)
> I believe this broke Fennec l10n tagging.

Could you elaborate on this?

Updated

7 years ago
Blocks: 749542

Comment 57

7 years ago
Created attachment 619138 [details] [diff] [review]
(untested) fix fennec split tagging

Since there are no l10nPlatforms (single locale) but we require l10n tagging for multilocale, we can't go by len(l10nPlatforms) as the only check for whether to tag.

Testing on staging.

Comment 58

7 years ago
Created attachment 619157 [details] [diff] [review]
(untested) fix fennec split tagging, with typo fix
Attachment #619138 - Attachment is obsolete: true

Comment 59

7 years ago
Comment on attachment 619157 [details] [diff] [review]
(untested) fix fennec split tagging, with typo fix

This patch gets the Fennec l10n tag builder to be a non-Dummy builder, but I'm hitting issues where the Fennec l10n mozilla-beta tag builder is trying to tag mozilla-beta over and over (instead of noticing there are no locales to tag, and skipping).

I'm leaning towards backing out split tagging to fix for now.
Comment on attachment 611361 [details] [diff] [review]
[buildbotcustom] v4 - Unbitrotted

Backed Out in 
http://hg.mozilla.org/build/buildbotcustom/rev/9a5fc1d73fa6
and Merged (complex merge) in
http://hg.mozilla.org/build/buildbotcustom/rev/5a0ad7d77453
Attachment #611361 - Flags: checked-in+ → checked-in-
Comment on attachment 611362 [details] [diff] [review]
[tools] v4.1 - Updated (no trailing whitespace)

Backed out in
http://hg.mozilla.org/build/tools/rev/30a2aa656d8e
Merged in
http://hg.mozilla.org/build/tools/rev/195281b37ed7
Attachment #611362 - Flags: checked-in+ → checked-in-

Comment 63

7 years ago
There are a few gotchas here in terms of mobile:

* The locales are specified in a json changeset file, not the l10n-changesets text file.
** This means that get_l10n_repositories() is not necessarily an accurate list for Fennec; get_locales_from_json() would be correct.
** This bug existed before your work

* Multilocale is currently enabled, even though l10nPlatforms isn't.  I tried to account for this in https://bugzilla.mozilla.org/attachment.cgi?id=619157 .

* However, I hit issues while trying to tag Fennec after applying this patch (see comment 59).  So that patch does create an l10n tagging builder instead of a dummy builder, but the builder seems to be doing the wrong thing.
** This may be a side effect of an empty json changeset file on beta?
I know this isn't actively being worked on, but if/when it gets done please make sure to update the Tag section of the documentation to talk about it: https://wiki.mozilla.org/Release:Release_Automation_on_Mercurial:Tagging_through_Signing#Tag

Comment 65

6 years ago
(In reply to Aki Sasaki [:aki] from comment #57)
> Since there are no l10nPlatforms (single locale) but we require l10n tagging
> for multilocale, we can't go by len(l10nPlatforms) as the only check for
> whether to tag.

Now that:

1) android native, with single locale repacks, is on mozilla-release, (l10nPlatforms is not empty), and
2) we don't have to support linux-android multilocale (no single locale repacks) on esr10,

we may be able to land this again without breaking mobile.
Product: mozilla.org → Release Engineering
I haven't worked on this in a while now. But could further reduce end-to-end time for release jobs if someone wanted to prioritize it.
Assignee: bugspam.Callek → nobody

Updated

4 years ago
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2057]

Updated

4 years ago
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2057] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2066]
(Assignee)

Updated

4 years ago
Assignee: nobody → mgervasini
(Assignee)

Comment 67

4 years ago
Created attachment 8532606 [details] [diff] [review]
[buildbotcustom] Split tagging into en-US and other.patch

Ported Callek's patch to current version of buildbotcustom and updated tag_l10n_factory to use mock.
Attachment #611361 - Attachment is obsolete: true
Attachment #619157 - Attachment is obsolete: true
Attachment #8532606 - Flags: review?(rail)
Comment on attachment 8532606 [details] [diff] [review]
[buildbotcustom] Split tagging into en-US and other.patch

Review of attachment 8532606 [details] [diff] [review]:
-----------------------------------------------------------------

In overall it looks good, just some minor changes.

::: process/release.py
@@ +68,4 @@
>      mozharness_repo_path = releaseConfig.get('mozharness_repo_path',
>                                               branchConfig['mozharness_repo_path'])
>      mozharness_repo = '%s%s' % (branchConfig['hgurl'], mozharness_repo_path)
> +    with_l10n = False

This line is redundant.

@@ +423,4 @@
>          )
>  
>          builders.append({
> +            'name': builderPrefix('%s_tag_source' % releaseConfig['productName']),

This requires template file name changes. Can you rename the templates as well?

@@ +457,5 @@
> +                extra_data={"tag_args": "--tag-l10n"},
> +            )
> +
> +            builders.append({
> +                'name': builderPrefix('%s_tag_l10n' % releaseConfig['productName']),

This requires an extra template.

@@ +464,5 @@
> +                'builddir': builderPrefix('%s_tag_l10n' % releaseConfig['productName']),
> +                'slavebuilddir': normalizeName(
> +                    builderPrefix('%s_tag_l10n' % releaseConfig['productName'])),
> +                'factory': tag_l10n_factory,
> +                'nextSlave': _nextSlave_skip_spot,

nextSlave will be going away with bug 1106922, the same for the source tagging.
Attachment #8532606 - Flags: review?(rail) → review-
(Assignee)

Comment 69

4 years ago
Created attachment 8532673 [details] [diff] [review]
[buildbot-configs] Bug 607392 - updated release templates.patch

Added new templates for Thunderbird
Attachment #8532673 - Flags: review?(rail)
(Assignee)

Comment 70

4 years ago
Created attachment 8532675 [details] [diff] [review]
[buildbotcustom] Split tagging into en-US and other.patch

Updated with changes requested in comment #68. Tools patch following soon.
Attachment #8532606 - Attachment is obsolete: true
Attachment #8532675 - Flags: review?(rail)
(Assignee)

Updated

4 years ago
Attachment #611525 - Attachment is obsolete: true
(Assignee)

Comment 71

4 years ago
Created attachment 8532677 [details] [diff] [review]
[tools] 607392 updated tagging scripts.patch

Updated tagging scripts in tools.
Attachment #611362 - Attachment is obsolete: true
Attachment #8532677 - Flags: review?(rail)
BTW, there are 3 dangling symlinks:

$ find -L . -type l        
./mozilla/release_templates/fennec_ready_for_release
./mozilla/release_templates/firefox_ready_for_release
./mozilla/release_templates/thunderbird_ready_for_release

All of them point to ready_for_release, which doesn't exist. Can you fix them too.
Attachment #8532677 - Flags: review?(rail) → review+
Attachment #8532673 - Flags: review?(rail) → review+
(In reply to Rail Aliiev [:rail] from comment #72)
> BTW, there are 3 dangling symlinks:
> 
> $ find -L . -type l        
> ./mozilla/release_templates/fennec_ready_for_release
> ./mozilla/release_templates/firefox_ready_for_release
> ./mozilla/release_templates/thunderbird_ready_for_release
> 
> All of them point to ready_for_release, which doesn't exist. Can you fix
> them too.

Actually never mind, I'll forward this to the original bug.
Attachment #8532675 - Flags: review?(rail) → review+
(Assignee)

Updated

4 years ago
Attachment #8532673 - Flags: checked-in+
(Assignee)

Updated

4 years ago
Attachment #8532675 - Flags: checked-in+
(Assignee)

Updated

4 years ago
Attachment #8532677 - Flags: checked-in+
(Assignee)

Comment 74

4 years ago
Created attachment 8533782 [details] [diff] [review]
[buildobotcustom] Bug 607392 - cannot shorten *tag_source and *tag_l10n: names are too long.patch

Temporary fix for:

ValueError: Cannot shorten "release-mozilla-release-34.1-firefox_tag_source" to maximum length (30). Got to: rel-m-rel-34.1-firefox_tag_source
Attachment #8533782 - Flags: review?(rail)
Attachment #8533782 - Flags: review?(rail) → review+
(Assignee)

Updated

4 years ago
Attachment #8533782 - Flags: checked-in+
(Assignee)

Comment 78

4 years ago
This patch worked fine for Fennec 35.0b4.

On Firefox 35.0b4, instead, all repacks failed because there 'buildid' and 'script_repo_revision' were not set.

I am creating a new patch to add the missing properties
(Assignee)

Comment 79

4 years ago
I've talked with catlee about this issue.
It's not easy to get the buildid in the Aggregating scheduler and propagate it to the down stream builders. A more sane approach would be fix the create-release-repacks.py script to figure out the buildid by itself. I am going to backout, for a while, the changes made in buildbotcustom/buildbot-configs/tools and fix the create-release-repacks.py script.
(Assignee)

Updated

4 years ago
Attachment #8532673 - Flags: checked-in+ → checked-in-
(Assignee)

Updated

4 years ago
Attachment #8532675 - Flags: checked-in+ → checked-in-
(Assignee)

Updated

4 years ago
Attachment #8533782 - Flags: checked-in+ → checked-in-
(Assignee)

Updated

4 years ago
Attachment #8532677 - Flags: checked-in+ → checked-in-
(Assignee)

Comment 80

4 years ago
Created attachment 8538542 [details] [diff] [review]
[tools] Bug 607392 - do not pass buildid to create-release-repacks.py.patch

create-release-repacks.py now uses getBuildID() to find the right buildid. There is no need to get this parameter from the builders.
Attachment #8538542 - Flags: review?(rail)
Attachment #8538542 - Flags: review?(rail) → review+
(Assignee)

Updated

4 years ago
Attachment #8538542 - Flags: checked-in+
(Assignee)

Updated

4 years ago
Attachment #8532675 - Flags: checked-in- → checked-in+
(Assignee)

Updated

4 years ago
Attachment #8532673 - Flags: checked-in- → checked-in+
(Assignee)

Updated

4 years ago
Attachment #8533782 - Flags: checked-in- → checked-in+
(Assignee)

Updated

4 years ago
Attachment #8532677 - Flags: checked-in- → checked-in+
(Assignee)

Comment 81

4 years ago
The buildid patch from comment #80, has worked fine (Firefox 35.0b5).

I have re-landed all the backed out patches.
(Assignee)

Comment 82

4 years ago
Firefox and Fennec 35.0b6 build 1 completed without any tagging/repacks problems.
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago4 years ago
Resolution: --- → FIXED
Depends on: 1116750
You need to log in before you can comment on or make changes to this bug.