Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

west update: remotes are not imported from submanifests

See original GitHub issue

We are migrating to west to manage our (private) project dependencies/submodules, but we are facing some difficulties integrating west in our GitLab CI workflow: we need to use HTTPS remotes for CI pipelines (for authentication purposes), but we would like to keep using SSH locally.

It would be nice if remotes could be overridden way as projects, e.g. with a 00-ci.yml sub-manifest, included only when needed. For example:

# west.yml
manifest:
    version: "0.10"
    remotes:
        - name: origin
          url-base: git@gitlab.com:group
    defaults:
        remote: oi-origin
    projects:
        - name: moduleA
          path: modules/moduleA
          repo-path: moduleA.git
self:
    import: submanifests

# submanifests/00-ci.yml
manifest:
    version: "0.10"
    remotes:
        - name: origin
          url-base: https://gitlab.com/group

In this example, the repo-path for moduleA would resolve to:

git@gitlab.com:group/moduleA.git for local workflows
https://gitlab.com/group/moduleA.git for CI workflows

At the current stage, including the 00-ci.yml file has no effect on the remote’s base-url (always resolved to SSH). The only solutions we could find are:

Re-declaring all the projects within the 00-ci.yml manifest, with a non-negligible duplication cost.
Perform a manual substitution (sed) of the remote’s URL before running west update

Issue Analytics

State:
Created 2 years ago
Comments:9 (2 by maintainers)

Top GitHub Comments

1reaction

mbolivar-nordiccommented, Feb 2, 2022

Hi and thanks for filing an issue.

The decision not to inherit remotes is a deliberate design choice in west. The reason it is done this way is that you can specify a project’s fetch URL in the following different ways: 1. by explicit remote, 2. by default remote, 3. by explicit url. Reference material is here: https://docs.zephyrproject.org/latest/guides/west/manifest.html#projects

I thought about how to treat remotes as first class objects you can inherit from sub-manifests that you import. It gets really messy and I couldn’t come up with a clean set of rules for it. So the decision I made is that when you import a project, its fetch URL is completely resolved at import time. You can override the project definition in your parent manifest, but then you have to override everything about it. This leads to a bit more typing for sure, but I think the resulting mental model is cleaner.

0reactions

marc-hbcommented, Dec 21, 2022

Thanks to recent #615 I just discovered that 2018’s and still open #28 discussed the same topic

Top Results From Across the Web

West Manifests

If given, this is concatenated on to the remote's url-base instead of the project's name to form its fetch URL. Projects may not...

West Manifests — Zephyr Project Documentation

If import is true as a projects attribute, west imports projects from the west.yml file in that project's root directory. If it's false...

west manifest project uses wrong path · Issue #572

The west.manifest uses the self::path and not the actual path given by west config manifest.path. If a project is manually cloned, ...

SDK Setup (Windows) west update dies

Key 'remote' was not defined. Path: '/remotes/8'. I 'restored' the west.yml and ran update, it worked. from my west.yml.mod

conftest.create_repo Example - Program Talk

def test_import_project_submanifest_commands(manifest_repo): # If a project has no west-commands, but an imported manifest # inside it defines some, ...