Skip to content
GitLab
Next
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 44,761
    • Issues 44,761
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1,329
    • Merge requests 1,329
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • GitLabGitLab
  • Issues
  • #360266
Closed
Open
Issue created Apr 22, 2022 by Ben Prescott @bprescott_↙ ☺@bprescott_🌴Developer

project create API: calls with both 'import_url' and '"initialize_with_readme": "true"' now fail

Summary

A customer reported that after upgrading from 14.3 to 14.9 API calls that the used to create projects had stopped working, failing with:

  "import_error": "Unable to save project. Error: 5:GetRepoPath: not a git repository: \"/var/opt/gitlab/git-data/repositories/@hashed/73/47/73475cb40a568e8da8a045ced110137e159f890ac4da883b6b17dc651b3a8049.git\".",

The path referred to is the one that would have been created for this new project.

From their logs, I noticed they were passing initialize_with_readme": "true" as well as an HTTPS import url "import_url": "https://user:token@gitlab.example.com/templates/someproject.git"

Setting initialize_with_readme to false resolved this. I tested this on 13.12, and confirmed their finding that this used to work OK.

I suspect some other change in the application has caused this combination of parameters to fail, whereas before import_url would take precedent over initialize_with_readme.

Alternatively, there's a race condition here, and the action that fails because of Error: 5:GetRepoPath: not a git repository sometimes gets delayed while the project is created in parallel.

GitLab team members can read more in the ticket.

Documentation revised

!85782 (merged) raised to document this issue.

Steps to reproduce

  1. This has been verified on GitLab 14.9
  2. Create a project via import. This should succeed. Substitute <TOKEN> twice, the plus the other USER, new project project and namespace details.
curl --request POST --header "PRIVATE-TOKEN: <TOKEN>" --header "Content-Type: application/json"  \
--data '{"name": "<projectname>", "description": "<project description>", "path": "<projecthandle>", "namespace_id": "<namespaceID>", "import_url": "https://<USER>:<TOKEN>@gitlab.example.com/group/template.git", "initialize_with_readme": "false"}'   \
"https://gitlab.example.com/api/v4/projects/" | jq .
  1. Switch "initialize_with_readme" to true and try again. This will fail to complete.

I've verified that both [2] and [3] would be successful on 13.12 - so this used to work.

Example Project

What is the current bug behavior?

It's reasonable that initialize_with_readme and import_url are mutually exclusive, because it's then ambiguous whether it should be an emptyish project or an imported one.

But this should be picked up by validation. The parameters should get passed to the back end and fail for an arbitrary reason.

Projects gets partly created: image image

What is the expected correct behavior?

Validate the supplied parameters.

Relevant logs and/or screenshots

Output of checks

Results of GitLab environment info

14.9.1

Results of GitLab application Check

Possible fixes

Edited Apr 25, 2022 by Ben Prescott @bprescott_↙ ☺
Assignee
Assign to
Time tracking