What happened to release v1.7.0
marcinmaruszewski opened this issue · 18 comments
Steps required to reproduce the problem
In my project, I have drupol/drupal-conventions 1.7.8 as a required dependency. Somewhere inside composer stuff, there was also the drupol/php-conventions 1.7.0 as a dependency. Right now when release 1.7.0 is gone I can't install my protect because it's missing.
Expected Result
The release 1.7.0 (it was the 921209a425cdfdbc7372ea7921211bf92b578312 git commit) exists and can be downloadable to my project.
Actual Result
- Installing drupol/php-conventions (1.7.0): Downloading (connecting...)Downloading (0%)
Failed to download drupol/php-conventions from dist: The "https://codeload.github.com/drupol/php-conventions/legacy.zip/921209a425cdfdbc7372ea7921211bf92b578312" file could not be downloaded (HTTP/1.1 404 Not Found)
Now trying to download from source
- Installing drupol/php-conventions (1.7.0): Failed to update https://github.com/drupol/php-conventions.git in cache, package installation for drupol/php-conventions might fail.
Cloning 921209a425 from cache
921209a425cdfdbc7372ea7921211bf92b578312 is gone (history was rewritten?)
I concur, the errors I was seeing looked a lot like the history for the project was rewritten. CI tasks which passed recently started failing with the following error while trying to install drupol/php-conventions (1.7.10 in my case, I think):
[RuntimeException]
Failed to execute git checkout 'e04a6c23cd03651860ac376fad3807cdf4808994' -- && git reset --hard 'e04a6c23cd03651860ac376fad3807cdf4808994' --
fatal: reference is not a tree: e04a6c23cd03651860ac376fad3807cdf4808994
@marcinmaruszewski if you blow away your local composer cache, does that help? (Guessing not since I'm seeing this fail in CI, where the composer cache wouldn't reliably exist anyway.)
Hi there,
For some reason, I had to rewrite the history indeed, and this is why you have the issue.
To fix this composer clear-cache is your friend.
Sorry about the that, it will not happen twice.
Feel free to reopen the issue if you feel that my answer doesn't help you.
Hey @xurizaemon and @drupol, thanks for the update. Unfortunately, none of the work you did helped. I still got an error with missing git commit.
As far as I can see git commit 921209a425cdfdbc7372ea7921211bf92b578312 was one of git release/tag. Right now this commit is missing and release/tag too - https://github.com/drupol/php-conventions/tags.
I see that you created the 1.7 branch, but it's not the case. What composer need is 1.7 release/tag.
To reproduce my issue please run the following commands:
# Install Drupal 8
composer create-project drupal/recommended-project drupol ^8
# Add drupol/drupal-conventions package
composer require drupol/drupal-conventions 1.7.8You will see that there is a grumphp version issue. The drupal-conventions 1.7.8 project requires ^0.16 version of grumphp and php-conventions 1.8.17 requires ^0.19.1 || ^0.20. I tried to use php-conventions 1.7.4, but there is sensiolabs/security-checker issue. One project requires ^4 and second ^6.
I think that in the current situation the best would be restoring missing drupol/php-conventions 1.7.0 tag/release and allow people to use it.
If you need any help with other issues I might gonna try to help you in some "free" time.
UPDATE:
Just to be clear. This issue is related only to D8. With D9 drupol/drupal-conventions including drupol/php-conventions works fine.
@drupol Thanks for the reply. I do think there might be more to do to resolve this fully (see comment above as well). FWIW Github won't let me re-open the issue, I think only you can do this.
To be honest the history rewrite raised suspicion for me - not because I don't trust you, but because rewriting history means that any trust grounded in community review and analysis of the project previously is reset; if inserting malware into an existing project (example), rewriting history would make the insertion much harder to identify and would be a reasonable tactic for an attacker in hijacking a tool. I hope this comes across OK in a Github issue - I have no reason to be suspicious of you personally!
I stress: I don't suspect you of a malware attack here, I'm just saying that was my first concern when I saw the history rewrite. Plenty of other scenarios come to mind too :)
The history rewrite will impact other users who have drupol/php-conventions integrated into their CI pipelines; you can probably expect to get "enquiries" in the issue queue until the history and previously available releases are restored.
I'm sorry to be saying this as I know you probably work hard to provide this tool and probably didn't make the decision to rewrite history lightly ...
Would it help for someone to dig a copy of the old history out of their composer cache and make it available for you?
EDIT: ah, composer cache doesn't have history, fair enough. Well, here's v1.7.1 (code, not the history / correct SHA) and I'm happy for folks to MR other tags to the same repo to help restore history if that's useful to you. I'm also happy to not do that if you do not want me to be helping restore history 😉
Just confirming that I'm also affected by this issue, my pipelines are broken and I can't get a set of installable packages together. Seems like we need 1.7.0 back for D8. (also, hi @xurizaemon ! Long time no see/chat)
@drupol Thanks for the reply. I do think there might be more to do to resolve this fully (see comment above as well). FWIW Github won't let me re-open the issue, I think only you can do this.
It's done.
To be honest the history rewrite raised suspicion for me - not because I don't trust you, but because rewriting history means that any trust grounded in community review and analysis of the project previously is reset; if inserting malware into an existing project (example), rewriting history would make the insertion much harder to identify and would be a reasonable tactic for an attacker in hijacking a tool. I hope this comes across OK in a Github issue - I have no reason to be suspicious of you personally!
I stress: I don't suspect you of a malware attack here, I'm just saying that was my first concern when I saw the history rewrite. Plenty of other scenarios come to mind too :)
I understand and no offense is taken. I know git, I know this would cause issues, but I wasn't expecting people from external to react in this issue. I'm quite surprised to see that drupol/php-conventions was used for other projects. I started that project mainly for my own packages.
The history rewrite will impact other users who have drupol/php-conventions integrated into their CI pipelines; you can probably expect to get "enquiries" in the issue queue until the history and previously available releases are restored.
I will restore it and find a solution to this, no worries.
I'm sorry to be saying this as I know you probably work hard to provide this tool and probably didn't make the decision to rewrite history lightly ...
Indeed that was a tough thing. I won't publish here the real reason, but yeah, this move was intentional.
Would it help for someone to dig a copy of the old history out of their composer cache and make it available for you?
Sure, anything will help.
EDIT: ah, composer cache doesn't have history, fair enough. Well, here's v1.7.1 (code, not the history / correct SHA) and I'm happy for folks to MR other tags to the same repo to help restore history if that's useful to you. I'm also happy to not do that if you do not want me to be helping restore history wink
No no restoring the tags is perfectly fine :-)
I will see if I can fix this by myself, I'm glad there are folks out there that might be able to test it.
However, I would prefer people to use the latest version of the branch 1.7, so I will see (thanks to the message above) why it's not working first and see how I can fix it.
Hey @xurizaemon and @drupol, thanks for the update. Unfortunately, none of the work you did helped. I still got an error with missing git commit.
As far as I can see git commit
921209a425cdfdbc7372ea7921211bf92b578312was one of git release/tag. Right now this commit is missing and release/tag too - https://github.com/drupol/php-conventions/tags.I see that you created the
1.7branch, but it's not the case. What composer need is1.7release/tag.To reproduce my issue please run the following commands:
# Install Drupal 8 composer create-project drupal/recommended-project drupol ^8 # Add drupol/drupal-conventions package composer require drupol/drupal-conventions 1.7.8You will see that there is a grumphp version issue. The
drupal-conventions 1.7.8project requires^0.16version of grumphp andphp-conventions 1.8.17requires^0.19.1 || ^0.20. I tried to usephp-conventions 1.7.4, but there issensiolabs/security-checkerissue. One project requires^4and second^6.I think that in the current situation the best would be restoring missing
drupol/php-conventions 1.7.0tag/release and allow people to use it.If you need any help with other issues I might gonna try to help you in some "free" time.
UPDATE:
Just to be clear. This issue is related only to D8. With D9drupol/drupal-conventionsincludingdrupol/php-conventionsworks fine.
Hi,
The 1.7 branch has always been there.
I tried to reproduce the issue locally, but I'm not able to: https://del.dog/latovuvyne.go
I also made a diff between https://github.com/xurizaemon/php-conventions/tree/xurizaemon-1.7.0 and drupol/php-conventions 1.7 branch, find it here: https://del.dog/hypobatyll.txt
I really hope this will clear people's fears about the history rewrite that was done.
In the meantime, I checked out drupol/drupal-conventions and noticed that the composer.json file was containing stuff that was already required by drupol/php-conventions. I removed the duplicates and tagged a new version: 1.7.12.
Let me know if that updated version fixes things for you.
Keeping this issue open until we find a working solution for you all.
Hey @drupol 👍
Here's an example composer.lock & composer.json which worked until the history rewrite landed. Hope this helps you reproduce / test the issue; you should be able to reproduce it by executing composer update --lock and see the dreaded message 😁
For the package of mine which was affected I'm in a situation to upgrade to the more recent grumphp & php-conventions, but that might not be the case for others so I think it's worth looking at restoring service for them if we can.
https://packagist.org/packages/drupol/php-conventions indicates there's a few packages depending on your package. You'd made it big and didn't even know ... what a pain 😁
More thoughts:
- You have a reason for rewriting history, so we know some sha/release combos can't/won't be republished.
- You might be able to republish 1.7.1 as e04a6c2 and so forth if that is a point in history before rewrite is required.
- Therefore it seems like a reasonably accessible solution for most folk is a 1.7.5 release to supercede existing 1.7 releases, allowing folks an upgrade path with minimal other changes. (I'm not a composer expert and when I tried to upgrade to 1.7.4, I ended up going all the way to 1.8 I think. So ... 🤷♂️)
- And maybe, if you can be bothered, republishing tags which precede any commit(s) you need to omit; then some folk don't need to upgrade at all.
- You probably can't solve the problem for everyone, and that's OK.
What a pain. Hey everyone, if you feel for @drupol's situation and want to help it get fixed, why not consider sponsoring or assisting in making the fix for others :)
Hi,
I will take care of this this evening.
Thanks for your message and sponsorship, it's very kind, i wasn't expecting this!
Thousand of thanks!
I ended up updating drupol/drupal-conventions to 1.7.12 and that has allowed me to use drupol/php-conventions 1.7.4. Worth noting that the initial problem meant I could not update drupal-conventions directly and instead had to remove it and reinstall.
I ended up updating
drupol/drupal-conventionsto 1.7.12 and that has allowed me to usedrupol/php-conventions1.7.4. Worth noting that the initial problem meant I could not update drupal-conventions directly and instead had to remove it and reinstall.
Great, can we consider this fixed for you then?
Issue fixed for:
@xurizaemon and @marcinmaruszewski I think it would also fix all the issue if you just use drupol/drupal-conventions 1.7.12, could you please confirm or infirm?
Yes, thanks - I'm happy having upgraded my project to drupol/php-conventions ^1.7 => ^1.8 which required phpro/grumphp ^0.18 => ^0.19.1 also. GrumPHP was the upgrade that required fiddling with config!
I don't know how to read the Packagist stats for the package but I'd estimate "at least a few dozen" projects are using this, not just the three of us who found this thread. My expectation is that there are other affected projects, but I could be wrong and you shouldn't spend too much time working for a horde I might be imagining!
According to Packagist, drupol/php-conventions has 27 821 installs (!!) and 52 dependents.
However, may I suggest we keep this issue open for 30 days, for visibility to others who might be in the same boat?
Yes, fixed for me. And thanks for the great packages - as an aside, I originally found your work through the note at the end of this article by Lullabot. It could explain the higher-than-expected usage!
Thanks for all your kind words, I wasn't expecting this outcome :-)
Let's keep this issue open for the time being, I guess it will be automatically closed by Github Settings app.
Feel free to let me know how I could improve it as well!
Yes, fixed for me. And thanks for the great packages - as an aside, I originally found your work through the note at the end of this article by Lullabot. It could explain the higher-than-expected usage!
Nice!
Thanks all for your comments and work. @drupol, I checked my previous command on clean D8 installation and it works like a charm. For my custom D8 installation with other dependencies, I had to update their version and after that, I'm also able to add drupol/drupal-conventions (and drupol/php-conventions as a dependency).
Thank you very much for your work!
Great new :-)
Thanks !!!
Dear all, can we close the issue ?