![]() Hopefully the Azure DevOps team improves on this omission (in my opinion) soon. You can add the repo to the URL here by hand as well of course, if need be. The most amazing part: the UI will now remember the last repo you have viewed, so if you use the menu to navigate to branches, it will enable you to set branch policies. Note that the dropdown still doesn’t show the wiki repo: it never will currently If you check the name of your wiki repository, you can enter it in the URL of a normal repository (use the repo selection dropdown first for the correct URL to appear for easy changing): I’ve searched and tested some options, but I didn’t manage to update the repo and make it not hidden anymore.įinding some really old posts and a GitHub issue that requested the hidden repo to be visible (that got redirected to a UserVoice request that was closed due to inactivity □), I figured that this old URL might still be working… And luckily it is! The fix If you include the query string includeHidden=True as can be found in the API docs, you see that the wiki repo is visible:Ĭonclusion: it is a repo, but a hidden one! Note this does not include the wiki repo, only the default empty repo with the same name as the project. Go to (so organization/project/_apis/git/repositories) and you get a list of repositories. If you update the URL in your browser, you can test the API with normal GET request without setting up to much stuff. You can find the git URL for cloning you need, but not how to get to the repository to set up branch policies for example… REST APIĪzure DevOps has an awesome REST API you can use to automate almost everything in Azure DevOps, so let’s see what it returns. If you go to the wiki, it shows the name of the wiki:Įven the dropdown or extra button (the three dots) doesn’t some more information. ![]() Then I started searching for the wiki in the repos overview, but it only shows the default, empty project repository, not the wiki repo: Testing things out, I created a new team project and created a new project wiki for it. I mean, if you need this large a matrix to try and make the differences clear, while under the covers it is the same setup, why not make your product easier to use? Already confusing and the Learn more link tries to make the difference more clear, but doesn’t really make it clear it will always be a repo underneath. When you create a new project and navigate to the wiki page, you are now greeted with this screen. If the team using it is mature enough to use it as a normal repository, then why limit its use? Current Wiki creation It would be better if a Project Admin could choose to include the repository in the normal overview or not. Note: I find the two types very confusing for the user and there is not a clear way to use them the same way. This is no longer the case.Ĭurrently when you create a new team project, you get the option to choose between the two types, although it is not very clear to see the difference between the two. You could get the git URL to clone the repo and when you made changes to it, the repository would become visible on the Repos overview. If you created a wiki a couple of years ago, you have the first wiki type. Publish one or more repositories as a wiki.The default (old) way of creating a wiki.In Azure DevOps there is a distinction between two ways to setup your wiki: Short version: it is not available anywhere, but you can ‘guess’ the correct URL and navigate to it: Of course, I was intrigued and started to search: this functionality was always there before, so surely this will still be available? In this case, the person asking the question wanted to add branch policies on the wiki repo so they can enforce Pull Requests on incoming changes. Weirdly enough, we couldn’t find how to get the repo to be visual so we could use it. This used to be available if you knew what to do, so you could clone the repo and add pages programmatically for example. Today someone in the Azure DevOps Club slack asked a question about finding the repo from the default wiki in Azure DevOps.
0 Comments
Leave a Reply. |