Mikhail Grachev's blog

Update-informer v0.5.0

Mon, 29 Aug 2022 08:00:00 +0000

Update-informer is a crate for CLI applications that written in Rust — such as git-cliff and dotenv-linter. It checks for a new version on Crates.io and GitHub.

Also, it has the minimum number of dependencies — only directories, ureq, semver and serde.

The idea is actually not new. This feature has long been present in the GitHub CLI application and npm. There is also a popular JavaScript library.

What is new in v0.5.0?

PyPi support

Now update-informer can check for a new version on PyPi:

use update_informer::{registry, Check};

let informer = update_informer::new(registry::PyPI, "package_name", "0.1.0");
informer.check_version();

Configurable check frequency and request timeout

By default, the first check will start only after the interval has expired (= 24 hours), but you can change it:

use std::time::Duration;
use update_informer::{registry, Check};

const EVERY_HOUR: Duration = Duration::from_secs(60 * 60);

let informer = update_informer::new(registry::Crates, "crate_name", "0.1.0").interval(EVERY_HOUR);
informer.check_version(); // The check will start only after an hour

It is also possible to change the request timeout (default 5 seconds).

Disabling caching

To avoid spam requests to the registry API, update-informer creates a file in the cache directory. In order not to cache requests, use a zero interval:

use std::time::Duration;
use update_informer::{registry, Check};

let informer = update_informer::new(registry::Crates, "crate_name", "0.1.0").interval(Duration::ZERO);
informer.check_version();

Implementing your own registry

You can implement your own registry to check updates. For example:

use std::time::Duration;
use update_informer::{registry, Check, Package, Registry, Result};

struct YourOwnRegistry;

impl Registry for YourOwnRegistry {
const NAME: &'static str = "your_own_registry";

    fn get_latest_version(pkg: &Package, _timeout: Duration) -> Result<Option<String>> {
        let url = format!("https://your_own_registry.com/{}/latest-version", pkg);
        let result = ureq::get(&url).call()?.into_string()?;
        let version = result.trim().to_string();

        Ok(Some(version))
    }
}

let informer = update_informer::new(YourOwnRegistry, "package_name", "0.1.0");
informer.check_version();

Please support the project 🙏

Star on GitHub ⭐️
Become a sponsor on OpenCollective ❤️

Dotenv-linter v3.1.0

Thu, 10 Jun 2021 08:00:00 +0000

We are happy to announce the release of a new version of dotenv-linter - v3.1.0 🎉

What is dotenv-linter?

Dotenv-linter is a lightning-fast linter for checking, fixing and comparing .env files.
And it’s written in Rust 🦀

What is a `.env` file?

A .env file or dotenv file is a simple text file containing all the environment variables of a project. The .env file has a simple key-value format, for example: FOO=BAR. Storing configuration in the environment variables is one of the tenets of the Manifesto of Twelve-Factor App.

What is new in v3.1.0?

More information you can find here: https://dotenv-linter.github.io/#/whats_new/v310

How you can support the project 😉

Star on GitHub ⭐️
Become a sponsor on GitHub Sponsors or OpenCollective ❤️
Contribute to the dotenv-linter ⚙️

GitHub Actions to guard your workflow

Wed, 10 Feb 2021 08:00:00 +0000

Modern development is so complex that it is simply impossible to keep everything in mind, especially various practices for writing code. This is where linters come to the rescue. They help maintain certain standards in the project and keep the code base in order.

I develop projects in a variety of programming languages such as: Rust, Go, Ruby and I connect different linters to each project. To make sure my code meets all quality standards, I run linters using CI services for every commit submitted to GitHub.

Reviewdog

It is very important to me that the result of linters’ work is always visible on GitHub, for example, in the form of comments to pull requests. To do this, I use reviewdog, which automates code review and provides seamless integration of any linter with GitHub. Here’s why reviewdog is so good:

It is written in Go and can be compiled into a binary file and connected to any project, regardless of the programming language;
It can work with any linters, you just need to redirect the linter result to the reviewdog input and define the linter output format, for example, $ dotenv-linter | reviewdog -efm="%f:%l %m";
It supports a large number of linters out of the box, such as dotenv-linter, rubocop and others.

GitHub Actions

As cool as reviewdog is, I still had to spend time setting up CI services to run linters for each project. But that all changed when GitHub announced GitHub Actions, a new tool for automating workflows. Simply put, this is a full-fledged CI/CD service with great capabilities that allows you to create your own actions and share them with the community.

Having switched to GitHub Actions, I decided to write my own actions to run popular linters. By doing this, I could simplify the process of connecting linters to any project. This is what I ended up with:

All of my actions can publish linter comments in two modes.

As an annotation in the code (github-pr-check):

And in the form of comments to pull requests (github-pr-review):

Ruby Actions

The first 3 actions (action-rubocop, action-brakeman and action-reek) allow you to run popular linters from the Ruby community: rubocop, brakeman and reek. To connect these actions to your project, you just need to create a .github/workflows/linters.yml file with the following content:

# .github/workflows/linters.yml
name: linters
on: [pull_request]
jobs:
  linters:
    name: runner / linters
    runs-on: ubuntu-latest
    steps:
      - name: Check out code
        uses: actions/checkout@v1
      - name: rubocop
        uses: reviewdog/action-rubocop@v1
        with:
          rubocop_version: gemfile
          rubocop_extensions: rubocop-rails:gemfile rubocop-rspec:gemfile
      - name: brakeman
        uses: reviewdog/action-brakeman@v1
        with:
          brakeman_version: gemfile
      - name: reek
        uses: reviewdog/action-reek@v1
        with:
          reek_version: gemfile

For all these action it is possible to specify the linter version. There are 3 options available:

