X-Ray should not run as a CI job
<!--This issue template can be used as a great starting point for feature requests. The section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated using the release post item generator: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator. The remaining sections are the backbone for every feature in GitLab. The goal of this template is brevity for quick/smaller iterations. For a more thorough list of considerations for larger features or feature sets, you can leverage the detailed [feature proposal](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md).--> ### Release notes Repository X-Ray enriches code generation requests for GitLab Duo Code Suggestions by providing additional context about a project’s dependencies to improve the accuracy and relevance of code recommendations. This improves the quality of code generation. Previously, Repository X-Ray used a CI job that you had to configure and manage. Now, Repository X-Ray uses a background job, which is triggered when a new commit is pushed to your project’s default branch. The Repository X-Ray triggers a background job that scans and parses the applicable configuration files in your repository automatically. Documentation: https://docs.gitlab.com/ee/user/project/repository/code_suggestions/repository_xray.html ### Problem to solve X-ray currently leverages a container and CI. There are multiple problems with this. 1. It uses CI minutes, which is consumable for the customer. * For product features that relied on CI minutes, we are generally moving away from these consumables. For example, dependency and container scanning now run in the background and continuous update based on the relevant changes. 2. Customers expect that this is just something that happens, not something that they need to configure and make sure is added to their `.gitlab-ci.yml` config or add a scheduled pipeline to make sure that any changes are caught by X-Ray. 3. Licensing has proven difficult, as there is a mismatch of users who have a Duo seat vs. groups/projects for orgs that purchased Duo, but not everyone running a CI job may have a seat assigned. Customers expect X-Ray to be tied to their namespace/instance, not to specific users. Because of all of these, we need to move x-ray scanning away from CI jobs. ### Proposal <!--Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues.--> Phase 1: Reduce the number of CI minutes used. - Do not run the LLM when no files have changed - Test: Do not use LLM at all - do we need the package descriptions? - Move the LLM processing to a background job Phase 2: Remove X-Ray from CI jobs altogether - Investigate options for running X-Ray as a scheduled service once a day ### Issues implementation order 1. https://gitlab.com/gitlab-org/gitlab/-/issues/467340+ 2. ~~https://gitlab.com/gitlab-org/gitlab/-/issues/467341+~~ 3. https://gitlab.com/gitlab-org/code-creation/repository-x-ray/-/issues/34+ ### Standalone issues * https://gitlab.com/gitlab-org/gitlab/-/issues/467357+ ### Rollout / Communication Issues * https://gitlab.com/gitlab-org/gitlab/-/issues/490553+ * https://gitlab.com/gitlab-org/gitlab/-/issues/490552+ * https://gitlab.com/gitlab-org/gitlab/-/issues/486518+ * https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/136723+ * Deprecation issue: https://gitlab.com/gitlab-org/gitlab/-/issues/500146+ * Updated [Deprecations](https://docs.gitlab.com/ee/update/deprecations.html#deprecate-ci-job-implementation-of-repository-x-ray) page via https://gitlab.com/gitlab-org/gitlab/-/merge_requests/170151
epic