AlloyCI v0.7.0 has been released! This version includes some major changes. Keep reading for a better description, or go here to checkout the code.
Deprecations
The biggest change for this release is the fact that JSON configuration files have been deprecated. You will no longer be able to use them to configure your AlloyCI builds. From now on you will need a YAML configuration file.
The main reason behind this decision is that YAML is much more flexible than JSON. It allows us to use aliases in oder to avoid duplication, to add comments to make the config file more understandable, and it is the de facto standard configuration file for almost all CI systems in the market.
When I first started writing AlloyCI, my initial intention was to use YAML for the configuration files, but at that time, the YamlElixir library did not support all modern YAML features. A couple of months ago these features were added to the library, but it still lacked proper support for aliases. I decided to see how difficult it would be to add that functionality. Luckily it was quite simple, so now AlloyCI uses its own fork of the YamlEixir library with proper support for aliases.
Furthermore, YAML makes the configuration file easier to write and easier to read. As an example, here is the config file used for AlloyCI in JSON format:
{
"image": "elixir:latest",
"services": [
"postgres:9.6"
],
"cache": {
"paths": [
"_build/",
"deps/"
]
},
"variables": {
"MIX_ENV": "test",
"GITHUB_CLIENT_ID": "fake-id",
"GITHUB_CLIENT_SECRET": "fake-secret",
"GITHUB_SECRET_TOKEN": "fake-token",
"SECRET_KEY_BASE": "NULr4xlNDNzEwE77UHdId7cQU+vuaPJ+Q5x3l+7dppQngBsL5EkjEaMu0S9cCGbk",
"DATABASE_URL": "postgres://postgres@postgres:5432/alloy_ci_test"
},
"before_script": [
"mix local.hex --force",
"mix local.rebar --force",
"mix deps.get",
"mix ecto.setup"
],
"mix + coveralls": {
"stage": "test",
"tags": [
"elixir",
"postgres"
],
"script": [
"mix coveralls.post --branch \"$CI_COMMIT_REF_SLUG\" --name \"$CI_SERVER_NAME\" --sha \"$CI_COMMIT_SHA\" --committer \"$CI_COMMIT_PUSHER\" --message \"$CI_COMMIT_MESSAGE\""
]
},
"credo + formatter": {
"stage": "test",
"tags": [
"elixir"
],
"script": [
"mix credo",
"mix format --check-formatted"
]
}
}
And here is the exact same config in YAML:
image: elixir:latest
services:
- postgres:9.6
cache:
paths:
- _build/
- deps/
variables:
MIX_ENV: test
GITHUB_CLIENT_ID: fake-id
GITHUB_CLIENT_SECRET: fake-secret
GITHUB_SECRET_TOKEN: fake-token
SECRET_KEY_BASE: NULr4xlNDNzEwE77UHdId7cQU+vuaPJ+Q5x3l+7dppQngBsL5EkjEaMu0S9cCGbk
DATABASE_URL: postgres://postgres@postgres:5432/alloy_ci_test
before_script:
- mix local.hex --force
- mix local.rebar --force
- mix deps.get
- mix ecto.setup
mix + coveralls:
stage: test
tags:
- elixir
- postgres
script:
- mix coveralls.post --branch "$CI_COMMIT_REF_SLUG" --name "$CI_SERVER_NAME" --sha
"$CI_COMMIT_SHA" --committer "$CI_COMMIT_PUSHER" --message "$CI_COMMIT_MESSAGE"
credo + formatter:
stage: test
tags:
- elixir
script:
- mix credo
- mix format --check-formatted
Much cleaner, right?
Also, YAML allows you to use comments in your file, which means that if you have a particularly complex setup, you can leave comments in them to make it easier to understand for people new to the project.
In addition to that, YAML allows you to declare aliases in your file, like a generic part, that can be reused in other declarations in order to avoid extra typing, e.g.:
image: elixir:latest
# This is the generic part we want to reuse.
.docker: &docker
image: elixir:1.5
entrypoint:
- "/bin/bash"
mix:
# In here he use that generic part, so everything declared there, will be added here
<<: *docker
services:
- postgres:9.6
stage: test
tags:
- elixir
- postgres
script:
- mix test
credo:
# Same goes for here
<<: *docker
services:
- postgres:latest
- redis:latest
stage: test
tags:
- elixir
script:
- mix credo
# This one does not use the generic part, so it will use the `image` declared in the first line
distillery:
tags:
- elixir
- postgres
variables:
MIX_ENV: prod
script:
- mix docker.build --tag latest
artifacts:
paths:
- alloy_ci.tar.gz
- _build/prod/lib/alloy_ci
And AlloyCI is smart enough not to treat elements starting with a .
as a build directive, so no build named .docker
will be created.
I'm sure using YAML will make AlloyCI a lot friendlier and easier to use.
New Features
This release does not include many new features. The most notorious one is that the status of pipelines and builds will be automatically updated via websockets in their own respective page.
This means that whenever you are in the project view (to see a list of pipelines) or on the pipeline view (to see a list of build jobs) the status of each one will be automatically updated whenever their status changes on the backend. This is accomplished via Phoenix Channels. You can see the changes necessary for this to work here.
Bug fixes
- Fixed redirect loop that would happen when an authentication token expires.
- Reverted back to Kerosene v0.7.0, as the updated v0.8.0 had pagination bugs.
Thank you for your interest on AlloyCI, and I hope you find this update useful. As always don't hesitate to ask any question, or report any bugs via the issue tracker on GitHub.
Check out AlloyCI v0.7.0! https://github.com/AlloyCI/alloy_ci/releases/tag/v0.7.0
🎉🐣
Top comments (0)