An empty value or no version - the latest version will be installed;
gemfile - the version from Gemfile.lock will be installed;
1.0.0 - the specified version will be installed.

Action-rubocop also provides the ability to install additional extensions. The following extensions are installed by default: rubocop-rails, rubocop-performance, rubocop-rspec, rubocop-i18n, rubocop-rake. But this can be overridden using the rubocop_extensions attribute.

Dockerfile Action

The next action, action-hadolint, looks for all Dockerfile in the project and checks them using the hadolint linter. Usage example:

# .github/workflows/hadolint.yml
name: hadolint
on: [pull_request]
jobs:
  hadolint:
    name: runner / hadolint
    runs-on: ubuntu-latest
    steps:
      - name: Check out code
        uses: actions/checkout@v1
      - name: hadolint
        uses: reviewdog/action-hadolint@v1
        with:
          hadolint_ignore: DL3008

Dotenv-linter Action

And last but not least, is action-dotenv-linter. It allows you to easily and simply check all .env files on the project. Usage example:

# .github/workflows/dotenv_linter.yml
name: dotenv-linter
on: [pull_request]
jobs:
  dotenv-linter:
    name: runner / dotenv-linter
    runs-on: ubuntu-latest
    steps:
      - name: Check out code
        uses: actions/checkout@v1
      - name: dotenv-linter
        uses: dotenv-linter/action-dotenv-linter@v2
        with:
          dotenv_linter_flags: --skip UnorderedKey

Find more GitHub Actions on the GitHub Marketplace page.

GitHub Actions is a cool workflow automation tool that allows you to completely replace all existing CI/CD services on a project. I wrote several GitHub Actions to launch popular linters, which allowed me to significantly simplify the process of connecting and configuring linters on each project.

Dotenv-linter v3.0.0

Thu, 28 Jan 2021 09:00:00 +0000

Прошло 2 с половиной месяца с момента прошлого релиза, а мы уже готовы вам представить новую версию dotenv-linter - v3.0.0 🎉

Что такое `.env` файлы?

.env или dotenv файлы — это простые текстовые файлы, содержащие в себе переменные окружения проекта. Файлы имеют формат «ключ-значение», например: FOO=BAR. Хранение конфигурации в переменных окружения является одним из принципов манифеста Twelve-Factor App.

Вот обзор ключевых изменений, которые попали в этот релиз.

1. Улучшение API 👍

В предыдущей версии, у dotenv-linter было несколько флагов, которые по сути являлись отдельными командами - --fix и --show-checks:

FLAGS:
    -f, --fix            Automatically fixes warnings
    -h, --help           Prints help information
        --no-backup      Prevents .env files from being backed up when modified by -f/--fix
    -q, --quiet          Doesn't display additional information
    -r, --recursive      Recursively search and check .env files
        --show-checks    Shows list of available checks
    -v, --version        Prints version information

Это приводило к небольшой путанице, т.к. эти флаги конфликтовали и не работали друг с другом:

$ dotenv-linter --fix --show-checks

В новой версии мы исправили это и вынесли флаги --fix и --show-checks в отдельные команды fix и list:

FLAGS:
    -h, --help         Prints help information
    -q, --quiet        Doesn't display additional information
    -r, --recursive    Recursively searches and checks .env files
    -v, --version      Prints version information

SUBCOMMANDS:
    fix        Automatically fixes warnings [aliases: f]
    list       Shows list of available checks [aliases: l]

PR: #342 (@mgrachev)

2. Сравнение `.env` файлов 🤲

Также, в новой версии мы добавили новую команду compare, которая позволяет сравнивать ключи в .env файлах:

$ dotenv-linter compare .env .env.example
Comparing .env
Comparing .env.example
.env is missing keys: BAR
.env.example is missing keys: FOO

PR: #282 (@mstruebing)

3. Отображение проверяемых файлов 👀

При наличии нескольких .env файлов, не всегда было понятно, какие из них проверил dotenv-linter, а какие нет.

Это могло быть связано с нестандартным именем файла, либо с отсутствием каких-либо проблем в этих файлах.

Поэтому в новой версии мы добавили отображение проверяемых файлов:

$ dotenv-linter
Checking .env
.env:1 LeadingCharacter: Invalid leading character detected

Checking .env.example
Checking .env.test

Found 1 problem

Отключить такое поведение можно с помощью флага --quiet/-q:

$ dotenv-linter --quiet
.env:1 LeadingCharacter: Invalid leading character detected

PR: #311 (@Anthuang), #336 (@DDtKey)

4. Цветной вывод 🌈

Для улучшения удобства использования, мы добавили цветной вывод предупреждений:

Отключить цветной вывод можно с помощью флага --no-color.

PR: #307 (@Nikhil0487)

5. Поддержка многострочных значений 💪

В .env файлах можно хранить многострочные значения. Один из вариантов выглядит следующим образом:

# .env
MULTILINE="new\nline"

Но при проверке таких значений, dotenv-linter всегда выводил предупреждение:

