• 27
    • We collect Bitbucket feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      It would be awesome if we could modify Git LFS settings on repositories through the REST API, definitely something i'm missing at the moment.

      Something like:

      http://example.com/rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/settings/lfs
      
      

      or simply a property in the creation of the repo

          Form Name

            [BSERV-8935] Change Git LFS settings through REST API

            nuetzig added a comment -

            @Daniel Holmes: I can only agree on this.

            nuetzig added a comment - @Daniel Holmes: I can only agree on this.

            This needs to be implemented exactly as @Dave Thomas suggests.

            I'm totally baffled how the addition of any feature doesn't include adding management of it into the REST API as well.  I also suggest that you adjust your general criteria for what it takes for a Feature to be properly DONE.

            Daniel Holmes added a comment - This needs to be implemented exactly as @Dave Thomas suggests. I'm totally baffled how the addition of any feature doesn't include adding management of it into the REST API as well.  I also suggest that you adjust your general criteria for what it takes for a Feature to be properly DONE.

            +1 for the endpoints

            Gonchik Tsymzhitov added a comment - +1 for the endpoints

            @jason_kemp , you are the best–thanks for endpoint 

            Joe Del Nano added a comment - @jason_kemp , you are the best–thanks for endpoint 

            Dave Thomas added a comment - - edited

            I'm voting for this even though it's possible to use the undocumented endpoint Jason mentioned. Ideally, the LFS enabled/disabled status should be reported when retrieving information about the project's repositories via the

            /rest/api/1.0/projects/{projectKey}/repos 
            

            endpoint and you should be able to get/set the attribute using the

            /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug} 
            

            endpoint.

            Overall, I have to say the BitBucket Server REST api is pretty inadequate for basic administration tasks. For example: generating a list of all repositories with the size of the repository, the date of last commit, and the LFS status requires one call to get the list of projects, on call per project to get the list of repositories, and then four separate calls to get the rest of the information (two of them using undocumented endpoints). The number of round trips required is very high, which limits the usability and it doesn't even tell you how much disk space is being used for LFS storage for each repository. For that, there's no alternative to cloning the repository and fetching all the objects.

            As an admin, I need to be able to see which repositories are being used and which aren't and be able to see how much disk space each repository is consuming. This seems like a pretty basic and reasonable requirement. It's sad that it's so difficult to retrieve this kind of information.

            Dave Thomas added a comment - - edited I'm voting for this even though it's possible to use the undocumented endpoint Jason mentioned. Ideally, the LFS enabled/disabled status should be reported when retrieving information about the project's repositories via the /rest/api/1.0/projects/{projectKey}/repos endpoint and you should be able to get/set the attribute using the /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug} endpoint. Overall, I have to say the BitBucket Server REST api is pretty inadequate for basic administration tasks. For example: generating a list of all repositories with the size of the repository, the date of last commit, and the LFS status requires one call to get the list of projects, on call per project to get the list of repositories, and then four separate calls to get the rest of the information (two of them using undocumented endpoints). The number of round trips required is very high, which limits the usability and it doesn't even tell you how much disk space is being used for LFS storage for each repository. For that, there's no alternative to cloning the repository and fetching all the objects. As an admin, I need to be able to see which repositories are being used and which aren't and be able to see how much disk space each repository is consuming. This seems like a pretty basic and reasonable requirement. It's sad that it's so difficult to retrieve this kind of information.

            Thank you @jason_kemp!

            Deleted Account (Inactive) added a comment - Thank you @jason_kemp!

            There's actually an undocumented endpoint for interacting with LFS. It's rough and clearly not polished, but it works.

            • rest/git-lfs/admin/projects/<key>/repos/<slug>/enabled

            GET will return a 200 if its enabled, 404 if it's disabled.
            PUT to enable
            DELETE to disable

            Jason Kemp added a comment - There's actually an undocumented endpoint for interacting with LFS. It's rough and clearly not polished, but it works. rest/git-lfs/admin/projects/<key>/repos/<slug>/enabled GET will return a 200 if its enabled, 404 if it's disabled. PUT to enable DELETE to disable

            It would be an improvement if we could even read the current LFS status of a repo. Currently the API doesn't report on whether a repo has LFS turned on or off. This is something administrators definitely want to know.

            Deleted Account (Inactive) added a comment - It would be an improvement if we could even read the current LFS status of a repo. Currently the API doesn't report on whether a repo has LFS turned on or off. This is something administrators definitely want to know.

              Unassigned Unassigned
              ce71f1f952f3 Kristen Schat
              Votes:
              39 Vote for this issue
              Watchers:
              37 Start watching this issue

                Created:
                Updated: