Missing Versions

[tschechniker]

Hi,

please check this package: https://packagist.org/packages/ezsystems/ezdemo-ls-extension

The tags are missing only the branches are available. Is this a packagist bug or something the maintainer can configure?

Thanks

Tobi

[stof]

this looks weird. Have you tried forcing an update of the package to see whether it finds the missing versions in this case ?
when I try to add the VCS repository directly, composer finds the tags as valid.

[tschechniker]

Hi,

i'm not the owner of this package. I just found this issue because i was unable to build. When i add this to my local satis repo it works. It's only broken in packagist.

[emodric]

The package was updated in the meantime to bring back the missing versions, but indeed, they were gone over the weekend.

[sabas]

Same for one of my packages, dev-master was downloading a version from some commits ago.
I forced update from the package page and it downloaded them.

[kdambekalns]

This might be related to #640 and #701 - and we see this recently as well, for some of our Neos packages.

We have changed the vendor name from typo3 to neos and as such our packages replace their "old typo3 self" in self.version now. We still have both variants of the package names at packagist, the typo3 ones being marked as abandoned, both using the same repo, those repos all having the auto-update hook.

Could that cause this? Don't know how updates requests from a repo that "feeds multiple packages" are handled…

One example where a manual update was needed (earlier today) to get the current commit hash listed for 3.0.x-dev on the neos/nodetypes package:

• https://packagist.org/packages/neos/nodetypes
• https://packagist.org/packages/typo3/neos-nodetypes

[hperrin]

I'm trying to update https://packagist.org/packages/sciactive/pnotify and nothing will get it to pull the tags. I've pushed a new tag up, and I've tried manually triggering an update.

[stof]

@hperrin the issue in your case is that older tags don't have a composer.json and so cannot be imported

[MatTheCat]

I don't know if it's related but the latest release of sonata-project/core-bundle is 3.3.0 on packagist and 3.4.0 on github.

(3.x-dev correctly pulls 3.4.0 though)

[stof]

@MatTheCat I don't think it is related. It think it is because the Packagist service hook does not get notified for new tags, only for new branch pushes. So if you push the release commit first, and then push the tag only later, Packagist will find the tag only the next time you trigger an update by doing a push (or by clicking on the button in the UI). And there has been no push on the repo after the release. See #522 (comment)

[ghost]

My package may be experiencing this issue or something similar. Rather than opening a separate issue perhaps adding information here will prove more valuable given the context of this thread.

Package: https://packagist.org/packages/comfusion/hyperdrive
Repo: https://github.com/comfusion/hyperdrive

Service hook enabled: Yes
Forced update: Yes
Has version field: No

Expected result:
Repo git tags crawled, parsed and made available on Packagist

Actual result:
Only dev-master is available on Packagist.

EDIT: My tags are following SemVer 2.0 specification. An example tag is v1.0.0-beta.0. I have tried deleting and adding my package a second time with the same results.

[stof]

@jhabdas here is something you can try to get more info:

• create a local project registering your repo directly as a VCS repo:

  {
    "repositories": [
      { "type": "vcs", "url": "https://github.com/comfusion/hyperdrive.git" },
      { "packagist.org": false }
    ],
    "require": {
      "comfusion/hyperdrive": "*"
    }
  }

• then run composer update -vvv

When doing this, composer will show you details about each tag in the VCS repo, telling you whether tags were skipped or no

[stof]

OK, actually, I understood your issue @jhabdas: none of your tags contain the composer.json file. So these versions don't have metadata.

[ghost]

none of your tags contain the composer.json file. So these versions don't have metadata.

excellent. thank you. that makes total sense. and I appreciate the snippet provided for later use in testing. cheers to you

[jyggen]

Seems like composer/composer has lost its tags now as well.

[stof]

@jyggen I think this is related to the github issue of today: github was sending webhooks properly (so packagist updates were triggered), but most API calls were failing, and so Packagist was considering the versions as deleted. The next update of the package should fix it.

[Ladsgroup]

@stof so you're saying without a new release packages will stay broken? this package is broken even though github has the proper tags

[ghost]

FWIW - Inferred tags are working just fine.

[stof]

@Ladsgroup no, things should be back on Packagist the next time packagist updates its metadata (i.e. either the next time you push a commit or the next time you click on the force update button).

and yeah, this probably happened for most packages which were updated during the time github was unreliable today.

[paulofreitas]

Edit: This was already force updated by the package owner and everything is working fine now. It's worth to note that this still was an issue for 2 days even the repository having new tags and untagged new commits. 👍

I'm having this issue (or similar) with sami/sami package - I'm not the owner.

The last 2 tags where pushed a day ago but Composer still don't see them as you can check on the package page: https://packagist.org/packages/sami/sami
It also says dev-master was last updated 2017-08-13 16:18 UTC but there was some commits pushed recently - it seems to be out of sync.

Should I report this somewhere else? Thank you.

[stof]

@paulofreitas contact the package maintainers so that they can check whether the packagist webhook is set properly on their github repo. Otherwise, Packagist will trigger its own update only once per week.

[Seldaek]

c22b770 hopefully fixes this by giving it some time before we delete a version in cases where a third party API is being dodgy.