$ dotenv-linter
.env:1 QuoteCharacter: The value has quote characters (', ")

Found 1 problem

Мы исправили это и теперь dotenv-linter не выводит предупреждения для многострочных значений, обернутых кавычками.

PR: #341 (@artem-russkikh)

6. Поддержка `export` префикса 🔥

Некоторые библиотеки для работы с .env файлами, такие как: dotenv, godotenv и python-dotenv поддерживают export префикс:

# .env
export S3_BUCKET=YOURS3BUCKET
export SECRET_KEY=YOURSECRETKEYGOESHERE

export префикс дает возможность экспортировать переменные окружения из файла с помощью команды source:

$ source .env

При проверке таких файлов, dotenv-linter всегда выводил предупреждения:

$ dotenv-linter
.env:1 IncorrectDelimiter: The export S3_BUCKET key has incorrect delimiter
.env:1 LowercaseKey: The export S3_BUCKET key should be in uppercase
.env:2 IncorrectDelimiter: The export SECRET_KEY key has incorrect delimiter
.env:2 LowercaseKey: The export SECRET_KEY key should be in uppercase

Found 4 problems

В новой версии мы добавили поддержку export префикса и теперь dotenv-linter не выводит никаких предупреждений.

PR: #340 (@skonik)

7. Поддержка пробелов 🙌

Ещё одним из улучшений стала поддержка пробелов в значениях, обернутых кавычками:

# .env
WHITESPACES="a b c"

Теперь, для таких значения dotenv-linter не будет выводить предупреждения.

PR: #349 (@sebastiantoh)

8. Улучшенная проверка 👌

Также, мы исправили проблему, при которой dotenv-linter мог выводить не все предупреждения за один раз:

$ dotenv-linter fix .env
Fixing .env
Original file was backed up to: ".env_1606422805"

.env:1 KeyWithoutValue: The test key should be with a value or have an equal sign

All warnings are fixed. Total: 1

$ dotenv-linter .env
Checking .env
.env:1 LowercaseKey: The test key should be in uppercase

Found 1 problem

PR: #348 (@vbrandl)

9. Улучшение производительности 🚀

И последнее, но не по значению - мы улучшили производительность и без того быстрого dotenv-linter, что теперь максимальное время запуска уменьшилось с 9.3 мс до 4.3 мс (более чем на 50%) 🙀

Для подтверждения этого, мы сделали бенчмарк с помощью утилиты hyperfine:

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
`dotenv-linter/dotenv-linter .env`	2.7 ± 0.4	2.0	4.3	1.00
`wemake-services/dotenv-linter .env`	162.6 ± 12.1	153.0	201.3	60.83 ± 10.20

PR: #350 (@vbrandl)

Это все ключевые изменения, которые вошли в новый релиз v3.0.0. Спасибо всем кто участвовал в подготовке этого релиза 🙏

Вы можете поддержать проект 😉

Поставить звездочку на GitHub ⭐️
Стать спонсором на GitHub Sponsors или OpenCollective ❤️

Dotenv-linter: линтер .env файлов

Mon, 20 Apr 2020 17:00:00 +0000

При разработке приложений я всегда стараюсь придерживаться манифеста двенадцати факторов. Такой подход позволяет избежать большого количества проблем, связанных с развертыванием приложений и их дальнейшей поддержкой.

Один из принципов этого манифеста гласит, что все настройки должны хранится в переменных окружения. Это позволяет менять их под разные окружения (Staging, QA, Production) без изменения кода.

Однако, во время разработки могут возникать сложности при работе с такими переменными. С ростом проекта, обычно также увеличивается количество переменных окружения и с ними становится не так удобно работать. Нужно каждый раз указывать их все при запуске приложения:

$ RAILS_ENV=development REDIS_URL=redis://redis:6379 DATABASE_URL=postgres://postgres:postgres@db:5432 bundle exec rails server

И тут на помощь приходят .env файлы. Они предоставляют удобный способ хранения всех переменных окружения в одном месте:

# .env
RAILS_ENV=development
REDIS_URL=redis://redis:6379
DATABASE_URL=postgres://postgres:postgres@db:5432

Для работы с .env файлами есть довольно много библиотек на разных языках программирования. Всё что они делают — это загружают переменные из .env файла при запуске приложения:

Rust: https://github.com/dotenv-rs/dotenv;
Golang: https://github.com/joho/godotenv;
Ruby: https://github.com/bkeepers/dotenv;
PHP: https://github.com/vlucas/phpdotenv;
Elixir: https://github.com/avdi/dotenv_elixir;
JavaScript: https://github.com/motdotla/dotenv;
Haskell: https://github.com/stackbuilders/dotenv-hs;
Python: https://github.com/theskumar/python-dotenv.

При использовании Docker и Docker Compose переменные окружения можно указать с помощью ключа environment в файле docker-compose.yml:

# docker-compose.yml
version: '2.4'
services:
  app:
    build:
      context: .
    environment:
      RAILS_ENV: development
      REDIS_URL: redis://redis:6379
      DATABASE_URL: postgres://postgres:postgres@db:5432

Но, как я уже писал ранее, с ростом проекта также увеличивается количество переменных, а вместе с ними и количество сервисов, которые необходимы вашему приложению, например Redis, RabbitMQ и т.д. И со временем, docker-compose.yml увеличивается в размерах и становится просто нечитаемым. В такой ситуации опять же могут помочь .env файлы, в которые можно вынести все переменные окружения и подключить их к docker-compose.yml с помощью ключа env_file:

# docker-compose.yml
version: '2.4'
services:
  app:
    build:
      context: .
    env_file:
      - .env

В процессе работы с .env файлами, часто могут возникать проблемы, которые можно не заметить с первого взгляда и даже пропустить при проверке кода, но которые могут стать причиной неправильной работы приложения:

1. Дублирование ключей

Такую проблему можно встретить, если в проекте есть .env файл, который содержит большое количество строк. В этой ситуации, легко не заметить появление новых переменных окружения с уже существующими ключами. В таком случае, новые переменные перезапишут старые значения:

# .env
FOO=BAR
# ...
FOO=FOO

2. Неправильный разделитель

Для удобства ключи переменных окружения можно разделять с помощью символа _. Однако в процессе разработки можно легко ошибиться и использовать другой символ, например -:

# .env
# Неправильно
FOO-BAR=FOOBAR

# Правильно
FOO_BAR=FOOBAR

3. Переменные без значения

Иногда бывают ситуации, когда нужно добавить новую переменную в приложение, но пока неизвестно, какое значение у неё будет. В таком случае обычно добавляют пустую переменную окружения. Но и здесь можно допустить ошибку, забыв указать символ =:

# .env
# Неправильно
FOO

# Правильно
FOO=

4. Некорректный первый символ

Не все знают, но есть ограничения при наименование переменных окружения. Они не могут начинаться с цифр и других символов, за исключением символа _:

# .env
# Неправильно
 FOO=BAR
.FOO=BAR
*FOO=BAR
1FOO=BAR

# Правильно
_FOO=BAR

5. Ключи в нижнем регистре

Продолжая тему ограничений, нельзя не упомянуть, что все ключи переменных окружения должны быть в верхнем регистре:

# .env
# Неправильно
foo=bar

# Правильно
FOO=bar

6. Пробелы

Ещё одной проблемой могут стать пробелы. Особенно, если они присутствуют между ключом и значением переменной окружения:

# .env
# Неправильно
FOO = BAR

# Правильно
FOO=BAR

7. Сортировка по алфавиту

Сортировка, конечно, не является проблемой, но куда приятнее работать с .env файлами, где все ключи отсортированы по алфавиту:

# .env
# Неправильно
FOO=BAR
BAR=FOO

# Правильно
BAR=FOO
FOO=BAR

Все проблемы, описанные выше, взяты из реальных проектов. На протяжение всей своей работы я постоянно сталкивался с ними, что доставляло различные неудобства в процессе разработки, а в некоторых случаях даже приводило к неправильной работе приложений.

Поэтому в один прекрасный день я решил создать инструмент, который позволил бы мне избежать подобных проблем в будущем, раз и навсегда.

И вот так появился dotenv-linter — линтер для .env файлов. Он позволяет проверить .env файлы на наличие всех проблем, описанных выше — от дублирования ключей и до сортировки.

Его ключевые особенности:

Молниеносно быстрый и всё благодаря тому, что он написан на Rust 🦀
Можно использовать на любом проекте, вне зависимости от языка программирования 🔥
Возможна интеграция с reviewdog и CI сервисами (включая GitHub Actions) 🚀

Установка

Есть несколько вариантов установки dotenv-linter. Самый простой вариант — скачать бинарный файл с помощью curl или wget:

# Linux / macOS / Windows (MINGW и т.д.). По умолчанию устанавливается в директорию ./bin
$ curl -sSfL https://raw.githubusercontent.com/dotenv-linter/dotenv-linter/master/install.sh | sh -s

# Можно указать директорию установки и версию
$ curl -sSfL https://raw.githubusercontent.com/dotenv-linter/dotenv-linter/master/install.sh | sh -s -- -b usr/local/bin v2.0.0

# Alpine Linux (wget)
$ wget -q -O - https://raw.githubusercontent.com/dotenv-linter/dotenv-linter/master/install.sh | sh -s

Другой вариант — установить через Homebrew:

$ brew install dotenv-linter

Так же есть возможность запуска dotenv-linter с помощью Docker:

$ docker run --rm -v `pwd`:/app -w /app dotenvlinter/dotenv-linter

Другие варианты установки можно найти на сайте проекта dotenv-linter.github.io.

Использование

По умолчанию dotenv-linter проверяет все .env файлы в текущей директории:

$ dotenv-linter
.env:2 DuplicatedKey: The FOO key is duplicated
.env:3 UnorderedKey: The BAR key should go before the FOO key
.env.test:1 LeadingCharacter: Invalid leading character detected

Чтобы проверить другую директорию, достаточно передать её путь в качестве аргумента. Этот же подход работает, если нужно проверить какие-нибудь файлы по отдельности:

$ dotenv-linter dir1 dir2/.my-env-file
dir1/.env:1 LeadingCharacter: Invalid leading character detected
dir1/.env:3 IncorrectDelimiter: The FOO-BAR key has incorrect delimiter
dir2/.my-env-file:1 LowercaseKey: The bar key should be in uppercase

Исключить какой-нибудь файл из проверки можно с помощью аргумента --exclude:

$ dotenv-linter --exclude .env.test
.env:2 DuplicatedKey: The FOO key is duplicated
.env:3 UnorderedKey: The BAR key should go before the FOO key

Интеграция

Отдельно стоит упомянуть про возможность интеграции dotenv-linter с reviewdog, что позволяет получать предупреждения от линтера в виде комментариев на GitHub или GitLab.

$ dotenv-linter | reviewdog -f=dotenv-linter -diff="git diff master"

При использование GitHub Actions, достаточно будет подключить к проекту dotenv-linter/action-dotenv-linter:

# .github/workflows/dotenv_linter.yml
name: dotenv-linter
on: [pull_request]
jobs:
  dotenv-linter:
    name: runner / dotenv-linter
    runs-on: ubuntu-latest
    steps:
      - name: Check out code
        uses: actions/checkout@v1
      - name: dotenv-linter
        uses: dotenv-linter/action-dotenv-linter@v1

Больше информации вы можете найти на сайте проекта dotenv-linter.github.io.

С самого начала dotenv-linter разрабатывался силами Open Source сообщества.
Поэтому, если у вас есть желание поизучать Rust и заодно поучаствовать в разработке замечательного Open Source проекта, то dotenv-linter — это то, что вам нужно!
Мы будем рады любой помощи!

Автоматическая проверка кода на Go

Mon, 26 Nov 2018 08:00:00 +0000

В прошлый раз, я уже писал небольшую инструкцию про то, как настроить автоматическую проверку кода с помощью pronto. Это отличный инструмент, который позволяет проверить качество кода при помощи всевозможных линтеров и получить результат в виде комментариев на GitHub или GitLab. Но, он написан на Ruby, следовательно, подключить его к проектам на других языках программирования, не представляется возможным. Поэтому, я начал искать альтернативу и нашел - reviewdog.

В отличие от pronto, reviewdog написан на Go. Его можно скомпилировать и подключить к любому проекту, вне зависимости от языка программирования.

Также, он может работать с любыми линтерами, достаточно лишь перенаправить результат работы линтера на вход reviewdog и определить формат сообщения. Для этого, reviewdog нужно запустить с флагом -efm и передать в качестве параметра строку вида: "%f:%l:%c: %m". Для примера, возьмем golint:

$ golint ./... | reviewdog -efm="%f:%l:%c: %m" -diff="git diff master"

Флаг -diff обязателен лишь для локального запуска, он позволяет отфильтровать результат и вывести сообщения только для новых изменений.

Чтобы постоянно не определять формат для каждого линтера, reviewdog поставляется с уже предопределенными форматами. Список можно получить, запустив его с флагом -list:

$ reviewdog -list
eslint		(eslint [-f stylish]) A fully pluggable tool for identifying and reporting on patterns in JavaScript	- https://github.com/eslint/eslint
eslint-compact	(eslint -f compact) A fully pluggable tool for identifying and reporting on patterns in JavaScript	- https://github.com/eslint/eslint
golint		linter for Go source code										- https://github.com/golang/lint
govet		Vet examines Go source code and reports suspicious problems						- https://golang.org/cmd/vet/
pep8		Python style guide checker										- https://pypi.python.org/pypi/pep8
phpstan		(phpstan --errorFormat=raw) PHP Static Analysis Tool - discover bugs in your code without running it!	- https://github.com/phpstan/phpstan
rubocop		A Ruby static code analyzer, based on the community Ruby style guide					- https://github.com/bbatsov/rubocop
sbt		the interactive build tool										- http://www.scala-sbt.org/
sbt-scalastyle	Scalastyle - SBT plugin											- http://www.scalastyle.org/sbt.html
scalac		Scala compiler												- http://www.scala-lang.org/
scalastyle	Scalastyle - Command line										- http://www.scalastyle.org/command-line.html
stylelint	A mighty modern CSS linter										- https://github.com/stylelint/stylelint
tsc		TypeScript compiler											- https://www.typescriptlang.org/
tslint		An extensible linter for the TypeScript language							- https://github.com/palantir/tslint
checkstyle	checkstyle XML format											- http://checkstyle.sourceforge.net/

Список небольшой, но он включает все популярные линтеры для разных языков программирования. Теперь, вместо определения формата, можно передать его название с помощью флага -f:

$ golint ./... | reviewdog -f=golint -diff="git diff master"

Этот же формат можно использовать и для других линтеров, например для golangci-lint:

$ golangci-lint run | reviewdog -f=golint -diff="git diff master"

Отдельно стоит упомянуть поддержку XML-формата checkstyle. С его помощью можно работать с такими линтерами, как например gometalinter:

$ gometalinter --checkstyle | reviewdog -f=checkstyle -diff="git diff master"

Для более удобного запуска нескольких линтеров, reviewdog поддерживает конфигурационные файлы следующего формата:

# .reviewdog.yml
runner:
  <tool-name>:
    cmd: <command> # (required)
    errorformat: # (optional if there is supporeted format for <tool-name>. see reviewdog -list)
      - <list of errorformat>
    name: <tool-name> # (optional. you can overwrite <tool-name> defined by runner key)

  # examples
  golint:
    cmd: golint ./...
    errorformat:
      - "%f:%l:%c: %m"
  govet:
    cmd: go tool vet -all -shadowstrict .

Теперь достаточно просто запустить reviewdog и он сам все сделает:

$ reviewdog -diff="git diff master"

По умолчанию reviewdog выводит весь результат работы в консоль. Для того, чтобы опубликовать результат на GitHub, нужно объявить переменную окружения REVIEWDOG_GITHUB_API_TOKEN и запустить reviewdog с флагом -reporter=github-pr-review:

$ export REVIEWDOG_GITHUB_API_TOKEN="<token>"
$ reviewdog -reporter=github-pr-review

В таком случае флаг -diff уже не нужен, reviewdog получит необходимые данные из переменных окружения:

$ export CI_PULL_REQUEST=7
$ export CI_REPO_OWNER=mgrachev
$ export CI_REPO_NAME=gastly
$ export CI_COMMIT=$(git rev-parse HEAD)

На этом плюсы reviewdog не заканчиваются, т.к. он из коробки поддерживает несколько популярных CI, таких как: Travis CI, Circle CI и GitLab CI. Если вы используете один из этих сервисов, то вам не нужно объявлять эти переменные окружения.

Это лишь малая часть тех возможностей, на что способен reviewdog. Более подробную информацию можно получить на странице проекта haya14busa/reviewdog.

Docker for Mac и Kubernetes

Mon, 26 Feb 2018 18:00:00 +0000

Начиная с версии 17.12 CE Edge, Docker for Mac поставляется вместе с Kubernetes. Теперь для создания локального Kubernetes кластера нет необходимости в использовании дополнительных инструментов, таких как Minikube. В качестве эксперимента, попробуем развернуть на кластере небольшой сервис и посмотрим, что из этого получится.

На момент написания статьи, у меня установлена самая последняя версия Docker for Mac - 18.02.0.

Для эксперимента, я написал простой генератор коротких ссылок на Go - brevity. Сервис разделен на 2 части: API для генерация коротких ссылок и их обработчик. Для хранения данных используется PostgreSQL.

Чтобы развернуть его и все необходимые зависимости, нам потребуется Helm - пакетный менеджер для Kubernetes, который заметно упрощает процесс развертывания и дальнейшей поддержки различных сервисов. Для его установки мы воспользуемся Homebrew:

$ brew install kubernetes-helm

После установки, нам нужно будет инициализировать Helm:

$ helm init

Если у вас настроен доступ к нескольких Kubernetes кластерам, то вам необходимо будет переключиться на локальный:

$ kubectl config use-context docker-for-desktop

Подготовка завершена, теперь приступаем к установке необходимых сервисов. Первым делом устанавливаем PostgreSQL:

$ helm install --name pg --namespace db --set postgresPassword=postgres,persistence.size=1Gi stable/postgresql

Helm позволяет переопределять значения по-умолчанию и тем самым настроить сервис под собственные нужды. Список сервисов, которые можно установить через Helm можно найти здесь - hub.kubeapps.com.

Теперь нам нужно удостовериться, что сервис установлен и работает корректно:

$ kubectl get pods -n db
NAME                            READY     STATUS                       RESTARTS   AGE
pg-postgresql-bbd4bbb5c-njkzs   0/1       CreateContainerConfigError   0          <invalid>

Сервис не запущен из-за ошибки. Чтобы узнать подробности, достаточно выполнить следующую команду:

$ kubectl describe pods -n db pg-postgresql-bbd4bbb5c-njkzs | tail -n 1
Warning  Failed                 <invalid> (x4 over 19s)  kubelet, docker-for-desktop  Error: lstat /Users/mgrachev/.docker/Volumes/pg-postgresql/pvc-588afa8b-0e90-11e8-8d22-025000000001: no such file or directory

Kubernetes не видит директорию, хотя она на самом деле есть. Оказалось, что Docker for Mac не понимает опцию subPath в конфигурации PostgreSQL для Kubernetes. В Minikube тоже была такая проблема, но её уже исправили.

Для решения этой проблемы, нам понадобится отредактировать Deployment для PostgreSQL:

$ kubectl edit deployment -n db pg-postgresql

И удалить следующую строчку:

subPath: postgresql-db

Теперь, если мы еще раз посмотрим на список запущенных подов, то увидим, что ошибок нет и сервис запущен:

$ kubectl get pods -n db
NAME                             READY     STATUS    RESTARTS   AGE
pg-postgresql-5c954c46c6-6bt2t   1/1       Running   0          26s

Далее, нам нужно создать БД для brevity. Сначала зайдем в контейнер:

$ kubectl exec -it -n db pg-postgresql-5c954c46c6-6bt2t bash

Внутри контейнера запускаем psql от имени пользователя postgres и создаем БД:

root@pg-postgresql-5c954c46c6-6bt2t:/# gosu postgres psql
postgres=# CREATE DATABASE brevity_production;

Чтобы наше приложение было доступно из кластера, нам понадобится Ingress Controller. Для этих целей отлично подойдет nginx:

$ helm install --name nginx stable/nginx-ingress

Переходим к установке brevity. Склонируем проект и запустим команду helm install, только в качестве аргумента передадим путь к заранее подготовленному чарту (пакеты в Helm называются чартами):

$ git clone https://github.com/mgrachev/brevity
$ cd brevity
$ helm install --name brevity ./helm

Проверяем, что все сервисы запущены:

$ kubectl get pods
NAME                                                   READY     STATUS    RESTARTS   AGE
brevity-brevity-778799dd4-zlb6g                        1/1       Running   0          1h
nginx-nginx-ingress-controller-c8cf56768-h4txk         1/1       Running   0          1h
nginx-nginx-ingress-default-backend-864c9484bf-rfdq4   1/1       Running   0          1h

Далее попробуем сгенерировать короткую ссылку, отправив POST запрос к API brevity:

$ curl -X "POST" "http://localhost/api/v1/shortlink" --data-urlencode "url=https://github.com/mgrachev"
{"shortlink":"http://localhost/MyAyEy"}

Переходим по ней, чтобы удостовериться, что все работает. Так же мы можем посмотреть логи:

$ kubectl logs brevity-brevity-778799dd4-zlb6g
time="2018-02-19T09:31:03Z" level=info msg="HTTP Server started at port: 80"
time="2018-02-19T09:32:35Z" level=info msg="Successful returns a short link, short: http://localhost/MyAyEy, original: https://github.com/mgrachev"
time="2018-02-19T09:32:43Z" level=info msg="Redirect to https://github.com/mgrachev, using token: MyAyEy"

Как видно из логов, сервис успешно обработал короткую ссылку и перенаправил на страницу github.com/mgrachev. На этом можно закончить наш эксперимент.

В заключение скажу, что Docker for Mac с поддержкой Kubernetes меня порадовал. Достаточно в настройках поставить всего одну галочку и в твоем распоряжение будет полностью готовый к работе кластер с Kubernetes на борту. Из минусов отмечу, что это пока нестабильная версия и могут встречаться разного рода ошибки. Но даже сейчас, он вполне пригоден для локальной разработки и тестирования.

Автоматическая проверка кода с помощью Vexor

Mon, 20 Mar 2017 12:00:00 +0000

Я думаю многим известен сервис Hound, который занимается автоматической проверкой кода. Когда вы создаете новый Pull Request на GitHub, Hound запускает проверку вашего кода на основе таких решений, как rubocop, haml-lint или scss-lint. Если в процессе проверки всплывают какие-то проблемы, Hound сообщит об этом, добавив соответствующий комментарий в ваш Pull Request. Это отличный инструмент для работы, но как говорится, за всё хорошее, приходится платить.

Не каждая компания готова платить такие деньги, поэтому я решил пойти другим путём. За основу взял библиотеку pronto, которая из коробки умеет всё тоже самое, что и Hound. Осталось дело за малым - интегрировать pronto с Vexor. Далее идет пошаговая инструкция, что для этого понадобится сделать.

Первым делом заходим на GitHub и генерируем персональный токен.

Затем, добавляем 2 переменные окружения в настройках вашего проекта на Vexor.

Далее, добавляем pronto и несколько его плагинов в Gemfile вашего проекта. Список доступных плагинов можно найти по этой ссылке.

group :test do
  gem 'pronto'
  gem 'pronto-brakeman', require: false
  gem 'pronto-coffeelint', require: false
  gem 'pronto-fasterer', require: false
  gem 'pronto-flay', require: false
  gem 'pronto-haml', require: false
  gem 'pronto-jshint', require: false
  gem 'pronto-rails_best_practices', require: false
  gem 'pronto-reek', require: false
  gem 'pronto-rubocop', require: false
  gem 'pronto-scss', require: false
end

Для запуска pronto нам потребуется создать файл bin/pronto:

#!/usr/bin/env ruby

require 'bundler/setup'
require 'pronto'
require 'pronto/cli'

begin
  Pronto::CLI.start
rescue Octokit::NotFound
  puts 'Pull Request Not Found'
end

И дать ему права на выполнение:

$ chmod +x bin/pronto

Теперь нам остаётся только добавить несколько команд в .vexor.yml:

language: ruby

script:
  - git remote set-branches origin '*'
  - git fetch
  - git checkout $CI_BRANCH
  - bin/pronto run -f github_pr -c $DEFAULT_BRANCH
  - bundle exec rake

И всё, можно проверять.

Кто-то может возразить, зачем всё это нужно, если есть overcommit? Новые разработчики на проекте часто забывают настроить overcommit и это обнаруживается только спустя несколько дней, когда другой разработчик не может отправить свои изменения на сервер. Чтобы исключить подобные ситуации, я рекомендую использовать эти инструменты вместе.

P.S. Хочу поблагодарить Сашу Кириллова, за помощь с интеграцией pronto и Vexor.

Управление зависимостями через Homebrew

Thu, 17 Nov 2016 11:00:00 +0000

Для управления зависимостями в проектах на Ruby мы используем Bundler. Он позволяет с легкостью устанавливать в проект необходимые нам библиотеки, вместе со всеми зависимостями.

Но что делать с внешними зависимостями проекта, такими как Redis или Node.js? Ситуация усугубляется, когда тебя подключают к новому проекту с большим багажом таких зависимостей. И вместо того, чтобы разбираться в проекте, ты тратишь целый день на установку всего этого зоопарка.

Homebrew Bundle

Для решения этой проблемы можно воспользоваться Homebrew Bundle. Он позволяет управлять внешними зависимостями проекта так же, как и Bundler внутренними, с помощью специального файла - Brewfile.

Итак, приступим. Устанавливаем Homebrew Bundle:

$ brew tap Homebrew/bundle
==> Tapping homebrew/bundle
Cloning into '/usr/local/Homebrew/Library/Taps/homebrew/homebrew-bundle'...
remote: Counting objects: 57, done.
remote: Compressing objects: 100% (53/53), done.
remote: Total 57 (delta 5), reused 16 (delta 2), pack-reused 0
Unpacking objects: 100% (57/57), done.
Checking connectivity... done.
Tapped 0 formulae (126 files, 154.5K)

Теперь необходимо создать Brewfile в корне проекта и добавить туда все необходимые зависимости. Это можно сделать вручную или запустить команду brew bundle dump, которая создаст файл со всеми установленными пакетами из Homebrew, например:

tap prosody/prosody

brew 'node'
brew 'redis'
brew 'prosody'
brew 'rabbitmq'
brew 'phantomjs'
brew 'postgresql'
brew 'imagemagick'

Запускаем команду brew bundle, чтобы установить или обновить все зависимости.

$ brew bundle
Succeeded in installing node
Succeeded in installing redis
Succeeded in installing prosody
Succeeded in installing rabbitmq
Succeeded in installing phantomjs
Succeeded in installing postgresql
Succeeded in installing imagemagick

Success: 7 Fail: 0

На этом можно было закончить, но что делать, если в команде есть разработчики на Linux? У них ведь нет Homebrew.

Linuxbrew

Homebrew - нет, но есть аналог - Linuxbrew. Он абсолютно так же работает, как и Homebrew на macOS.

Для его использования потребуется установить несколько дополнительных пакетов в свой дистрибутив:

$ sudo apt-get install build-essential curl git python-setuptools ruby

Далее устанавливаем Linuxbrew:

$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Linuxbrew/install/master/install)"
==> This script will install:
/home/ubuntu/.linuxbrew/bin/brew
/home/ubuntu/.linuxbrew/Library/...
/home/ubuntu/.linuxbrew/share/doc/homebrew
/home/ubuntu/.linuxbrew/share/man/man1/brew.1
/home/ubuntu/.linuxbrew/share/zsh/site-functions/_brew
/home/ubuntu/.linuxbrew/etc/bash_completion.d/brew
/home/ubuntu/.cache/Homebrew/

