packagist icon indicating copy to clipboard operation
packagist copied to clipboard

Packagist not updating for deletions

Open mindplay-dk opened this issue 5 years ago • 6 comments

Looks like Packagist isn't picking up branch deletions today?

Under webhooks in GitHub I can see several deliveries were made today - for example:

image

I've made numerous changes to this repo today, of which adding tags did correctly generate new versions in Packagist - but several branch removals (all of which show webhook deliveries being made) did not.

I've marked with green here additions I made today, and removals in red:

image

I'll wait before I manually update, in case you want to investigate the data/logs. (Please let me know if I can safely do the manual update?)

mindplay-dk avatar Oct 17 '18 12:10 mindplay-dk

Anybody look into this?

This is still an issue.

I just removed an 0.3.2 branch from this repository today, and the dev-branch is still listed.

Again, I can look in the "webhook" tab in GitHub and see that it did post the deletion to Packagist:

{
  "ref": "refs/heads/0.3.2",
  "before": "65fa9c47c2fc44457b2acecc6632b8dbf1f3b0ab",
  "after": "0000000000000000000000000000000000000000",
  "created": false,
  "deleted": true,
  ...

As well as Packagist responding with:

{"status":"success","jobs":["a857599b4ea54c4ff7167c6d8b59d3463f351607"]}

This webhook dispatch was timestamped at 2018-10-23 09:32:01 +0200.

mindplay-dk avatar Oct 23 '18 07:10 mindplay-dk

Would you mind if I go ahead and manually clean up my repositories, or do you need more time to look at the current state to figure out why these updates aren't happening?

mindplay-dk avatar Oct 30 '18 10:10 mindplay-dk

Job 0c0f86d5aaa61ea0f600c73f3a54471c6a2357db started at 2018-10-23 07:31:48 +0000 and completed at 2018-10-23 07:31:51 +0000 and contained this in the output:

Reading composer.json of <span style="color:green;">mindplay/testies</span> (<span style="color:yellow;">0.3.2</span>)
Importing branch 0.3.2 (0.3.2.x-dev)

So it still existed..

Then job a857599b4ea54c4ff7167c6d8b59d3463f351607 started at 2018-10-23 07:32:01 +0000 and completed at 2018-10-23 07:32:09 +0000 so that matches with the hook delivery you posted. That one's output did not contain the 0.3.2 branch though, but that only means https://github.com/composer/packagist/blob/master/src/Packagist/WebBundle/Package/Updater.php#L234-L238 triggers and marks the version to be deleted after a day.. Now I ran an update earlier and that indeed cleared up the version.

So all works as expected, but it's not ideal when you're micro-managing things. I am not sure how we could improve this.. The point was to avoid wiping out all versions of a package in case any temporary outage returns no version (which definitely happened in the past occasionally).

Seldaek avatar Oct 30 '18 20:10 Seldaek

@Seldaek I think a solution could be to inspect the payload of the github webhook in detail instead of just using it as a trigger for a full processing of the package. Receiving a webhook telling the branch was deleted would allow for immediate removal of that version, as it is clear it is not an outage. That would force making Packagist more integrated with the Github API though. But it might make sense given the amount of packages hosted there.

stof avatar Oct 31 '18 10:10 stof

I think a solution could be to inspect the payload of the github webhook in detail instead of just using it as a trigger for a full processing of the package

Or offer more detailed webhooks and configure them automatically at GitHub like you do anyway.

That way less coupling to GitHub, right?

And probably also cheaper - incremental rather than full updates.

mindplay-dk avatar Nov 02 '18 11:11 mindplay-dk

any news?

eisberg avatar Dec 22 '21 10:12 eisberg