Rauf

A trick worth knowing for combining an info metric with a real one in a single query: multiply by the info series and use the label grouping to carry the labels across.

The general shape is to take your measurement and multiply it by the info metric using a grouping that keeps the identifying label. The value is unchanged because the info metric is 1, and the result now carries the extra labels.

It looks like a hack and it is the standard idiom, precisely because labels travel with the series. Once you have seen it, a lot of dashboards that seemed impossible become straightforward.

The caveat is that if the info series is ever missing for a machine, the multiplication drops that machine entirely — which is a silent gap rather than an error, and it is worth knowing when a row disappears.

Both problems are well known and both have standard answers. Take the loop first, because it is the one that will page somebody.

Break the loop. Two mechanisms, and use both:

• Skip on the commit message. Most CI systems honour a marker in the commit message that suppresses a pipeline. Put it in the message your job creates. This is the belt.
• Guard in the pipeline rules. A condition so the job cannot run on a commit authored by the automation, or only runs on the events you intend. This is the braces.

Relying only on the message marker is how people end up with a loop when somebody changes the message template.

And make the commit idempotent: if nothing changed, do not commit. A job that commits an identical file every run creates noise and, combined with any gap in the loop guard, creates the loop.

The credential. The read-only token the job gets by default is deliberate — a build should not be able to rewrite its own source, because anybody who can change the pipeline could then rewrite history or push to protected branches.

So you are widening a boundary on purpose, and the way to do it safely:

• Use a project-scoped deploy key or token with write access to this repository only. Not a personal access token belonging to a human, which is the shortcut everybody takes and which means the automation acts as that person forever, including after they leave.
• Do not let it push to protected branches. If the change needs to land on the main branch, open a merge request instead of pushing. That keeps review in the loop and is a much smaller privilege.
• Store it as a protected, masked variable, available only to runs on protected refs.

Opening a merge request rather than pushing directly solves the loop problem as a side effect, which is a good sign it is the right shape.

If you want one alert per environment, write the query with the value hard-coded and create one rule per environment. Tedious by hand, and the reason alert rules should live in configuration files rather than be clicked together — then it is a loop in a template and the tedium disappears.

If you want one alert that covers everything, drop the filter entirely and let the query return a series per environment. Alerting evaluates each returned series separately, so one rule produces one alert per environment automatically, and a new environment is covered the day it appears without anybody editing anything.

The second is almost always what people want once they see it. The variable was there to let a human narrow the view; an alert does not need to narrow, it needs to fire per thing.

The detail that makes it work is putting the identifying label into the alert's labels and message, so the notification says which environment rather than just that something is wrong.

The mental model that fixes most tangles: conditions decide whether a job exists in the pipeline, not what it does at run time. They are evaluated once, when the pipeline is created.

That distinction matters because it separates the two tools people mix:

• Pipeline rules — evaluated up front, decide inclusion. Use these for branch, tag, event type, changed paths.
• Shell conditionals inside a script — evaluated during the run, decide behaviour. Use these only for things not knowable in advance.

Mixing them is where the mess comes from. A job that always exists and then decides inside the script whether to do anything shows up as a green job that did nothing, which is why you cannot tell what ran.

Rule of thumb: if the answer is knowable when the pipeline starts, put it in the rules. Then the pipeline graph itself tells you what will happen, and you can read it instead of watching it.