AIDM-455: Generate Markdown Table of Supported Versions

[PROFeNoM]

Description

Akin to what has been made on other tracing repositories, a full record of tested versions and a markdown table of min/max supported versions will be automatically kept up to date.

A new CircleCI Job aggregate_tested_versions has been added. The latter will run on every commit made to master. It will be in charge to collect tested_versions.json artifacts from CircleCI test jobs, aggregate them, and generate a PR if necessary.

A sample PR can be seen at the following link: #3060 - (CircleCI Job).

Note that two environment variables have been added to CircleCI's settings: CIRCLECI_TOKEN and GITHUB_TOKEN. They are used to communicate with CircleCI's and Github's APIs, respectively.

As such, two "repository artifacts" will be added at the root of the repo: aggregated_tested_versions.json and integration_versions.md. The former contains all tested versions of target libraries, while the latter summarize min/max supported versions.

---

To record tested versions, a method recordTestedVersion will be called during tests' tear down.

• For composer-based library integrations (e.g., guzzle), nothing will have to be done. The logic will handle the retrieval of the target library and its currently tested version, and record it.
• For composer-based web integrations (e.g., laravel) and extensions (e.g., redis), the target library (e.g., laravel/framework or **ext-**redis) will have to be specified by overriding getTestedLibrary.
• For other cases (e.g., Wordpress), it is possible to override both getTestedLibrary and getTestedVersion with the tested library/version.

The tested_versions Makefie target will always be run at the end of integration-snapshots jobs, and generate the aforementioned tested_versions.json artifact.

Reviewer checklist

• Test coverage seems ok.
• Appropriate labels assigned.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 56.45%. Comparing base (8fac8d9) to head (4a02531).

❗ There is a different number of reports uploaded between BASE (8fac8d9) and HEAD (4a02531). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (8fac8d9)	HEAD (4a02531)
tracer-php	11	10

Additional details and impacted files

@@              Coverage Diff              @@
##             master    #3062       +/-   ##
=============================================
- Coverage     74.74%   56.45%   -18.30%     
  Complexity     2790     2790               
=============================================
  Files           112      139       +27     
  Lines         11039    15273     +4234     
  Branches          0     1043     +1043     
=============================================
+ Hits           8251     8622      +371     
- Misses         2788     6100     +3312     
- Partials          0      551      +551     

Flag	Coverage Δ
appsec-extension	68.37% <ø> (?)
tracer-php	51.87% <ø> (-22.87%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

see 48 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8fac8d9...4a02531. Read the comment docs.

[bouwkast]

Nicely done and thanks for the PR description!

I think we can refine the generated table a bit at a later date as there seem to be some tricky integrations to report here.

[bouwkast]

I see that there is a Zend Framework V2 https://docs.datadoghq.com/tracing/trace_collection/compatibility/php
But that is Generic web tracing would that mean that it is supported via HTTP call instrumentation?

[PROFeNoM]

The PHP Tracer will automatically generate a web.request root span for all incoming HTTP requests. Without further instrumentation, this is what is being called "Generic Web Tracing" for the PHP Tracer, meaning that transactions will be traced, as well as hypothetical Database calls (for instance).

On the other hand, "Framework-Level Instrumentation" offers greater information granularity based on the framework's specifics. For instance, for a MVC based framework, this would mean at least tracing the controller.

In the case of ZF2, we don't have a specific instrumentation. However, I believe that since it used to be a common PHP framework, it was included in the documentation so as to indicate that we provide some sort of support for it.

Does that answer your question? 🤔

[bouwkast]

Yep exactly does thanks!

Wondering how we best would like to represent these types of instrumentations as we have several instances here and in others.

[bouwkast]

I'll bring that question up to figure out a path, but nothing to do at the moment unless you have ideas 😅

[bouwkast]

Some of the ones that aren't here but I think should be from looking at https://docs.datadoghq.com/tracing/trace_collection/compatibility/php
e.g. curl and zendframework v2

I think my understanding is that there isn't a nice way to fit these in here, so it may require some manual effort

[PROFeNoM]

I had forgotten adding curl. My bad. However for zf2, it would indeed require manual effort.