Categories
DevOps

Start using GitHub Dependabot

GitHub bought a service called Dependabot a while back and is now integrating this service as a GitHub Application into the ecosystem. This allows GitHub users to automatically do dependency management and get alerted when a security-related update has been found. For now, his service is still in beta but can be added to all service plans.

Let start simple and creating .github/dependabot.yml with the content below will tell Dependabot to scan all your GitHub workflows daily for GitHub Actions that are defined and have a newer release available. It will also create a pull-request that can be merged when approved.

---
version: 2
updates:
  - package-ecosystem: github-actions
    directory: "/"
    schedule:
      interval: daily
      time: "04:00"
    open-pull-requests-limit: 10

A daily scan seems to be fine and is only limited to 10 open pull requests, but if you have many repositories to maintain, then this task can become daunting. Luckily Dependabot is aware of pull-requests that are still open and will update them if a new dependency update is found. Then still just going for a weekly or even monthly scan can be a better fit for your workflow. The example below runs every Friday and gives you an idea of what your work for the next week will be.

---
version: 2
updates:
  - package-ecosystem: github-actions
    directory: "/"
    schedule:
      interval: weekly
      day: friday
    open-pull-requests-limit: 10

Dependabot can maintain dependencies for many ecosystems and the example below is one I use for my development containers in VSCode and GitHub CodeSpaces. It scans for Dockerfile to see if the base image is outdated, and it also scans Python dependencies for any know updates.

---
version: 2
updates:
  - package-ecosystem: docker
    directory: "/"
    schedule:
      interval: weekly
      day: friday
    open-pull-requests-limit: 10

  - package-ecosystem: pip
    directory: "/"
    schedule:
      interval: weekly
      day: friday
    open-pull-requests-limit: 10

  - package-ecosystem: github-actions
    directory: "/"
    schedule:
      interval: weekly
      day: friday
    open-pull-requests-limit: 10

These examples are only a small introduction to using Dependabot and many more options and package ecosystems are available. But for most people, this is enough to get started before thinking about a complex Semantic Versioning oriented updating strategy.

Categories
System Administration

Using bare variables in Ansible 2.8

Ansible 2.8 was released in May 2019 and later in May came to Fedora 30 in package form. So the first tests could be done to see what needed to be done to switch from 2.7 to 2.8 and don’t generate a lot of stopped GitLab CI-jobs due to new warnings and errors. So let start with one warning that needs to be resolved before the 2.12 release and also is given on many third-party roles.

- name: Enable EPEL repository
  package:
    name: epel-release
    state: present
  when: platform_repo_epel

The example code above is simple enough to get the warning about CONDITIONAL_BARE_VARS. We could opt for disabling the warning in ansible.cfg and move forward, but as this is the technical debt we don’t want to get more and resolve the current debt as quickly as possible.

TASK [role.platform : Enable EPEL repository] *******************************
[DEPRECATION WARNING]: evaluating platform_repo_epel as a bare variable, this 
behaviour will go away and you might need to add |bool to the expression in the
 future. Also see CONDITIONAL_BARE_VARS configuration toggle.. This feature 
will be removed in version 2.12. Deprecation warnings can be disabled by 
setting deprecation_warnings=False in ansible.cfg.

First, we try to resolve this technical debt in the traditional way and making it a Boolean comparison and this stops Ansible from complaining as it is not a bare variable anymore.

- name: Enable EPEL repository
  package:
    name: epel-release
    state: present
  when: platform_repo_epel == True

Now Ansible lint starts to give a notification, added in version 4.0.0, as you shouldn’t do a Boolean comparison this was. And while it is technically correct, we also want this linting notification gone to pass the CI-pipeline.

[601] Don't compare to literal True/False
/path/to/ansible/project/roles/platform/tasks/main:6
  when: platform_repo_epel == True

In the original message from Ansible there was already a hit on how to resolve this and by adding a Boolean filter both Ansible keeps on running correctly and Ansible lint is also happy.

- name: Enable EPEL repository
  package:
    name: epel-release
    state: present
  when: platform_repo_epel|bool

While these kinds of modifications seem non-trivial and a test in your CI-pipeline could easily be set to “allow_failure=true”, but it makes code more readable for yourself and others.