mkdir osm
wget -O osm/planet.mbtiles https://hidrive.ionos.com/api/sharelink/download?id=SYEgScrRe
podman run -ti --rm -p 9000:9000 --name sms -v $(pwd)/osm/:/data/ registry.gitlab.com/markuman/sms:latest
firefox http://localhost:9000
npm uses Semantic Versioning. Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards compatible manner, and
- PATCH version when you make backwards compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format, e.g. 1.0.0-alpha.
| variables: | |
| VERSION_ID: '1.0.$CI_PIPELINE_ID' | |
| stages: | |
| - build | |
| build: | |
| image: slauta93/electron-builder-win | |
| stage: build | |
| artifacts: |
Automating things in software development is more than useful and using Ansible is one way to automate software provisioning, configuration management, and application deployment. Normally you would install Ansible to your control node just like any other application but an alternate strategy is to deploy Ansible inside a standalone Docker image. But why would you do that? This approach has benefits to i.a. operational processes.
Although Ansible does not require installation of any agents within managed nodes, the environment where Ansible is installed is not so simple to setup. In control node it requires specific Python libraries and their system dependencies. So instead of using package manager to install Ansible and it’s dependencies we just pull a Docker image.
By creating an Ansible Docker image you get the Ansible version you want and isolate all of the required dependencies from the host machine which potentially might break things in other area
/!\ Be very carrefull in your setup : any misconfiguration make all the git config to fail silently ! Go trought this guide step by step and it should be fine 😉
- Generate your SSH keys as per your git provider documentation.
- Add each public SSH keys to your git providers acounts.
- In your
~/.ssh/config, set each ssh key for each repository as in this exemple:
| variables: | |
| VERSION_ID: '1.0.$CI_PIPELINE_ID' | |
| stages: | |
| - build | |
| build: | |
| image: slauta93/electron-builder-win | |
| stage: build | |
| artifacts: |
| env - `cat /root/env.sh` /bin/bash -c $1 >> /var/log/cron.log 2>&1 |
I recently had several days of extremely frustrating experiences with service workers. Here are a few things I've since learned which would have made my life much easier but which isn't particularly obvious from most of the blog posts and videos I've seen.
I'll add to this list over time – suggested additions welcome in the comments or via twitter.com/rich_harris.
Chrome 51 has some pretty wild behaviour related to console.log in service workers. Canary doesn't, and it has a load of really good service worker related stuff in devtools.


