Closed
Bug 1297011
Opened 8 years ago
Closed 8 years ago
Invalid versions should not fetch l10n changesets
Categories
(Release Engineering :: Applications: Shipit, defect)
Release Engineering
Applications: Shipit
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: Sylvestre, Assigned: jlorenzo)
References
Details
Attachments
(1 file)
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.
Assignee | ||
Comment 2•8 years ago
|
||
Sure!
Assignee: nobody → jlorenzo
Status: NEW → ASSIGNED
Flags: needinfo?(jlorenzo)
Assignee | ||
Comment 3•8 years ago
|
||
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)
Assignee | ||
Comment 4•8 years ago
|
||
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
Assignee | ||
Comment 5•8 years ago
|
||
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)
Updated•8 years ago
|
Attachment #8783672 -
Flags: review?(rail) → review+
Comment 6•8 years ago
|
||
Deployed PR #114 as part of a push for another change.
Assignee | ||
Comment 7•8 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Updated•3 years ago
|
Component: Applications: ShipIt (backend) → Applications: ShipIt
You need to log in
before you can comment on or make changes to this bug.
Description
•