add agent point

[mat1e]

Link to #150

Add agent_point with :

• agent_name : name of the agent
• agent_label : label of the agent

[asimell]

I feel like adding a completely new measurement is a slight overkill for effectively 1 new metric (build_agent_name is already available in jenkins_data). What is the benefit of this new measurement compared to just adding the agent label as a new metric for jenkins_data as well? And is there any other relevant data one could collect from the agent other than the name and label? I'm having a hard time grasping what is the overall use case of having such a tiny measurement.

[mat1e]

In agent_datas, you can find all agents called by the pipeline. I tried to get others informations like the time the build use the agent but I didn't find a way to get it yet. Because the agents are already removed (in case of cloud agents). For now the only benefit is to have all agents names and label used by a pipeline.

[asimell]

Could you also add unit tests to demonstrate this behaviour? Currently the tests only test with one agent, which is exactly the same behaviour as the build_agent_name in jenkins_data. What this looks like to me is that you're writing multiple points on the same timestamp, which in InfluxDB results into overwriting data. For example, with RobotFrameworkPointGenerator we need to manually set the timestamp, so that data is not overwritten and I think something similar is needed here.

[mat1e]

Could you also add unit tests to demonstrate this behaviour? Currently the tests only test with one agent, which is exactly the same behaviour as the build_agent_name in jenkins_data. What this looks like to me is that you're writing multiple points on the same timestamp, which in InfluxDB results into overwriting data. For example, with RobotFrameworkPointGenerator we need to manually set the timestamp, so that data is not overwritten and I think something similar is needed here.

You're right, we just tested and datas are overwrited... I will do the modifications.

[asimell]

The plugin contains a class called TimeGenerator, which you can use to iterate 1 nanosecond onwards to get a different timestamp, so the easiest way to avoid data overwrite would be to do something like this

TimeGenerator generator = new TimeGenerator(timestamp);
for (...) {
    long time = generator.next();
    Point point = BuildPoint("measurement", customPrefix, build, time)
   ...;
}

[mat1e]

The plugin contains a class called TimeGenerator, which you can use to iterate 1 nanosecond onwards to get a different timestamp, so the easiest way to avoid data overwrite would be to do something like this

TimeGenerator generator = new TimeGenerator(timestamp);
for (...) {
    long time = generator.next();
    Point point = BuildPoint("measurement", customPrefix, build, time)
   ...;
}

It is not good with an unique_id ? I don't want to corrupt the datas...

[asimell]

A unique ID tag works as well. Just pointing out a solution for not reinventing the wheel, but you had already done your own solution. 😊

[HabibMAALEM]

A unique ID tag works as well. Just pointing out a solution for not reinventing the wheel, but you had already done your own solution. 😊

A unique_id tag such an incremental number is suitable for this case (especially for performance), example :

unique_id=1
unique_id=2

[asimell]

LGTM