Bug 1423885 - Yet another milestone beetmoverscript #96
Conversation
MihaiTabara
commented
Dec 9, 2017
- fixes checksums
- fixes devedition
- misc
maybe fix devedition
1 similar comment
fix devedition beetmover-cdns
1 similar comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! CHANGELOG.md
could have more explicit changes listed, and we may want to follow semver and bump to 4.0.0.
CHANGELOG.md
Outdated
## [3.5.0] - 2017-12-12 | ||
|
||
### Added | ||
- beetmoverscript support for Devedition releases |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We seem to also have added .beet
support in general, no?
Also, get_product_name
, NORMALIZED_BALROG_PLATFORMS
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, I must have missed some of these in the previous milestone. Will follow-up with a push.
CHANGELOG.md
Outdated
|
||
### Changed | ||
- stop uploading checksums.asc files as `.beet` under beetmover-checksums | ||
- `get_release_props` and `update_props` functions now take context as argument |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a breaking change. It's not as critical for beetmoverscript to respect semver since we have nothing downstream. But if we follow semver, we would bump the major version. 4.0.0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for making this comment. To be honest I was walking on the fence yesterday between MAJOR and MINOR bump https://semver.org/ and wasn't sure since these functions aren't used anywhere downstream. But at a second look, you're right. With my logic at hand, we would never bump the MAJOR :)
# XXX Bug 1424482 - until we solve this, we need this hack. Since en-US | ||
# have at least `stage_platform`, there is a way to tell whether they are | ||
# devedition related or not. But for l10n jobs, we only have `platform` | ||
# which is identical to the ones we have for Firefox. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned in person, we can use graph generation to take attributes['shipping_product']
and turn it into a task.payload.product
; similarly we could use build_platform
and turn it into a task.payload.platform
. If we accept those as optional task payload schema items, and keyed off of them if they exist, then we could slowly reduce the need for balrog_props.json
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, this makes totally sense. This is in my tcmigration cleaup list for beetmover as my reasoning was to first roll-out the milestone version and then follow-up with a potential MINOR bump. I'd like to add proper testing when I make a sensitive change like that and I didn't want to hold back the landing from maple => central this week. I can include those changes as well if you want me to though.