I just realized now all the dashboard screenshots are not up to date grimacing Just the names of the visualizations are different so hopefully it's ok.

I also hope this is ok 😬 I wouldn't change all the screenshots now.

Dashboards using custom titles for visualizations wouldn't be affected, but not all of them are using this feature.

I left a similar comment in #13215, I think it would be nice to add this to dev-tools/mage/target/common and then update each project to

import (
...

	// mage:import
	_ "github.com/elastic/beats/dev-tools/mage/target/common"
)

which will help reduce duplication.

@andrewkroh I had tried, but I found some conflicting targets, and that Check depended on Update in some magefiles, so I postponed it. But now checking again I have discovered RegisterCheckDeps() to inject the Updates. So with this, and removing the conflicting targets, all good 🙂

All magefiles use the common targets now.

Once we have this merged I will update #13215, that has more things.

@andrewkroh there were a couple of legit issues in CI, I think I have solved them. One was caused by the different python envs mage and make use under the same PYTHON_ENV. This may need another quick review.

Hey, this change broke apm-server.
I understand that it can be hard to remember what might break apm-server, but https://beats-ci.elastic.co/job/elastic+apm-server+master+beats-update/ runs periodically on master and should provide feedback.
Now, it looks like that job is permanently broken... did anyone raise the alarm, or it is not really being used?

Would it be better to run that job on every pr touching libbeat code instead?

Hey @jalvz,

I am very sorry. Actually I didn't know (or remember) that there was a build of apm-server running with the last version of libbeat.

I can take a look to what is failing after this PR if nobody is working on it, or I can help if someone is already on it.

Would it be better to run that job on every pr touching libbeat code instead?

This would be something to discuss, but it would be definitely helpful to have some way of knowing when libbeat breaks apm-server builds.

No worries, that is understandable - it is why i suggest to run it on libbeat prs (also for future beats contributors, etc)

it would be definitely helpful to have some way of knowing when libbeat breaks apm-server builds.

The conservative answer is that breaking changes on a libbeat Makefile or exported functions might break us. It practical terms, most of the times it happens with make / mage changes.

The only automated way we have to check is by running on beats CI the same command we run locally to update beats. Adding that stage would bump build times ~15 minutes, that is why you have it running only on master - but then it can get forgotten about.

Maybe a good middle ground is to trigger that stage only upon changes on devtools/mage* and libbeat/scripts/Makefile

What do you think?

The only automated way we have to check is by running on beats CI the same command we run locally to update beats. Adding that stage would bump build times ~15 minutes, that is why you have it running only on master - but then it can get forgotten about.

I guess this can be run in parallel, so it doesn't affect the total time of builds.

Maybe a good middle ground is to trigger that stage only upon changes on devtools/mage* and libbeat/scripts/Makefile

What do you think?

That sounds reasonable, this way we'd force ourselves to make changes in a more backwards compatible way.