[Bug][Sonarcloud] Error 1406 (22001): Data too long for column 'project_key' at row 1

[klemen-df]

Search before asking

• [X] I had searched in the issues and found no similar issues.

What happened

When running:

SonarQube:Xyyyzzz_xyyyzzz.data-service.device-parameters-manager_AY51PdzPWFjHTJF4SDr_

I received

subtask convertIssues ended unexpectedly Wraps: (2) Error 1406 (22001): Data too long for column 'project_key' at row 1 (500) Wraps: (3) Error 1406 (22001): Data too long for column 'project_key' at row 1 Error types: (1) *hintdetail.withDetail (2) *hintdetail.withDetail (3) *mysql.MySQLError

What do you expect to happen

Sonarcloud task should run succesfully

How to reproduce

Integrate sonarcloud and run task

Anything else

No response

Version

v1.0.1-beta1

Are you willing to submit PR?

• [ ] Yes I am willing to submit a PR!

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[dosubot[bot]]

To resolve the "Data too long for column 'project_key'" error when running a Sonarcloud task, you need to expand the ProjectKey column size in the database. The provided migration script expandProjectKey20230206 does exactly that by transforming the ProjectKey column from varchar(64) to varchar(255) in the _tool_sonarqube_projects table and from varchar(100) to varchar(255) in the _tool_sonarqube_issues table.

Here is the relevant part of the migration script:

type expandProjectKey20230206 struct{}

func (script *expandProjectKey20230206) Up(basicRes context.BasicRes) errors.Error {
    // expand `ProjectKey` from varchar(64) to varchar(255)
    err := migrationhelper.TransformTable(
        basicRes,
        script,
        "_tool_sonarqube_projects",
        func(s *SonarqubeProject20230206Before) (*SonarqubeProject20230206After, errors.Error) {
            dst := (*SonarqubeProject20230206After)(s)
            return dst, nil
        },
    )
    if err != nil {
        return err
    }

    // expand `ProjectKey` from varchar(100) to varchar(255)
    err = migrationhelper.TransformTable(
        basicRes,
        script,
        "_tool_sonarqube_issues",
        func(s *SonarqubeIssue20230206Before) (*SonarqubeIssue20230206After, errors.Error) {
            dst := (*SonarqubeIssue20230206After)(s)
            return dst, nil
        },
    )
    if err != nil {
        return err
    }

    // also, SonarqubeFileMetrics and SonarqubeHotspot have ProjectKey.
    // But I think varchar(191) in mysql and text in pg is enough.
    return nil
}

To apply this migration, ensure that the migration script is executed in your environment. This will update the column sizes and resolve the "Data too long for column 'project_key'" error ^[1].

To continue talking to Dosu, mention @dosu.

[klemen-df]

Hm, seems that some of the migrations weren't applied. Any suggestions how to do it now (deployed to k8s with helm chart)?

[dosubot[bot]]

To ensure that the expandProjectKey20230206 migration is applied correctly in your Kubernetes setup deployed with a Helm chart, follow these steps:

1. Include the Migration Script in Your Helm Chart: Ensure that the migration script expandProjectKey20230206 is part of your application's codebase and is included in the Docker image used by your Kubernetes deployment.

2. Run Migrations on Startup: Modify your application's entrypoint or startup script to run database migrations before starting the application. This can be done by adding a command to execute the migration scripts.

3. Helm Chart Configuration: Update your Helm chart to include the necessary configuration for running migrations. This might involve adding an init container or a pre-start hook to run the migrations.

Here is an example of how you might modify your Helm chart to include a pre-start hook for running migrations:

apiVersion: batch/v1
kind: Job
metadata:
  name: run-migrations
spec:
  template:
    spec:
      containers:
      - name: migrate
        image: your-application-image:latest
        command: ["sh", "-c", "your-migration-command"]
      restartPolicy: Never

Replace your-application-image:latest with the actual image of your application and your-migration-command with the command to run your migrations.

4. Verify Migration Execution: Ensure that the migration job runs successfully and the changes are applied to the database. You can check the logs of the migration job to verify this.

By following these steps, you can ensure that the expandProjectKey20230206 migration is applied correctly in your Kubernetes setup deployed with a Helm chart ^[1].

To continue talking to Dosu, mention @dosu.

[d4x1]

@klemen-df Check field project_key's type in table _tool_sonarqube_projects, it should be VARCHAR(255).

You can modify it directly, or deploy a new instance and see what will happen.

[klemen-df]

huh, interesting

[d4x1]

@klemen-df Check the actual length of project_key. Is it longer than varchar(255)?

[klemen-df]

Hm, not really

sonarqube:SonarqubeProject:1:Xyyyyyy_xyyyyyy.data-service.device-parameters-manager_AY51PdzPWFjHTJF4SDr_