4

Being Flexible in Travis Stages with References

 2 years ago
source link: https://blog.travis-ci.com/2021-09-10-flexible
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Being Flexible in Travis Stages with References

Sep 10, 2021 |

Montana Mendy

| news

TCI-Graphics for AdsBlogs (1) copy

Deployment or asset publication happens on select configurations (e.g., after non-debug aka non-verbose builds), it only takes even me, just missing one member of any stage to subtly break the pipeline and introduces visual clutter that YAML has a hard time parsing. Anchors have been in the YAML spec for quite some time, but not all CI providers have support for Anchors, here at Travis we embrace a modern implementation of YAML. Let’s get our Anchors going and parse something similar in this blog post.

Anchors and Extensions

When building in YAML, these are normally negative qualities in a configuration that I will show you below, now our present situation is one where where we’re going to use two of YAML’s unusual and lesser-known features, and rarely you’ll see this utilized in a .travis.yml, these features are called Anchors and Extensions.

To get started, let me give you a couple of YAML examples. You use anchors and aliases like so:

_template: &_template
  key: value
  other_key: other_value
real_config:
- <<: *_template
  other_key: overridden_value
  new_key: new_value
- <<: *_template
  different_key: different_value
- *_template

Which equates to:

real_config:
- key: value
  other_key: overridden_value
  new_key: new_value
- key: value
  other_key: other_value
  different_key: different_value
- key: value
  other_key: other_value

You’ll see in the above example I wrote out I used key-value pairs. as an example. Fundamentally, a file written in YAML consists of a set of key-value pairs. Each pair is written as key: value, where whitespace after the : is optional, and in Travis you can obviously give conditionals.

Usage

Anchors are really similar to the programming language C, here’s a quick sample for reference:

foo: &bar travis
bar: *bar

This is read through the interpeter as:

foo: travis
bar: travis

Let’s inject an anchor blob in our .travis.yml config:

blob: &blob
  bar: travis

foo:
  <<: *blob

This is the same as:

blob:
  bar: travis

foo:
  bar: travis

Example .travis.yml file

Synchornizing Anchors, Extensions and Blobs, we can use references and anchors to beautifully and almost artistically set our .travis.yml file. This is not only cleaner for YAML, but for also the end user reading the YAML file, here’s the example YAML file using Anchors, and Extensions I’ve created:

---
language: cpp
os: linux
dist: xenial

linux-ppc64le: &linux-ppc64le
  os: linux-ppc64le

linux-s390x: &linux-s390x
  os: linux
  arch: s390x
  dist: bionic

jobs:
  include:
    - <<: *linux-ppc64le
      compiler: gcc
    - <<: *linux-ppc64le
      compiler: clang
    - <<: *linux-s390x
      compiler: gcc
    - <<: *linux-s390x

script: true

We can also add addons on certain hooks, here’s an example:

---
_build:
  stage: montana
  language: cpp
  addons:
    apt:
      packages:
        - gcc
        - chromaprint
        - netif

Conclusion

As you can see this is a more formattable way to write your .travis.yml, and it’s using little lesser known functions of YAML.

If you have any questions please email me at [email protected] and I’ll answer any and all questions!

Happy building!


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK