Build Prod Site NG fails - error: No such remote 'composer'

We have this problem often, when Build Prod Site NG task fails.

...
 - Installing henrywhitaker3/healthchecks-io (v1.0.2): Extracting archive
  - Installing lakedrops/docker4drupal (v3.8.12): Cloning bdd1b6658d from cache
  - Upgrading lakedrops/drupal-environment (v3.1.19 => v3.1.20): Checking out b64dada206 from cache
    Update of lakedrops/drupal-environment failed
In Git.php line 471:
                                                                               
  Failed to execute (git rev-parse --quiet --verify 'b64dada206180ac3bf50fa45  
  76985d1602c84729^{commit}' || (git remote set-url composer -- '/root/.compo  
  ser/cache/vcs/https---gitlab.lakedrops.com-composer-plugin-drupal-environme  
  nt/' && git fetch composer && git fetch --tags composer)) && git remote set  
  -url composer -- 'https://gitlab.lakedrops.com/composer/plugin/drupal-envir  
  onment'                                                                      
                                                                               
  error: No such remote 'composer'                         
...

and it happens when the new version of lakedrops/drupal-environment is released (ie 3.1.20) but in our composer.lock we have an older version (ie 3.1.19). The only 'fix' I know is to upgrade lakedrops/drupal-environment locally to the newest version and then do deployment again.

Is there maybe any workaround/fix for this, or have I misconfigured something maybe?

Hmm, that's interesting. It certainly comes from composer require --update-no-dev --no-interaction --no-progress lakedrops/docker4drupal lakedrops/drupal-environment where we have to make sure that those packages are being installed even if not required by the project before then.

Looks like if those packages are already available, this attempts to do an update instead of just doing nothing, what was intended by this.

However, what makes me wondering even more so is why composer tries to install those packages from git rather than just the package. Do you probably have a composer setting to prefer installation from source?

added Doing label

mentioned in commit 12bab9ba

mentioned in commit 9156657e

This is strange, we just happened to see the same error. Looks like GitLab's packagist must have changed something which makes composer to install from source instead of the dist.

Found a way to circumvent this and updated the CI task accordingly.

@dejan-acolono please give it a try and let me know if yours is fixed now too.

@jurgenhaas I just experienced this problem again, so good chance to test your solution. And yes, your CI change fixed it. Thank you!

closed

That's good to hear, thanks @dejan-acolono for your feedback.