Summary:
Allow CI/CD builds to build and publish aarch64 builds alongside the existing x86_64 builds.
The published RPMs will have the same version number as the x86_64 RPMs allowing standard slowroll logic to push the packages to the fleet. This allows the aarch64 bringup team to stop special-casing slowroll.
This diff affects only the RPMs that are required for initial bringup. Subsequent activity will add more RPMs.
Context about the aarch64 effort: https://fb.workplace.com/groups/1858357931081326/posts/3670012916582476
Differential Revision: D38386331
fbshipit-source-id: 7a72da85868d0c0a488940cfff4285145ef114e7
Summary:
The "Portions" license cannot be updated automatically. So this is a manual
update using:
sd -s 'Portions Copyright (c) Facebook, Inc. and its affiliates.' 'Portions Copyright (c) Meta Platforms, Inc. and affiliates.' `rg -l Facebook`
sd -s 'Copyright (c) Facebook, Inc. and its affiliates.' 'Copyright (c) Meta Platforms, Inc. and affiliates.' `rg -l Facebook`
Differential Revision: D33420114
fbshipit-source-id: 49ae00a7b62e3b8cc6c5dd839b3c104a75e72a56
Summary:
We'd like to keep track of hg cache size on users' machines. It's generally
useful, but it will be even more important with megarepo rollout. The job will be triggered by cron.
This is a very simple implementation, most of it was copy-pasted from
https://fburl.com/diffusion/g8ysyxo1.
Note that I intentionally didn't call hg to get hgcache size.
Since this binary will be triggered by cron, it will run as
root without a direct access to user's repository.
A few notes for the future:
1) Currentlly I'm planning to get hgcache path value from opsfiles.
I'm not sure if we'd need to change this later when dynamic configs are fully
rolled out. CC DurhamG
2) We might want to track size of pack files (are they still used at all?) and
indexed log files separately
Reviewed By: ikostia
Differential Revision: D23341149
fbshipit-source-id: 2a600d7a8034ac887014788f1024fb9866c3ef76
