Feature/retrieve debug information

[victorpablosceruelo]

Suppose we could have a test that takes as input the url to a job in production, take from it the real values it uses and run the important (and problematic to test) parts of the shared library using that values.

This is what we propose to do. Here we only have the part in which we save the important values of a pipeline execution into a text file that we can easily retrieve from a test. Retrieving this test file as input data and the output of the pipeline allows us to compare results between current implementation in production and current development version of shared library.

This development started during the docGen refactor, task in which we invested a lot of effort and which was left appart because we had no way to justify what was still missing.

The first usage we have in mind is comparing the result of a pipeline without the docGen refactor and the result of a pipeline with it implemented, so we can compare results of multiple calls to docGen from the shared library.

It is rather interesting to include it in master before refactors like the ones proposed in:

https://github.com/opendevstack/ods-jenkins-shared-library/tree/feature/afterMoveLevaDoc

https://github.com/opendevstack/ods-document-generation-svc/tree/feature/moveLevaDoc

The only drawback of this proposal is that it generates another file in the pipeline that needs to be stored by Jenkins if jenkins keep executions of pipelines, but the size of this file is less than 1/2 mb.

[victorpablosceruelo]

I would like to have a discussion on the contents of this PR.

It would be an improvement to have it into master and being able to export information from pipelines using previous versions and compare results to new ones.

Maybe the idea of keeping the files in Jenkins is not good enough (we might be able to find another place to store them) and the idea of running it always is not good enough too, but I think that the idea of being able to ensure that after a change the resulting documents are similar enough is something we need.

@jorge-romero @jafarre-viewnext, what do you think about this?