Press RETURN to continue or any other key to abort
==> Downloading and installing Linuxbrew...
remote: Counting objects: 1040, done.
remote: Compressing objects: 100% (930/930), done.
remote: Total 1040 (delta 106), reused 481 (delta 75), pack-reused 0
Receiving objects: 100% (1040/1040), 1.01 MiB | 325.00 KiB/s, done.
Resolving deltas: 100% (106/106), done.
From https://github.com/Linuxbrew/brew
 * [new branch]      master     -> origin/master
HEAD is now at b75ca7b CONTRIBUTING.md: Update Contributing to Linuxbrew
==> Homebrew has enabled anonymous aggregate user behaviour analytics
Read the analytics documentation (and how to opt-out) here:
  https://git.io/brew-analytics
==> Tapping homebrew/core
Cloning into '/home/ubuntu/.linuxbrew/Library/Taps/homebrew/homebrew-core'...
remote: Counting objects: 3773, done.
remote: Compressing objects: 100% (3663/3663), done.
remote: Total 3773 (delta 12), reused 335 (delta 1), pack-reused 0
Receiving objects: 100% (3773/3773), 3.05 MiB | 577.00 KiB/s, done.
Resolving deltas: 100% (12/12), done.
Checking connectivity... done.
Tapped 3651 formulae (3,800 files, 9.5M)
Warning: /home/ubuntu/.linuxbrew/bin is not in your PATH.
==> Installation successful!
==> Next steps
Install the Linuxbrew dependencies:

