Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removed bad line #195

Merged
merged 1 commit into from
Dec 28, 2019
Merged

Removed bad line #195

merged 1 commit into from
Dec 28, 2019

Conversation

GrahamCampbell
Copy link
Contributor

No description provided.

@jaapio jaapio merged commit 4bccbd5 into phpDocumentor:release/4.x Dec 28, 2019
@jaapio
Copy link
Member

jaapio commented Dec 28, 2019

Thanks again!

@GrahamCampbell GrahamCampbell deleted the patch-1 branch December 28, 2019 18:28
@GrahamCampbell
Copy link
Contributor Author

I think the failing build must be somehow related to cache? Is there a way to delete all travis' caches from the UI?

@jaapio
Copy link
Member

jaapio commented Dec 28, 2019

removed all cache and restarted the build

@GrahamCampbell
Copy link
Contributor Author

Did that restart work?

@GrahamCampbell
Copy link
Contributor Author

It doesn't seem to have re-run>

@jaapio
Copy link
Member

jaapio commented Dec 28, 2019

 Problem 1

    - Installation request for phpspec/prophecy 1.10.1 -> satisfiable by phpspec/prophecy[1.10.1].

    - phpspec/prophecy 1.10.1 requires phpdocumentor/reflection-docblock ^2.0|^3.0.2|^4.0|^5.0 -> no matching package found.

  Problem 2

    - phpspec/prophecy 1.10.1 requires phpdocumentor/reflection-docblock ^2.0|^3.0.2|^4.0|^5.0 -> no matching package found.

    - phpunit/phpunit 6.5.14 requires phpspec/prophecy ^1.7 -> satisfiable by phpspec/prophecy[1.10.1].

    - Installation request for phpunit/phpunit 6.5.14 -> satisfiable by phpunit/phpunit[6.5.14].

this is not cache, the issue is that we are a dependency of phpunit. Which is causing issues as always. This is why we were very happy with the scoped phar of phpunit v8.

@GrahamCampbell
Copy link
Contributor Author

It doesn't make sense, though. Composer resolves fine on my machine, and on the PR build.

@jaapio
Copy link
Member

jaapio commented Dec 28, 2019

there is one main difference, travis is building a commit and not a branch. So what it does is executing the clone command and after that is does:
git checkout -qf 149120ee8fe5ab43fdb707144e56df96321591d9

This brings git into a detached mode, so composer does not recognize the package or any alias you are configuring. So it will fail on your machine as well when you execute that command before the composer install. :-)

@GrahamCampbell
Copy link
Contributor Author

Well... we could fix that :P ...

@GrahamCampbell
Copy link
Contributor Author

Give me a sec

@jaapio
Copy link
Member

jaapio commented Dec 28, 2019

sure, by creating a tag like git tag 4.3.9999 ;-)

@GrahamCampbell
Copy link
Contributor Author

No, I was thinking... just get travis to actually check out the branch we are on, then hard reset to the place we need to be at.

@GrahamCampbell
Copy link
Contributor Author

Actually, I think we can just set COMPOSER_ROOT_VERSION.

@GrahamCampbell
Copy link
Contributor Author

I am rather hopeful this will work: #196.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants