feat: support yml anchors during push command

[vigneshshanmugam]

• fix yaml anchor support for lightweight monitors #888
• YAML anchors help with DIY principle when same multiple monitors have similar structure. When users are maintaining a large number of monitors, this becomes super handy.

[devcorpio]

code LGTM

Edit: I will test it manually and let you know

[devcorpio]

TL;DR: testing panned out 🚀, so LGTM 🎉

btw, at the end you will see an observations section I added, let me know what you think:

Details:

YML used:

http-type: &http-type
  type: http
schedule5: &schedule-1
  schedule: '@every 1m'
team-tag: &team-tag
  tags:
    - team1
    - team2

heartbeat.monitors:
- id: http1
  name: "http1"
  schedule: '@every 1m'
  <<: *http-type
  <<: *team-tag
  urls: "https://elastic.github.io/synthetics-demo/"
- id: http2
  name: "http2"
  <<: *http-type
  <<: *schedule-1
  urls: "https://elastic.co"
- id: tcp1
  name: "tcp1"
  type: tcp
  <<: *schedule-1
  hosts: ["www.elastic.co:443"]

case 1: results of using the YML anchor in a branch without the new code changes

I tested out of curiosity. Above, you can see what the CLI displayed.

The interesting thing is that in Kibana I was able to see two monitors (although they have been created as journeys rather than http), see below:

case 2: results of using the YML anchor in the PR's branch

since http1 and http2 were created as journeys in the previous step. Now we can see the following when executing the command:

This is a good signal since that tells us the new logic is involved 🚀

Now, after removing all monitors and starting afresh, the CLI shows this:

Besides, on this Kibana page we can see clearly how things have been set as expected:

I also tested pushing the same YML again (without any changes):

all good, too.

I also tested pushing the YML with a little variation (changing the URL of the TCP monitor):

everything is okay as well.

OBSERVATIONS

1. Perhaps not super important, but when writing the YML, VS code was complaining about duplicated keys:

Display related to:

Should we document this or mention it somehow? Maybe it's not important I'm not sure, but wanted to highlight it. It doesn't affect the functionality at all.

2. Uploading a TCP monitor with a host that is "malformed" such as "https://elastic.co" (it should be elastic.co:443) makes the monitor fail, which makes sense, but what caught my attention is that in the UI it says that the URL is unavailable:

which seems weird, at the beginning I thought that the YML wasn't working and that the URL was empty.

But after updating to the proper value (elastic.co:443), I started seeing the URL set again:

again, just something that wanted to highlight, perhaps is an intended behaviour

3. I will update the unit test, although it works, I believe that we should use all the required fields for each monitor type. For instance, urls and hosts, saying mainly because tests can also be a good place where to extract examples from, just a nitpick thingy 😄

edit: commit

edit2: oh no, now my approval is useless because I pushed code, @emilioalvap will need your review too 🚀

[vigneshshanmugam]

@devcorpio Thanks for the through tests 🎉

Regarding the VScode thing, we really don't control that and its the YML formatting/extension that throws these lint errors. We can discard them as its up to the library to handle these.

[emilioalvap]

LGTM