"repositories" support only https repositories

[Mitiaj]

This is all valid composer repository annotations according to official composer documentation and it works in heroku/buildpacks:20. We have been migrating recently to heroku/builder:20/22 and we cant overcome this issue.

Only first one with https is not producing crash.

    "repositories": [
       {
            "type": "vcs",
            "url": "https://gitlab.com/devops59460/packages/independent/core.git"
        },
        {
            "type": "path",
            "url": "./../code/stripe"
        },
        {
            "type": "vcs",
            "url": "[email protected]:devops59460/packages/independent/api-client.git"
        }
    ]

Build output log:

    ===> ANALYZING
Image with name "tmp-cnb-image-6784113612" not found
===> DETECTING
heroku/php      0.1.2
heroku/procfile 3.1.1
===> RESTORING
===> BUILDING
[Error: Failed to parse 'composer.lock']
There was an error parsing the lock file; it must be a valid
file generated by Composer and be in an up-to-date state.
Check below for any parse errors and address them if necessary.
The parsed contents were invalid.
Details: invalid value: string "[email protected]:devops59460/packages/independent/api-client.git", expected relative URL without a base at line [114](https://gitlab.com/devops59460/services/stripe-recurring-engine/backend-api/-/jobs/6784113612#L114)3 column 9
You most likely created or edited the file by hand, or a merge
conflict was not resolved properly, resulting in a syntax error
in the file. Refer to the docs for information on re-generating
the lock file: https://getcomposer.org/doc/01-basic-usage.md
Please perform the following steps locally on your computer to
resolve this issue before attempting another deploy:
1) Run 'composer update' to re-generate the lock file
2) stage the lock file changes using 'git add'
3) commit the change using 'git commit'
You can run 'composer validate' locally on your computer for
further diagnosis. Remember to also always keep your lock file
up to date with any changes according to the instructions at
https://getcomposer.org/doc/01-basic-usage.md
If you believe this message to be in error, please report it.
ERROR: failed to build: exit status 1

Another one:

[Error: Failed to parse 'composer.lock']
There was an error parsing the lock file; it must be a valid
file generated by Composer and be in an up-to-date state.
Check below for any parse errors and address them if necessary.
The parsed contents were invalid.
Details: invalid value: string "code/stripe", expected relative URL without a base at line 45 column 9

[ngatti-tmm]

Same issue here, but it's strange, with only one repository it works ok. When I add a second it fails. For example:

    "repositories": {
        "my-yoast": {
            "type": "composer",
            "url": "https://my.yoast.com/packages/"
        },
        "wpackagist": {
            "type": "composer",
            "url": "https://wpackagist.org"
        }
    }

It works correctly using composer CLI, but when running pack build reports the same parse error

[pixelart7]

Having a similar issue here, looks like it's having a problem with a "type: git" packages as well.

[Error: Failed to parse 'composer.lock']
There was an error parsing the lock file; it must be a valid
file generated by Composer and be in an up-to-date state.

Check below for any parse errors and address them if necessary.

The parsed contents were invalid.

Details: invalid value: string "[email protected]:hpierce1102/ClassFinder.git", expected relative URL without a base at line 1243 column 9

Running composer validate return no issues with the file, and using composer install in local machine does work correctly.
Version used: heroku/builder:22 with heroku/php:0.1.2

[dzuelke]

The culprit is the url crate, it cannot parse these URLs, see e.g. rust-lang/cargo#12295 or rust-lang/cargo#12404.

Best option is to parse as a string rather than a URL

[dzuelke]

@ngatti-tmm it should work when you make it an array of objects instead and drop the keys.

The reason is that otherwise, you do not get order guarantees, and order matters greatly for package lookup when Composer solves dependencies across repositories.

I'll see if there is a way to have a more ergonomic error message for exactly this case.

[ngatti-tmm]

@ngatti-tmm it should work when you make it an array of objects instead and drop the keys.

Hi! thanks for the info, but I tried with

[
  {
    "type": "composer",
    "url": "https://my.yoast.com/packages/"
  },
  {
    "type": "composer",
    "url": "https://wpackagist.org"
  }
]

And it failed, but now with a strange composer.lock error:

===> BUILDING
Timer: Builder started at 2024-06-03T19:36:07Z
target distro name/version labels not found, reading /etc/os-release file
Running build for buildpack heroku/[email protected]
Looking up buildpack
Finding plan
Creating plan directory
Preparing paths
Running build command
Timer: Builder ran for 14.965122ms and ended at 2024-06-03T19:36:07Z
ERROR: failed to build: exit status 1
[Error: Failed to parse 'composer.lock']
There was an error parsing the lock file; it must be a valid
file generated by Composer and be in an up-to-date state.
Check below for any parse errors and address them if necessary.
The parsed contents were invalid.
Details: invalid value: string "[email protected]:Yoast-dist/wordpress-seo-premium.git", expected relative URL without a base at line 7060 column 9

But composer install, validate and update they all work without any issues on other environments, also it worked with the older image.

[dzuelke]

Yup, now you're hitting the "real" issue described at the very top, @ngatti-tmm :)

Working on it!

[dzuelke]

As a workaround, you should be able to use ssh://[email protected]:22/Yoast-dist/wordpress-seo-premium.git, @ngatti-tmm.

No workaround at this time for relative paths, though.