Lines Matching refs:project
35 repositories in the workspace, with each project repository boxed in by a
42 project repositories. This relationship is shown using dotted line arrows in the
44 to a corresponding commit in a project repository.
60 One use for moving backward in project history is to "revert" a regression by
66 - In the above diagram, no project repository has two revisions "at
84 # short names for project URLs
88 # default project attributes
94 # a list of project groups to enable or disable
116 the complete Git fetch URL for each project. A project's fetch URL can be set
117 by appending a project-specific path onto a remote URL base. (As we'll see
146 project with this remote.
159 The ``projects`` subsection contains a sequence describing the project
160 repositories in the west workspace. Every project has a unique name. You can
162 what revisions to track, and where the project should be stored on the local
177 description: the first example project
179 path: extra/project-1
183 project.
188 url: https://github.com/user/project-three
195 with a ``/`` and the project ``name`` to form the URL.
197 Locally, this project will be cloned at path ``extra/project-1`` relative to
201 Since the project has no ``revision`` specified, ``master`` is used by
203 detached ``HEAD`` when west next updates this project.
209 Since the project has no ``path`` attribute, its ``name`` is used by
212 project.
215 ``https://github.com/user/project-three``.
220 The available project keys and their usage are in the following table.
232 - Mandatory; a unique name for the project. The name cannot be one of the
237 - Optional, an informational description of the project. Added in
243 If the project has a ``remote``, that remote's ``url-base`` will be
244 combined with the project's ``name`` (or ``repo-path``, if it has one)
247 If the project has a ``url``, that's the complete fetch URL for the
250 If the project has neither, the ``defaults`` section must specify a
251 ``remote``, which will be used as the project's remote. Otherwise,
256 ``url-base`` instead of the project's ``name`` to form its fetch URL.
266 A project revision can be a branch, tag, or SHA.
271 state of the project.
276 the project's ``name`` is used as a directory name.
284 - Optional. If given, a relative path to a YAML file within the project
285 which describes additional west commands provided by that project. This
295 - Optional, a list of groups the project belongs to. See
300 submodules`_ defined by the project. See
305 :ref:`west-project-userdata`.
322 The ``defaults`` subsection can provide default values for project
342 description: the first example project
343 path: extra/project-1
348 project.
352 url: https://github.com/user/project-three
365 - Optional. This will be used for a project's ``remote`` if it does not
369 - Optional. This will be used for a project's ``revision`` if it does
410 ``https://git.example.com/project-repo``, the manifest repository would
411 be cloned to the directory :file:`project-repo`.
414 - Optional. This is analogous to the same key in a project sequence
493 - Support for ``userdata:`` in ``projects:`` (:ref:`west-project-userdata`)
496 - Support for ``self: userdata:`` (:ref:`west-project-userdata`)
534 difference is that an inactive project is generally ignored by west. For
537 :ref:`west-manifest-import` in an inactive project will be ignored by west.
539 There are two ways to make a project inactive:
541 1. Using the ``manifest.project-filter`` configuration option. If a project is
543 a project inactive using its ``groups:`` are ignored. That is, if a regular
544 expression in ``manifest.project-filter`` applies to a project, the
545 project's groups have no effect on whether it is active or inactive.
549 2. Otherwise, if a project has groups, and they are all disabled, then the
550 project is inactive.
568 The next section introduces project groups. The following section describes
570 :ref:`west-project-group-examples`. Finally, :ref:`west-group-filter-imports`
583 - name: some-project
589 You can enable or disable project groups using ``group-filter``. Projects whose
591 ``manifest.project-filter`` configuration option, are inactive.
599 - name: project-1
602 - name: project-2
606 - name: project-3
610 - ``project-1``: one group, named ``groupA``
611 - ``project-2``: two groups, named ``groupB`` and ``groupC``
612 - ``project-3``: no groups
622 As a restriction, no project may use both ``import:`` and ``groups:``. (This
630 All project groups are enabled by default. You can enable or disable groups in
684 .. _west-project-group-examples:
689 This section contains example situations involving project groups and active
698 In all of the examples that follow, the ``manifest.project-filter`` option
730 is no way to make project ``baz`` inactive, since it has no groups.
760 Since ``groupA`` is disabled, project ``foo`` is inactive. Project ``bar`` is
966 - name: project-1
967 url: https://git.example.com/project-1
979 - name: project-2
980 url: https://git.example.com/project-2
981 - name: project-3
982 url: https://git.example.com/project-3
986 Only ``child`` and ``project-2`` are active in the resolved manifest.
992 Since ``project-1`` and ``project-3`` are in the ``unstable`` group and are not
1009 - name: project-1
1010 url: https://git.example.com/project-1
1022 - name: project-2
1023 url: https://git.example.com/project-2
1026 - name: project-3
1027 url: https://git.example.com/project-3
1031 Only the ``child``, ``project-1``, and ``project-3`` projects are active.
1035 ``project-1`` and ``project-3`` are in the ``unstable`` group, they are active.
1038 ``project-2`` is inactive.
1056 - name: project-1
1057 url: https://git.example.com/project-1
1069 - name: project-2
1070 url: https://git.example.com/project-2
1073 - name: project-3
1074 url: https://git.example.com/project-3
1084 Then only the ``child``, ``project-1``, and ``project-3`` projects are active.
1088 enabled. Since ``project-1`` and ``project-3`` are in the ``unstable`` group,
1091 The same configuration option disables the ``optional`` group, so ``project-2``
1104 submodules`_ configured in project's git repository. The ``submodules`` key can
1111 - name: some-project
1123 recursively update the project's Git submodules whenever it updates the project
1128 along with another project named ``bar`` in the same workspace.
1153 to its parent west project, as shown in the output of ``git submodule
1160 in sync, along with another project named ``bar`` in the same workspace.
1179 .. _west-project-userdata:
1189 It is meant for consumption by programs that require user-specific project
1231 ``project`` or ``self`` section attribute:
1237 - name: some-project
1243 containing your :file:`west.yml`. You can use a "project: ... import:" to load
1244 additional files defined in that project's Git history.
1253 other files. For example, a project named ``foo`` in your :file:`west.yml`
1295 from the :file:`west.yml` file in that project's root directory. If it's
1415 latest changes in the Zephyr project. The cost is that running ``west update``
1422 ``manifest-rev`` when importing from a project.
1470 With this manifest file, the project named ``hal_nordic``:
1477 In other words, when your top-level manifest defines a project, like
1509 - name: project-1
1512 - name: project-2
1520 - the contents of :file:`project-1/west.yml` at ``manifest-rev``, which points
1522 - any YAML files in the directory tree :file:`project-2/p2-manifests`
1553 the ``zephyr`` project. This example is contrived, but shows the idea.
1621 the project by the same name in :file:`zephyr/west.yml` is simply ignored. As
1669 - ``name-allowlist``: Optional. If present, a name or sequence of project names
1671 - ``path-allowlist``: Optional. If present, a path or sequence of project paths
1675 - ``name-blocklist``: Optional. Like ``name-allowlist``, but contains project
1677 - ``path-blocklist``: Optional. Like ``path-allowlist``, but contains project
1680 to the project's path in the workspace, as well as the paths of any imported
1688 Allowlists override blocklists if both are given. For example, if a project is
1751 If an allowlist had not been used, the ``lib`` project from the mainline
1882 For example, suppose you want to import this manifest from project ``foo``,
1883 adding this project and its projects ``bar`` and ``baz`` to your workspace:
1899 three project repositories in an :file:`external-code` subdirectory, like this:
2007 name), since that's the final project ``import``
2043 west will not import additional manifest data from that project. If
2086 example, if ``import-1`` contains a project named ``bar``, that is ignored,
2087 because the top-level :file:`west.yml` has already defined a project by that
2094 ``west update`` also fetches project data from the remote fetch URL and updates
2098 which defines a project ``P``, must be up to date in order for west to update
2100 ``manifest-rev`` in the ``baz`` project if :file:`baz/west.yml` defines ``P``,
2104 unrecognized project!
2107 in an imported manifest; you must update this project along with all the others
2110 By default, west won't fetch any project data over the network if a project's
2207 A "frozen" manifest is a manifest file where every project's revision is a SHA.