renovate
renovate copied to clipboard
Artifact update problem composer.json
How are you running Renovate?
Mend Renovate hosted app on github.com
If you're self-hosting Renovate, tell us what version of Renovate you run.
No response
If you're self-hosting Renovate, select which platform you are using.
No response
If you're self-hosting Renovate, tell us what version of the platform you run.
No response
Was this something which used to work for you, and then stopped?
It used to work, and then stopped
Describe the bug
In 1 of the private repos, the lockFileMaintenance
run for composer dependencies fails.
It is working in other private repos on the same org.
It was working in the past (16th of August), and then stopped working after that (6th of September)
Relevant debug logs
Logs
WARN: artifactErrors(branch="renovate/lock-file-maintenance")
{
"artifactErrors": [
{
"lockFile": "composer.lock",
"stderr": "Command failed: docker run --rm --name=renovate_php --label=renovate_child -v \"/mnt/renovate/gh/RingierIMU/ritdu-horizon\":\"/mnt/renovate/gh/RingierIMU/ritdu-horizon\" -v \"/tmp/renovate-cache\":\"/tmp/renovate-cache\" -v \"/tmp/containerbase\":\"/tmp/containerbase\" -e COMPOSER_CACHE_DIR -e COMPOSER_AUTH -e BUILDPACK_CACHE_DIR -w \"/mnt/renovate/gh/RingierIMU/ritdu-horizon\" docker.io/renovate/php:8.0.12 bash -l -c \"install-tool composer 2.4.1 && composer update --ignore-platform-req='ext-*' --ignore-platform-req='lib-*' --no-ansi --no-interaction --no-scripts --no-autoloader --no-plugins\"\nLoading composer repositories with package information\n\nIn AuthHelper.php line 130:\n \n Could not authenticate against github.com \n \n\nupdate [--with WITH] [--prefer-source] [--prefer-dist] [--prefer-install PREFER-INSTALL] [--dry-run] [--dev] [--no-dev] [--lock] [--no-install] [--no-audit] [--audit-format AUDIT-FORMAT] [--no-autoloader] [--no-suggest] [--no-progress] [-w|--with-dependencies] [-W|--with-all-dependencies] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--apcu-autoloader-prefix APCU-AUTOLOADER-PREFIX] [--ignore-platform-req IGNORE-PLATFORM-REQ] [--ignore-platform-reqs] [--prefer-stable] [--prefer-lowest] [-i|--interactive] [--root-reqs] [--] [<packages>...]\n\n"
}
]
}
Have you created a minimal reproduction repository?
No reproduction repository
@patrickblackjr Your log isn't helpful. Please find the real failed exec message and past it here.
@matthewnessworthy How do you configure authentication for the private composer dependency?
probably a regression of
- https://github.com/renovatebot/renovate/pull/16193
@viceice I have hostRules for our private packages, see below
"hostRules": [
{
"matchHost": "some laravel packagist repo",
"hostType": "packagist",
"encrypted": {
"username": "<encoded>",
"password": "<encoded>"
}
},
{
"matchHost": "old toran instance url",
"hostType": "packagist",
"encrypted": {
"username": "<encoded>",
"password": "<encoded>"
}
},
{
"hostType": "npm",
"matchHost": "registry.npmjs.org",
"encrypted": {
"token": "<encoded>"
}
}
]
}
``
@rarkins it seems we need to revert #16193, as it has broken the app composer credentials
Ok
We are running into the same problem (using Github hosted app). Is it possible to revert https://github.com/renovatebot/renovate/pull/16193, as a quick-fix?
Reverting in #17961 but need to understand if this is something I can fix in the hosted app config alone, or needs a code change
:tada: This issue has been resolved in version 32.202.6 :tada:
The release is available on:
- GitHub release
-
32.202.6
Your semantic-release bot :package::rocket:
@rarkins Are you really shure that #17961 caused this issue. When I'm looking at the hostRules above I don't see how de changes could affect them.
The change could only affect rules with "hostType": "github",
that PR affects GitHub token handling
I've put the revert live in the app just now, let's see if it resolves the problem for @matthewnessworthy and @annuh. If so then next step is to work out why and how to resolve
@rarkins I just triggered the lock file maintenance option from the GitHub issue and the composer.lock was successfully updated. It is working as expected.
@rarkins yes, with v32.204.4
Renovate can create/update PR's again in our project. So reverting https://github.com/renovatebot/renovate/pull/17961 fixed it!
@annuh are you self hosting?
@annuh are you self hosting?
No, I'm using the Github hosted app.
Ok thank's for the information, I will try to make sense of this tommorow
@matthewnessworthy Sorry to bother you but it would help very mutch to understand what went wrong if you could provide the exact error you had when updating artifacts.
@rarkins The only thing the reverted pr changed is for composer to extract github token from git-tags;
host rules. Maybe this rule superseed the packagist rule when composer try to fetch private repositories.
In a case like that composer auth.json would look like :
{
"github-oauth": {
"github.com": "TOKEN from git-tags hostRule"
},
"http-basic": {
"some laravel packagist repo" : {username: "<decoded>", password: "<decoded>"},
"old toran instance url" : {username: "<decoded>", password: "<decoded>"},
},
}
i think this GitHub token handling changes are the issue
https://github.com/renovatebot/renovate/pull/17961/files#diff-2a044cab400c76ce5b5528934ee240097f181956e47690b01c73c09605b6296cL38
i think this GitHub token handling changes are the issue
https://github.com/renovatebot/renovate/pull/17961/files#diff-2a044cab400c76ce5b5528934ee240097f181956e47690b01c73c09605b6296cL38
Indeed, it could be either the check for ghp_
prefix or the .replace('x-access-token:', '')
Is it possible that some peoples have old configurations with x-access-token:
in their github hostRule ?
I can make a new pull request with the replace
Is it possible that some peoples have old configurations with
x-access-token:
in their github hostRule ?
We are not using the x-access-token
configuration. 😬
the hosted app is using those, as it's working as GitHub app.
the hosted app is using those, as it's working as GitHub app.
So it's good news, we hava a solution
FYI we're going to have another shot at this in #18004 thanks to @etremblay
If anyone notices any problems again soon, please don't hesitate to create a new issue