Debian, Ubuntu, etc.:
  `sudo apt-get install build-essential`

Fedora, Red Hat, CentOS, etc.:
  `sudo yum groupinstall 'Development Tools'`

See http://linuxbrew.sh/#dependencies for more information.

Add to your ~/.zshrc by running
  echo 'export PATH="/home/ubuntu/.linuxbrew/bin:$PATH"' >>~/.zshrc
  echo 'export MANPATH="/home/ubuntu/.linuxbrew/share/man:$MANPATH"' >>~/.zshrc
  echo 'export INFOPATH="/home/ubuntu/.linuxbrew/share/info:$INFOPATH"' >>~/.zshrc

We recommend you install GCC by running `brew install gcc`.
Run `brew help` to get started
Further documentation: https://git.io/brew-docs
==> Homebrew has enabled anonymous aggregate user behaviour analytics
Read the analytics documentation (and how to opt-out) here:
  https://git.io/brew-analytics

Затем добавляем пути в ~/.zshrc:

$ echo 'export PATH="/home/ubuntu/.linuxbrew/bin:$PATH"' >> ~/.zshrc
$ echo 'export MANPATH="/home/ubuntu/.linuxbrew/share/man:$MANPATH"' >> ~/.zshrc
$ echo 'export INFOPATH="/home/ubuntu/.linuxbrew/share/info:$INFOPATH"' >> ~/.zshrc

