I recently was asked whether JUnitDiff was available as a PHAR. Up to that point I hadn’t actually thought about it. But it made sense. The only thing I was sure about was that I didn’t want to have to think about it when doing a release. So the solution should fit nice into the build-chain.
A few weeks ago I updated our gitlab-installation to the glorious, shiny and new 8.12.6! Awesome new stuff! It had only one drawback. We couldn’t clone repos via HTTP(S) anymore.
It wasn’t that much of a drawback at the time but then we wanted to use the included CI-stuff. And that – you guessed it already – only works with cloning or fetching the repo via HTTP(S).
Continue reading Fixing issues with cloning via HTTPS on GitLab
The other day I wanted to have an automated deployment for a sideproject (callingallpapers.com) of mine. I wanted to be able to merge a PullRequest on github and have Travis-CI deploy the merged files via rsync after all tests succeed. Easy thing I thought, I can’t be the first one attempting that. Looked like I was at least the first one writing about it… Continue reading Automated deploy from travis-ci via ssh
Whether to commit a
composer.lock-file to a repository or not seems to be a somewhat religious decision. Either you follow Raphael Dohms and commit your lock-file or you follow Marco Pivetta and you don’t.
But I think the truth is somewhat in between.
Recently I decided to create a badge for Badge Poser that shows whether the lock-file is commited or not. It’s something you can see easily from the repo but hey, it’s a fun project!
And instantly I stumbled over a commited lock-file! Because as it seems, commited composer.lock-files can be a blessing or a curse. What happened? I thought – as the project commited their composer.lock-file – it would be a good idea to run a
composer install instead of a
composer update. After all I should be left with a working installation after the install-command. That’s why we would commit the lock-file in the first place, isn’t it?
But as it turned out, the composer.lock-file was created some time ago with a now hopelessly outdated PHP-version. I have PHP 7 running on my machine, but the composer.lock-file obviously was created using something like PHP 5.3 or PHP 5.4. So instead of getting a running version of the project, I got composer yelling at me that it can’t resolve an installable version of my lock file. Hm.
So it looks like it’s dependent on the PHP-Version you are running whether the composer.lock can be used or has to be updated. Sadly there’s no hint that tells me which PHP-Version the file has been created with so I will have to test whether an
install will work or not.
Entry the “config/platform”-parameter. It allows the creator of a package to specify what PHP-Version should be used to resolve the dependencies regardless of what the actual PHP-Version is. This might have the consequence of installing useless packages as installed packages might not work on the installed PHP-Version.
So one thing to have in mind when committing or receiving a
composer.lock-file is, that it contains a set of dependencies, that was working for the committer but it might not work for the user as the environment might have changed to a point where the packages of the composer.lock-file might not be usable anymore. Consider a locked Version of
phpunit/phpunit:4.8 because the file was created using PHP 5.5 and you are running PHP 7.
The second thing that came to my mind was that the lock-file might or might not contain the dev-requirements. So when you are developing a lib you’d want other developers to have the same versions of your dev-tools so it’s a good idea to have them in the lock file. And when you are developing a web-project (website of a certain extend) you might want to use the lock-file to automatically deploy the libs you where testing agains. But as it’s for deployment you’d create the lock-file without the dev-dependencies. That will then leave other developers without the dev-dependencies, so they will have to run a
composer update (because
composer install will tell you that you should either run
composer install --no-dev or
composer update) anyway.
And also when you do automated testing against the lowest,locked,latest-strategy you might run into issues with locked packages not being able to run on the current platform even though they are installed without an issue. Have a look for example at https://travis-ci.org/heiglandreas/composerlocktest/jobs/133745846. The test fails due to PHPUnit being installed in the wrong version due to that version being locked in the
Be careful when you commit your lock-file. Indicate clearly what PHP-Version you used when creating it. Either by providing the suggested version using the
platform-Parameter or by pointing it out in the documentation very clear. And remember to only automatically test the locked dependencies with the PHP-Versions you created the
Be careful when you use a lock-file. Check whether there is a hint to the provided version in the
composer.json file or in the documentation of the project you are using. Have a look at the CI-config-file, it might give you a hint.
Recently I presented a talk about Timezones (which I hope to present a few more times). During the preparation I stumbled over a a function that eases timezone-based datetime-calculations in MySQL:
CONVERT_TZ. You can use it to convert from one timezone into a different one. So let’s say we have a database created like this:
CREATE TABLE `datetime` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `zeit` datetime DEFAULT NULL, `zone` varchar(255) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4; INSERT INTO `datetime` (`id`, `zeit`, `zone`) VALUES (1,'2014-03-04 12:23:34','Europe/Berlin'), (2,'2016-05-03 23:12:23','Europe/Busingen'), (3,'2016-05-03 23:12:23','America/Chicago');
So the dates in the table are in their respective timezones.
To check which Dates are before 14:00 UTC you can use a select-statement like this:
SELECT * FROM datetime WHERE TIME(CONVERT_TZ(zeit, zone, 'UTC')) < "14:00:00";
It will return something like this:
1 | 2014-03-04 12:23:34 | Europe/Berlin
3 | 2016-05-03 23:12:23 | America/Chicago
CONVERT_TZ you can convert a datetime (from a datetime-field) from a timezone into a different timezone. And the timezone can also be a field from the table.
The only prerequisit is that the timezone-informations have to be set up in the database. For that you’ll use the servers timezone-informations by calling
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql.
You can find more information on that at https://dev.mysql.com/doc/refman/5.5/en/time-zone-support.html and https://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_convert-tz