Automate deployments

Building off of the conversation with @orangemug in #123, it looks like Travis and/or CircleCI could be used more to automate deployments. Instead of updating the main GitHub Pages repo, Pages could be turned on in this repo and a build step could be added that deploys the site to the gh-pages branch so that it will still be available at maputnik.github.io/editor

Alternatively, for branch, tag, and PR builds we could use Surge.sh. S3 is great for builds like this, but Surge is completely free and here’s an example of someone using it for a similar workflow. I’m happy to take a stab at setting up the build, but have there been any updates on getting maputnik.com back? That could be used as the custom domain for Surge.sh, otherwise maputnik.github.io/editor could still be used as the main location, with individual builds having surge domains

[orangemug]

Right here is how it’s going to work. The tools (git-deploy) are built and ready to be integrated into maputnik.

We have a new repository called maputnik/editor-builds which will store all the builds for the maputnik/editor repository.

maputnik/website and maputnik/desktop contain submodules to the maputnik/editor-builds repository.

The content of maputnik/editor-builds repository is generated by git-deploy via CircleCI whenever a semver tag is added. The directory structure will end up looking something like this

builds
├── 0.1.0
├── 0.1.1
├── 0.2.0
├── 0.3.0-beta
└── latest -> ./0.2.0

I have a second util script (which I’ll release shortly) that bumps submodules in repositories to the HEAD commit of a branch. This will update maputnik/desktop to the correct version while also causing github pages to rebuild maputnik/website and hence deploy the new version of the code to the world on https://maputnik.com

So all going well cutting a new release will be as easy as running the following from the maputnik/editor repository.

npm version minor
git push origin master --tags

@lukasmartinelli for this to work I need to add deploy keys to GitHub and CircleCI for the following repositories

• maputnik/editor
• maputnik/editor-builds
• maputnik/website

I’m happy to do this of you give me the correct permissions. Else the details can be found in the GitHub and CircleCI sections of this document https://github.com/orangemug/git-deploy/blob/master/docs/quick-start.md

Any feedback welcome.

Note: I know submodules can be awkward to use sometimes, however they are already used in maputnik/desktop so I’ve decided to use them in maputnik/website also. Later I may move to updating a package.json so something similar but for now this’ll work fine.

[pathmapper]

Sounds good to me @orangemug.

In this scenario, where would we store the builds? Are these basically the public.zip files from the release assets?

So the deployment workflow would be the following?

1. Create manually a release in the editor repo, e.g. v1.8.0
2. Manually upload a public.zip file with the v1.8.0 build to the release assets of the editor v1.8.0 release (the build could be taken from the editor ci artifact which is currently named editor).
3. Manually update the editor version number in the desktop repo (https://github.com/maputnik/desktop/blob/master/maputnik.go#L19) and create a new desktop release.
4. Manually upload the 3 desktop artificats created by the desktop ci workflow (e.g. https://github.com/maputnik/desktop/runs/734727176) to the editor release assets of the v1.8.0 release
5. Manually update the active version in the versions.json file to v1.8.0.

This would be fine!

Maybe we should change the name of the public.zip file in the release assets to editor.zip so there is no need to rename the artifact. Then we must adapt the desktop makefile to pull the editor.zip. Or just rename the editor artifact to public.zip.