| Gábor Hojtsy (he/him) | Based on #2608062: [META] Requirements for tagging Drupal 9.0.0-alpha1 it looks like there is one requirement left |
| Gábor Hojtsy (he/him) | #3074993: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates |
| Gábor Hojtsy (he/him) | there are also 2 should haves |
| Gábor Hojtsy (he/him) | #3091418: Update composer dependencies on 9.0.x |
| Gábor Hojtsy (he/him) | and #3075954: Remove duplicate scaffold files |
| Gábor Hojtsy (he/him) | help would be welcome on updating composer dependencies |
| Gábor Hojtsy (he/him) | @greg.1.anderson may have an update on the scaffold files issue :slightly_smiling_face: |
| Gábor Hojtsy (he/him) | it seems to be postponed on the tarball building issue which is already happening AFAIK(?) but not entirely reflected on the issue |
| tedbow | The first I am working and I think is getting pretty close. Working with drumm to determine what we need the /current XML feed. |
| greg.1.anderson | Yeah, it's just tarball creation that's holding up removing the duplicate scaffold files in Drupal 9. That work is in progress right now (cc @mixologic) |
| mixologic | Yep. still feeling like I've got 5 rivers converging on my floodplains. |
| greg.1.anderson | lmk if there are any tools / scripts / PRs I could provide to help knock out one of your todos |
| mixologic | @greg.1.anderson one thing that could help is figuring out what I need to do in drupalci to make testing against 8.8.0 work. Basically, git clone drupal;composer require some module;is what is supposed to work, but due to the composer.lock being out of sync with composer.json things break. Im pretty sure it might just be composer update --lock or something simple in between. Ideally something that can run always that would noop in most cases. |
| greg.1.anderson | @mixologic Why is composer.lock out of sync with composer.json? What error is returned, at what stage? |
| mixologic | This was the issue where the 8.8.0 tag still has 8.8.x-dev in the lockfile for drupal/core (the lockfile in the git repo) |
| mixologic | https://www.drupal.org/pift-ci-job/1498058 is an example of a contrib test that fails |
| mixologic | https://dispatcher.drupalci.org/job/drupal_contrib/94054/console |
| greg.1.anderson | Ah, so you're doing a git clone of the tag, and then the composer require of the module fails? |
| mixologic | yes. as that how we run contrib module tests. |
| mixologic | But the tag is angry about the lock file. |
| mixologic | 14:20:06 Problem 114:20:06 - Conclusion: don't install drupal/core 8.8.014:20:06 - Can only install one of: drupal/core[8.8.0, 8.8.x-dev].14:20:06 - Can only install one of: drupal/core[8.8.x-dev, 8.8.0].14:20:06 - Can only install one of: drupal/core[8.8.0, 8.8.x-dev].14:20:06 - Installation request for drupal/core 8.8.0 -> satisfiable by drupal/core[8.8.0].14:20:06 - Installation request for drupal/core (locked at 8.8.x-dev, required as self.version) -> satisfiable by drupal/core[8.8.x-dev]. |
| greg.1.anderson | Yeah, I see that now. Provide a link to the code that's running that step? |
| mixologic | Its low hanging, probably just composer lock update before requiring the contrib project. |
| mixologic | This is the plugin that does the core_install |
| mixologic | https://git.drupalcode.org/project/drupalci_testbot/blob/dev/src/DrupalC... |
| greg.1.anderson | To me it looks like installed.json somehow got Drupal 8.8.0 stable, but composer.lock has 8.8.x-dev. Maybe |
| mixologic | but Im mostly just hoping to lateral pass the composer commands |
| mixologic | yeah, I think thats exactly the issue. |
| mixologic | But yeah, dont sweat making a patch for drupalci, mostly just see if you can clone/doesomething/require contrib |
| greg.1.anderson | Yeah I can do that; I just need to reproduce the setup steps. |
| mixologic | check the console logs: https://dispatcher.drupalci.org/job/drupal_contrib/94054/console |
| greg.1.anderson | Can I browse the contents of packages.drupal.org online if I want to see a composer.json w/out installing the module? |
| mixologic | Not really. But you can do it with composer show -a drupal/projectname:version |
| mixologic | but that will also download the whole metadata into your cache where you can see the raw json |
| mixologic | i.e. for that contrib test I linked to:composer -vvv show -a drupal/minisite |
| mixologic | I seeDownloading https://packages.drupal.org/8/drupal/minisite%24c5d727ec199da9c3573cd920... the output |
| mixologic | oh, actuallyWriting /Users/ryan/.composer/cache/repo/https---packages.drupal.org-8/provider-drupal$minisite.json into cache |
| greg.1.anderson | Yeah so it looks like module foo requires drupal/core at some stable version |
| greg.1.anderson | That's where the conflict is coming in. |
| greg.1.anderson | I am guessing that when we test modules, we always want to do so against a stable drupal |
| greg.1.anderson | and the only problem is that the stable Drupal has a dev drupal/core in its lock file. |
| greg.1.anderson | Ultimately, I guess, fix the lock file. |
| Gábor Hojtsy (he/him) | proposed by @mglaman |
| mglaman | phpstan 0.12 came out which changes a lot. phpstan is now a phar by default, which fixes autoloading collisions! |
| mglaman | but it broke things. |
| mglaman | Immediate goal is to point out phpstan-drupal as 0.11.0 only - https://github.com/mglaman/phpstan-drupal/pull/95This test is failing, but maybe I just need to merge and see? |
| mglaman | Issues for 0.12.0 support:phpstan-drupal https://github.com/mglaman/phpstan-drupal/issues/91drupal-check:https://github.com/mglaman/drupal-check/issues/117 |
| mglaman | the conflict identification is for #3099396: PHPStan job must identify it conflicts with 0.12, so the deprecation reports can keep running |
| mglaman | @Gábor Hojtsy (he/him) @mixologic the conflicts in PR#95 for phpstan-drupal seem to make sense, but are failing in the test. I wonder if its just due to wonky testing of a local sourced path? maybe just merge and test somewhere |
| Gábor Hojtsy (he/him) | @mglaman I will need to update https://git.drupalcode.org/project/upgrade_status/blob/8.x-1.x/composer.... too with similar :slightly_smiling_face: |
| Gábor Hojtsy (he/him) | so that should serve as testing also :slightly_smiling_face: |
| mglaman | well, really if the conflict is in phpstan-drupal that should inherit the same conflict? or does it not quite work that way |
| Gábor Hojtsy (he/him) | possibly yes |
| mglaman | One thing I was wondering is if conflicts are treated like require-dev, only on the root of the project :confused:. |
| Gábor Hojtsy (he/him) | I’d love to move to require drupal-check and exec() it eventually, see #3085327: PHP and cURL error 7: Failed to connect, use exec() instead that would clear out a lot of the syncing needs between the tools |
| mixologic | This feels like its 4 problems. |
| mixologic | drupal-check needs fixing |
| mixologic | 2. upgrade_status needs fixing |
| mixologic | 3. drupalci phpstan build step needs fixing |
| mixologic | and 4. static analysis all projects needs fixing. |
| mglaman | (it is 4 problems) |
| mixologic | and Im unsure what it is we need to do |
| mglaman | one quick-fix is identifying the conflict, that solves 3&4 |
| mglaman | so deprecations-rules stops trying to pull 0.12 |
| mixologic | what requires deprecations-rules ? |
| mglaman | that's what groks @deprecated, but upgrae_status and the build step composer require it |
| mglaman | the build step runs composer require phpstan/phpstan-deprecation-rules after it requires phpstan-drupal |
| mixologic | where did the requirement for^0.12.0 come from? |
| mglaman | that's the Q, composer just picks it |
| mglaman | @mixologic see https://circleci.com/gh/mglaman/phpstan-drupal/262the composer.json just had ^0.11.0 |
| mglaman | for some reason Composer flips a table |
| mixologic | gotcha so its phpstan-drupal thats getting a higher version of phpstan |
| mixologic | which is probably because this doesnt have 3 version places: https://github.com/mglaman/phpstan-drupal/blob/master/composer.json#L14 |
| mixologic | Im not entirely sure, but it might work if its ^0.11.0 |
| mglaman | @mixologic which I changed in the PR to ~0.11.0 |
| mixologic | ah. but still breaks? |
| mglaman | https://github.com/mglaman/phpstan-drupal/pull/95, see builds |
| mglaman | https://circleci.com/gh/mglaman/phpstan-drupal/264 |
| mglaman | Composer is still pulling phpstan/phpstan-deprecation-rules 0.12.0 and blowing my mind |
| mglaman | but it's also pulling the package from a symlink, and I feel like that randomly breaks some metadata shit |
| mglaman | so I'm tempted to just merge as is and tag a release and see |
| mixologic | yeah, I think thats something to do with how composer behaves with regards to dev releases. |
| mglaman | When does the phpstan job build? |
| Gábor Hojtsy (he/him) | @mglaman the all contrib one weekly, the contrib individual ones anytime they run |
| mixologic | so for both drupalci and the phpstan job, I can just add phpstan/phpstan:0.11 to the require and force it to be that version |
| mixologic | it runs once a week or whenever I push the button (edited) |
| mglaman | can we try pushing the button after I tag a release? see if the conflict statements worked |
| mglaman | I was hoping this would work so we don't have workarounds in drupalci-land |
| mixologic | Do you want to do that? I was just going to shoehorn in this for now:-composer require mglaman/phpstan-drupal phpstan/phpstan-deprecation-rules --dev+composer require mglaman/phpstan-drupal phpstan/phpstan-deprecation-rules phpstan/phpstan:0.11.19 --dev |
