AlloyCI v0.7.0 released!

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

🎉🐣