manifest-format.txt 6.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183
  1. repo Manifest Format
  2. ====================
  3. A repo manifest describes the structure of a repo client; that is
  4. the directories that are visible and where they should be obtained
  5. from with git.
  6. The basic structure of a manifest is a bare Git repository holding
  7. a single 'default.xml' XML file in the top level directory.
  8. Manifests are inherently version controlled, since they are kept
  9. within a Git repository. Updates to manifests are automatically
  10. obtained by clients during `repo sync`.
  11. XML File Format
  12. ---------------
  13. A manifest XML file (e.g. 'default.xml') roughly conforms to the
  14. following DTD:
  15. <!DOCTYPE manifest [
  16. <!ELEMENT manifest (remote*,
  17. default?,
  18. manifest-server?,
  19. remove-project*,
  20. project*)>
  21. <!ELEMENT remote (EMPTY)>
  22. <!ATTLIST remote name ID #REQUIRED>
  23. <!ATTLIST remote fetch CDATA #REQUIRED>
  24. <!ATTLIST remote review CDATA #IMPLIED>
  25. <!ELEMENT default (EMPTY)>
  26. <!ATTLIST default remote IDREF #IMPLIED>
  27. <!ATTLIST default revision CDATA #IMPLIED>
  28. <!ELEMENT manifest-server (EMPTY)>
  29. <!ATTLIST url CDATA #REQUIRED>
  30. <!ELEMENT project (EMPTY)>
  31. <!ATTLIST project name CDATA #REQUIRED>
  32. <!ATTLIST project path CDATA #IMPLIED>
  33. <!ATTLIST project remote IDREF #IMPLIED>
  34. <!ATTLIST project revision CDATA #IMPLIED>
  35. <!ELEMENT remove-project (EMPTY)>
  36. <!ATTLIST remove-project name CDATA #REQUIRED>
  37. ]>
  38. A description of the elements and their attributes follows.
  39. Element manifest
  40. ----------------
  41. The root element of the file.
  42. Element remote
  43. --------------
  44. One or more remote elements may be specified. Each remote element
  45. specifies a Git URL shared by one or more projects and (optionally)
  46. the Gerrit review server those projects upload changes through.
  47. Attribute `name`: A short name unique to this manifest file. The
  48. name specified here is used as the remote name in each project's
  49. .git/config, and is therefore automatically available to commands
  50. like `git fetch`, `git remote`, `git pull` and `git push`.
  51. Attribute `fetch`: The Git URL prefix for all projects which use
  52. this remote. Each project's name is appended to this prefix to
  53. form the actual URL used to clone the project.
  54. Attribute `review`: Hostname of the Gerrit server where reviews
  55. are uploaded to by `repo upload`. This attribute is optional;
  56. if not specified then `repo upload` will not function.
  57. Element default
  58. ---------------
  59. At most one default element may be specified. Its remote and
  60. revision attributes are used when a project element does not
  61. specify its own remote or revision attribute.
  62. Attribute `remote`: Name of a previously defined remote element.
  63. Project elements lacking a remote attribute of their own will use
  64. this remote.
  65. Attribute `revision`: Name of a Git branch (e.g. `master` or
  66. `refs/heads/master`). Project elements lacking their own
  67. revision attribute will use this revision.
  68. Element manifest-server
  69. -----------------------
  70. At most one manifest-server may be specified. The url attribute
  71. is used to specify the URL of a manifest server, which is an
  72. XML RPC service that will return a manifest in which each project
  73. is pegged to a known good revision for the current branch and
  74. target.
  75. The manifest server should implement:
  76. GetApprovedManifest(branch, target)
  77. The target to use is defined by environment variables TARGET_PRODUCT
  78. and TARGET_BUILD_VARIANT. These variables are used to create a string
  79. of the form $TARGET_PRODUCT-$TARGET_BUILD_VARIANT, e.g. passion-userdebug.
  80. If one of those variables or both are not present, the program will call
  81. GetApprovedManifest without the target paramater and the manifest server
  82. should choose a reasonable default target.
  83. Element project
  84. ---------------
  85. One or more project elements may be specified. Each element
  86. describes a single Git repository to be cloned into the repo
  87. client workspace.
  88. Attribute `name`: A unique name for this project. The project's
  89. name is appended onto its remote's fetch URL to generate the actual
  90. URL to configure the Git remote with. The URL gets formed as:
  91. ${remote_fetch}/${project_name}.git
  92. where ${remote_fetch} is the remote's fetch attribute and
  93. ${project_name} is the project's name attribute. The suffix ".git"
  94. is always appended as repo assumes the upstream is a forrest of
  95. bare Git repositories.
  96. The project name must match the name Gerrit knows, if Gerrit is
  97. being used for code reviews.
  98. Attribute `path`: An optional path relative to the top directory
  99. of the repo client where the Git working directory for this project
  100. should be placed. If not supplied the project name is used.
  101. Attribute `remote`: Name of a previously defined remote element.
  102. If not supplied the remote given by the default element is used.
  103. Attribute `revision`: Name of the Git branch the manifest wants
  104. to track for this project. Names can be relative to refs/heads
  105. (e.g. just "master") or absolute (e.g. "refs/heads/master").
  106. Tags and/or explicit SHA-1s should work in theory, but have not
  107. been extensively tested. If not supplied the revision given by
  108. the default element is used.
  109. Element remove-project
  110. ----------------------
  111. Deletes the named project from the internal manifest table, possibly
  112. allowing a subsequent project element in the same manifest file to
  113. replace the project with a different source.
  114. This element is mostly useful in the local_manifest.xml, where
  115. the user can remove a project, and possibly replace it with their
  116. own definition.
  117. Local Manifest
  118. ==============
  119. Additional remotes and projects may be added through a local
  120. manifest, stored in `$TOP_DIR/.repo/local_manifest.xml`.
  121. For example:
  122. $ cat .repo/local_manifest.xml
  123. <?xml version="1.0" encoding="UTF-8"?>
  124. <manifest>
  125. <project path="manifest"
  126. name="tools/manifest" />
  127. <project path="platform-manifest"
  128. name="platform/manifest" />
  129. </manifest>
  130. Users may add projects to the local manifest prior to a `repo sync`
  131. invocation, instructing repo to automatically download and manage
  132. these extra projects.