Перезапускаем zsh:

$ source ~/.zshrc

И всё, теперь можно перейти в проект и выполнить команду brew bundle. Все необходимые зависимости для вашего проекта будут установлены.

Класс Set и уникальные коллекции объектов

Thu, 31 Mar 2016 18:00:00 +0000

На одном проекте мне понадобилось получать список форматов для баннеров из одной рекламной платформы. Задача с виду простая, но возникла одна проблема - список форматов приходит не уникальный. Для решения этой проблемы я решил использовать встроенный в Ruby класс Set и немного DDD.

Итак, по порядку.

Список форматов мы будем получать по API, для этого создадим сервис:

# app/services/my_target_service.rb
class MyTargetService
  API_URL = 'https://example.com'

  def self.banner_formats
    response = RestClient.get("#{API_URL}/api/banner_formats.json")
    JSON.parse(response, symbolize_names: true)
  end
end

В ответ нам приходит массив примерно следующего вида:

[
  {
    :id => 1,
    :status => 'active',
    :name => 'Format 1',
    :description => '...',
    :width => 240,
    :height => 400
  },
  {
    :id => 1,
    :status => 'active',
    :name => 'Format 1',
    :description => '...',
    :width => 240,
    :height => 400
  },
  {
    :id => 2,
    :status => 'inactive',
    :name => 'Format 2',
    :description => '...',
    :width => 1080,
    :height => 607
  }
]

