* refactor(graphql): Introduce image type
* Undo changes to .travis.yml
* chore: Upgrade travis to node LTS
- URL is available since v10
* chore: use lts
Co-authored-by: mattwr18 <mattwr18@gmail.com>
- Looking at our releases, https://github.com/Human-Connection/Human-Connection/releases, the ones created from our build server, are not sufficient.
As part of the deploy process, I have been manually creating the Releases in Github, using our CHANGELOG.md.... I propose we remove this script from our build server, as it's now breaking our master build and it's not being used.
Remove VERSION file in favour of version entry in `package.json`. Parse
this version in our build server scripts.
This commit also introduces `standard-version` which we can use to
generate our `CHANGELOG.md` with `yarn run release`.
close#1831
So I had `DOCKER_CLI_EXPERIMENTAL=enabled` enabled by default and
couldn't reproduce the error on my machine. This time I'm pretty sure it
works as expected.
The Dockerfile is still using `apk` instead of `apt-get` (Debian slim).
So that's why our build server was never successfully pushing the
`maintenance-worker` image.
I contributed to `ghr` here:
https://github.com/tcnksm/ghr/pull/118
Now after `ghr` does not need any artifacts to create a file, we can
stop uploading archives. (Use the default archives provided by Github)
Inspired by the tagging of e.g. `node` on dockerhub:
https://hub.docker.com/_/node/?tab=description
I would like to push the current version of all our images to dockerhub.
This is a first step to push to production later on.
If sb. increments the VERSION file, this is considered a release.
This commit should setup kubectl in a way that it downloads a recent
`kubeconfig` from Digitial Ocean with `doctl`. Thus, deployments will
not fail after a kubeconfig has expired.
Since it seems to be the recommended way to install `doctl` through
[Snap](https://snapcraft.io/). I decided to install everything else
through snap too, including chrome and docker.
The documentation clearly says:
```
Note: A Deployment’s rollout is triggered if and only if the
Deployment’s pod template (that is, .spec.template) is changed, for
example if the labels or container images of the template are updated.
Other updates, such as scaling the Deployment, do not trigger a
rollout.
```
Read: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment
