Closed Bug 1297011 Opened 8 years ago Closed 8 years ago

Invalid versions should not fetch l10n changesets

Categories

(Release Engineering :: Applications: Shipit, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Sylvestre, Assigned: jlorenzo)

References

Details

Attachments

(1 file)

50 bytes, text/x-github-pull-request
rail
: review+
Details | Review
Enter 23.0, this is a valid version, I get a proper list of changeset. Now, enter 23.0b2.0, obvious, ship-it cannot retrieve the list of changeset as the version doesn't exist. However, I still get the list of changeset for 23.0. So, when we touch the version field, we should automatically reset the l10n changeset.
Johan, can you look at this?
Flags: needinfo?(jlorenzo)
Sure!
Assignee: nobody → jlorenzo
Status: NEW → ASSIGNED
Flags: needinfo?(jlorenzo)
I'm sorry, I'm not sure to understand the issue. Should 23.0b2.0 be considered as an invalid version, so we shouldn't retrieve l10n changesets? In the current state, 23.0b2.0 does reset the l10n field[1]. But it goes fetch https://l10n.mozilla.org/shipping/l10n-changesets?av=fx23 , and as the result is already cached, the field is filled nearly instantaneously. That's why, it seems like the there was no reset done. [1] https://github.com/mozilla-releng/ship-it/pull/103/files#diff-f2f19f23c632c1a8154fd734bebd6ed1R238
Depends on: 1292188
Flags: needinfo?(sledru)
From Sylvestre on IRC: > 10:03:35 <Sylvestre> 23.0b2.0 is invalid, so, we should not have anything in the l10n field Changing the title accordingly.
Flags: needinfo?(sledru)
Summary: Changing the version should reset the l10n changeset field → Invalid versions should not fetch l10n changesets
Attached file PR
This patch makes the JS-side behaving similarly to the Python one (the one defined in bug 1296168). The regexp that says if a version number is valid is the same in both cases. There is now room for a few enhancements: * Centralize the regex in 1 file, and make both Python and JS read from it. * Split release.js into version.js and release.js. Most of what's in release.js is actually making sure we have a valid version number. The only part specific to a release is the build number * Once version.js is defined: Use it everywhere we can in suggestions.js. This will make functions like isBeta(version) useless. * Show a warning when a bad version number is entered. I propose to make these changes in follow ups. Changing the regex on the JS-side led to a considerable amount of changes already. What do you think, rail?
Attachment #8783672 - Flags: review?(rail)
Depends on: 1296168
Blocks: 1297483
Attachment #8783672 - Flags: review?(rail) → review+
Deployed PR #114 as part of a push for another change.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Component: Applications: ShipIt (backend) → Applications: ShipIt
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: