### Problem to solve #### Current status of Jaeger setup It's possible to deploy application to different environments as a part of GitLab's CI/CD. It's possible to setup GitLab to show information from Jaeger for production environment via GitLab web interface #### Problem A: non-production tracing Unfortunately sometimes it's not possible to allow non-production environment to send tracings to production's jaeger. From the other side it may be very useful to review tracings for Staging/Review App/etc to understand root causes for the issues. #### Problem B: custom Jaeger link per deployment During deployment it's possible that Jaeger instance may migrate to different location/link. In that case User have to manually change link to the tracer via web site which limits speed of changes propagation to all project's team members and create possibility for incorrect tracer configuration due to required manual action. ### Intended users * Users of Review App feature who are interested in traces for different environments (stage, Review App, etc.) * Users who would like to deploy Jaeger as a part of their project deploy ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> * add option to specify Jaeger per environment instead of per project * add option to provide a link to Jaeger as a part of CI/CD job (like it done for url and environment's name) ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? --> The same model which is used to setup environment's url as a part of CI/CD job ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements --> #### .git-lab.ci reference doc environment:jaeger_link Provide a link to Jaeger server for the environment ### Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/ --> TBD ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> Metric: amount of project used the feature vs. amount of project with manual Jaeger setup via web site ### Links / references