Apparently the Vagrant puppet code limits updates to once per day:

exec { 'Daily apt-get update':
    command  => '/bin/date > /etc/apt/.update',
    schedule => 'daily',
}
exec { 'apt-get update':
    command     => '/usr/bin/apt-get update',
    timeout     => 240,
    returns     => [ 0, 100 ],
    refreshonly => true,
    subscribe   => File['/etc/apt/.update'],
}

(09ddf4ac1) so I'm guessing you ran vagrant provision less then 24 hours before pulling the new MediaWiki code, and then the next provisioning skipped this step. (Otherwise, Vagrant uses the php7.2 package from apt.wikimedia.org so it will always match the version used in production.)

Not sure how to handle this. We could add some kind of manual override (just needs to delete /etc/apt/.update) but it would be obscure enough that it probably wouldn't really help. @bd808 any thoughts?

In T246300#5922425, @Tgr wrote:

Apparently the Vagrant puppet code limits updates to once per day:

This is a feature that was added expressly because people were upset that originally each vagrant provision run included an apt-get update step which can take a long time depending on network connectivity and latency to apt.wikimedia.org.

Not sure how to handle this. We could add some kind of manual override (just needs to delete /etc/apt/.update) but it would be obscure enough that it probably wouldn't really help. @bd808 any thoughts?

The manual override option is actually exactly what @Catrope reported doing, ssh into the VM and do manual updates. I really don't have any better idea as the concept of "ensure that a recent enough PHP version is installed so that MediaWiki doesn't break" is a moving target that can change with a single git commit in an unrelated repository and honestly is completely dependent on what branch and revision is active at any point.

I guess we could parse the required PHP version out of composer.json or extension.json and splice that into the content of /etc/apt/.update. Not sure if it's worth the complexity though.