Consider vendoring application-services with moz.yaml
Categories
(Application Services :: General, task)
Tracking
(Not tracked)
People
(Reporter: tcampbell, Assigned: tcampbell)
References
Details
(Keywords: leave-open)
Attachments
(2 external files, 1 obsolete file)
Today we are using ./mach vendor rust to manually vendor a subset of application services and do so on manual cadence. At the same time, Android uses moz.yaml to dump revision on nightly basis.
As we more towards migrating application-services into the monorepo, I am wondering if we should start using a moz.yaml to vendor even more of application-services (such as gradle configuration) so that things are easier to test as monorepo work progresses. Ideally this moz.yaml would be combined with the android-nightly one such that we bump both desktop and android at the same time.
| Assignee | ||
Comment 1•9 months ago
|
||
In preparation for future migration of application-services into tree, start
vendoring application-services as a project instead of just on a per-component
basis. This will make it easier to bring more of application-services (such as
gradle configuration into tree). Currently brings in the same subset of files
as before.
Updated•9 months ago
|
| Assignee | ||
Updated•9 months ago
|
| Assignee | ||
Comment 2•9 months ago
|
||
Replace crate-level vendoring of application-services with a general import
flow. This vendors the same set of crates as desktop currently uses but in
the future will import more and more of application-services. The existing
./mach vendor rust and ./mach uniffi generate steps are still required
when updating.
| Assignee | ||
Comment 3•9 months ago
|
||
Updated•9 months ago
|
| Assignee | ||
Updated•9 months ago
|
Comment 5•9 months ago
|
||
| bugherder | ||
| Assignee | ||
Updated•8 months ago
|
| Assignee | ||
Updated•8 months ago
|
Comment 6•8 months ago
|
||
Comment on attachment 9543765 [details]
Bug 2014911 - Vendor the whole of application-services. r?markh
Revision D282538 was moved to bug 2019144. Setting attachment 9543765 [details] to obsolete.
Description
•