Как видно из примера, форматы в списке повторяются. Воспользуемся классом Set, чтобы сделать этот список уникальным:

# app/services/my_target_service.rb
require 'set'

class MyTargetService
  API_URL = 'https://example.com'

  def self.banner_formats
    response = RestClient.get("#{API_URL}/api/banner_formats.json")
    formats = JSON.parse(response, symbolize_names: true)

    banner_formats = Set.new
    formats.each do |format|
      banner_formats << format
    end

    banner_formats
  end
end

Для удобства работы, обернем каждый формат в отдельную сущность. Для этого создадим класс BannerFormatEntity:

# app/entities/banner_format_entity.rb
class BannerFormatEntity
  attr_reader :format

  def initialize(format)
    @format = format
  end

  def id
    format[:id]
  end

  def name
    format[:name]
  end

  def description
    format[:description]
  end

  def size
    "#{format[:width]}x#{format[:height]}"
  end
  
  def active?
    format[:status] == 'active'
  end
end

Теперь обновим наш сервис, чтобы использовать класс BannerFormatEntity. Так же добавим условие, чтобы в списке были только активные форматы:

# app/services/my_target_service.rb
require 'set'

class MyTargetService
  API_URL = 'https://example.com'

  def self.banner_formats
    response = RestClient.get("#{API_URL}/api/banner_formats.json")
    formats = JSON.parse(response, symbolize_names: true)

    banner_formats = Set.new
    formats.each do |format|
      banner_format = BannerFormatEntity.new(format)
      banner_formats << banner_format if banner_format.active?
    end

    banner_formats
  end
end

Остается последний штрих. Для того чтобы Set мог определять уникальность наших объектов, необходимо определить в классе BannerFormatEntity 2 метода: Object#eql? и Object#hash.

# app/entities/banner_format_entity.rb
class BannerFormatEntity
  attr_reader :format

  def initialize(format)
    @format = format
  end

  def id
    format[:id]
  end

  def name
    format[:name]
  end

  def description
    format[:description]
  end

  def size
    "#{format[:width]}x#{format[:height]}"
  end

  def active?
    format[:status] == 'active'
  end
  
  def eql?(other)
    id == other.id
  end
  
  def hash
    id.hash
  end
end

Вот таким простым и элегантным способом, мы решили нашу задачу с получением уникального списка форматов для баннеров. Сервис MyTargetService отправляет запрос к API рекламной площадки и возвращает уникальную коллекцию объектов BannerFormatEntity.