Create service_access_tokens table

What does this MR do and why?

Introduce a table to store JWT tokens for Code Suggestions on SM instances.

In this MR, the table & the model is no-op, we just preparing the ground via small MRs.

See #416996 (closed)

How to set up and validate locally

Run the migration.

In rails c, check that the table exists and is accessible via the model:

[1] pry(main)> ::Ai::ServiceAccessToken.count
  Ai::ServiceAccessToken Count (0.5ms)  SELECT COUNT(*) FROM "service_access_tokens" /*application:console,db_config_name:main,console_hostname:Alekseis-MBP-2.home,console_username:al,line:(pry):1:in `__pry__'*/
=> 0
[2] pry(main)>

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

Related to #416996 (closed)

changed milestone to %16.2

added cloud connectoractive devopsdata stores groupcloud connector maintenancerefactor sectioncore platform typemaintenance workflowin dev labels

assigned to @alipniagov and @rzwambag

assigned to @rzwambag

added 1 commit

• e5d5f894 - Create ai_access_tokens table

Compare with previous version

added backend database databasereview pending documentation labels

	1 Warning
	6de82ab8: The commit body should not contain more than 72 characters per line. For more information, take a look at our Commit message guidelines.

	1 Message
	This merge request adds or changes documentation files. A review from the Technical Writing team before you merge is recommended. Reviews can happen after you merge.

Documentation review

The following files require a review from a technical writer:

• db/docs/service_access_tokens.yml (Link to current live version)

The review does not need to block merging this merge request. See the:

• Metadata for the *.md files that you've changed. The first few lines of each *.md file identify the stage and group most closely associated with your docs change.
• The Technical Writer assigned for that stage and group.
• Documentation workflows for information on when to assign a merge request for review.

Reviewer roulette

Changes that require review have been detected!

Please refer to the table below for assigning reviewers and maintainers suggested by Danger in the specified category:

Category	Reviewer	Maintainer
backend	Gregorius Marco (@marcogreg) (UTC+8, 6 hours ahead of @alipniagov)	Laura Montemayor (@lauraX) (UTC+2, same timezone as @alipniagov)
database	Dmytro Biryukov (@dbiryukov) (UTC+2, same timezone as @alipniagov)	Michał Zając (@Quintasan) (UTC+2, same timezone as @alipniagov)
~"migration"	No reviewer available	No maintainer available

To spread load more evenly across eligible reviewers, Danger has picked a candidate for each review slot, based on their timezone. Feel free to override these selections if you think someone else would be better-suited or use the GitLab Review Workload Dashboard to find other available reviewers.

To read more on how to use the reviewer roulette, please take a look at the Engineering workflow and code review guidelines. Please consider assigning a reviewer or maintainer who is a domain expert in the area of the merge request.

Once you've decided who will review this merge request, assign them as a reviewer! Danger does not automatically notify them for you.

If needed, you can retry the danger-review job that generated this comment.

Generated by Danger

added Data WarehouseImpact Check label

marked the checklist item I have evaluated the MR acceptance checklist for this MR. as completed

Allure report

allure-report-publisher generated test report!

e2e-test-on-gdk: test report for fe85bc1e

expand test summary

+-----------------------------------------------------------------------+
|                            suites summary                             |
+------------------+--------+--------+---------+-------+-------+--------+
|                  | passed | failed | skipped | flaky | total | result |
+------------------+--------+--------+---------+-------+-------+--------+
| Create           | 6      | 2      | 1       | 6     | 9     | ❌     |
| Govern           | 2      | 0      | 0       | 0     | 2     | ✅     |
| Monitor          | 4      | 0      | 0       | 3     | 4     | ❗     |
| Manage           | 1      | 0      | 0       | 0     | 1     | ✅     |
| Plan             | 4      | 0      | 0       | 4     | 4     | ❗     |
| Framework sanity | 0      | 0      | 1       | 0     | 1     | ➖     |
| Data Stores      | 2      | 0      | 0       | 0     | 2     | ✅     |
+------------------+--------+--------+---------+-------+-------+--------+
| Total            | 19     | 2      | 2       | 13    | 23    | ❌     |
+------------------+--------+--------+---------+-------+-------+--------+

marked this merge request as ready

Based https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/7745/diffs#2ee02bdbb86d17e4ab6f90bf1efcd9ae6f5a850b_194_194, @rzwambag do you think we should add the "category/kind" (can't use 'type') of the token as, for example, enum field into our table?

We'll start with :code_suggestions only, but from MK's MR I've got an impression he prepares for the future scenarios where we'll receive a bunch of tokens of various types. On the one side, it may be premature consideration, on the other side -- it is not much of a change for us to do now.

added 1 commit

• 656af033 - Add category to ai_access_tokens table

Compare with previous version

added 1 commit

• b3d588bf - Add category to ai_access_tokens table

Compare with previous version

added 1 commit

• e6e3ace8 - Add category to ai_access_tokens table

Compare with previous version

added 1 commit

• acd0a156 - Add category to ai_access_tokens table

Compare with previous version

@mkaeppler Could you please do backend review?
@nmilojevic1 Could you please perform a database review?
Thanks!

requested review from @mkaeppler

requested review from @nmilojevic1