- delete & clean this? https://hg.mozilla.org/build/puppet/file/tip/modules/beetmover_scriptworker/templates/base_script_config.json.erb#l14
- think about a way to trim the unused files and not upload more than we used to for candidates/releases - they slow down beetmoverworker e.g en-Us stuff http://bucketlister-delivery.stage.mozaws.net/pub/firefox/candidates/58.0b6-candidates/build11/linux-i686/en-US/
- cleanup of docker image beetmover?
- fix the beetmoverscript tests by adding proper fixtures to fix the damn release case
- make sure the nightlies still work after beetmover-repackage changes. check the graphs are the same!
- beetmoverscript to use boto.copy() instead of reuploading for multiple destinations to efficientize uploads + bandwidth
- improve the generate_balrog_info() function by using either a
breakstatement there or a dict withbuildidas key for O(1) access - "Also, do we have anything validating the get_partials_props schema? That may belong in get_partials_props, or in the release task schema as an optional field. This doesn't block, but may help in the future."
- more verbose CHANGELOG
- MAJOR bump the beetmoverscript with the recent chanes
- shipping_product and shipping_phase in the task.payload as optional. Gradually migrate lines from balrog props - copy over the push_to_candidates function maybe from the push_to_nightly one - more comments in Aki's PR mozilla-releng/beetmoverscript#96
- ideally we'd have templates fed within the build system so that you single-source all these things. But a good compromise and intermediary step would be to move templates from beetmoverscript into in-tree so that at least we have two places to modify: build + templates but they are both in-tree. Plus the advantage is any potential changes are riding the trains so we don't need to worry about "from this X release on, stop pushing Y artifact" or so. In order to do so, we can either put them in-tree and have beetmover download them with wget or hack somehow in scriptworker to have them ready.
- stop being dummy in staging releases
- address rail"s comment on balrogscript PR
- fix balrogscript unit testing to 100%
- this needs fixing along with the others in the file: https://hg.mozilla.org/build/puppet/file/tip/modules/balrog_scriptworker/templates/script_config.json.erb#l43
- balrog jobs return Completed even though they hit errors when submitting data to Balrog. Make them less tolerant to silent errors. Example here and here
- urgently add logic to separate operations per scopes. Right now, if we accidentally have "tc_nightly" in a release-manifest, it will try to push to nightly and vice-versa. Follow the action model from beetmoverscript
- check why no windows under beetmover-checksums
- was I supposed to add transforms with task schema validation at least?
- add dummy task for stress-test conditions
- make sure we get rid of hardcoding en-US main build for balrog_props in beetmover-source. Otherwise we end up having Fennec source uploaded to fx-candidates or so
- why are we bothering with release-source if we can point to README file instead?
- remove maple_desktop_promotion from util/scriptworker.py and make it default to "dep"
- we need to adjust the worker-type in balrog/beetmover_repackage transforms to separate stuff from staging vs production
- remove source-test and filter out from second graph fennec generation - https://tools.taskcluster.net/groups/WJHti58xSs60QiaR0FTcnw aki> mtabara: no, we should optimize those out. they're harmless though
- be consistent with dep/dev workerTypes under https://tools.taskcluster.net/provisioners/scriptworker-prov-v1/worker-types
./mach tashgraph test-action-callback --task-group-id fhGL_9mXQTim-VtnVEKEfQ --input ~/Downloads/debugging/promote_firefox.yml -p ~/Downloads/debugging/maple-desktop-promotion.yml release_promotion_action