I want to change the security settings of my repository project by selecting More options > Security in Azure DevOps web console / browser. But when I do so, I get the below error:
Your administrator has disabled web editing for this repository. You cannot add, delete, rename, or edit files via the web.
I am an administrator myself and not sure what setting I should change and where in Azure DevOps, given that it has varying levels of permissions and that the error message above is more cryptic that I don't see a setting that matches it anywhere.
Note: I am also admin of an external group where access permissions are restricted to many of the projects in this repository. Not sure if this deny is over-riding my permissions and how to go about solving the issue if this is the case.
I really would appreciate your help in fixing this issue
Your administrator has disabled web editing for this repository. You cannot add, delete, rename, or edit files via the web.
As far as I know, this issue should appear in the TFVC repo.
To solve this issue, you need to navigate to Project Settings -> Repositories -> TFVC Repo -> Settings and enable the Web editing option.
Related
I want to add a group/user to an Azure DevOps project with just access to repositories and pipelines.
If I deny "View project-level information" they don't have access to the project at all.
If I allow the "View project-level information" it gives them a read-only access to the Project Settings including permissions to see users and members of other groups etc.
It seems unbelievable that such a basic security and privacy hole exists.
Am I missing something in the config because I have never seen this in any other application and I find it hard to believe that everyone else using Azure DevOps finds this acceptable.
The easiest equivalent is GitHub (that Microsoft now owns) and you can't see the project settings if you are just a contributor.
How do I give external contractors access to the project to work but prevent them from viewing the Project Settings?
There is no possibility to restrict access to the Team Project - Project Settings page. The only thing that comes close is the feature that is now in preview: Limit user visibility and collaboration to specific projects, which will enable you to restrict access to the Organization Settings. You could suggest this feature in the Microsoft Developer Community.
I have managed to finally add my devops account in sourcetree using the https://orgname.visualstudio.com path
Now I am having issues cloning the repository
I am using the path that devops gives me
https://orgname#dev.azure.com/orgname/MyProject/_git/MyRepo
but I get an error saying
This is not a valid source
The details reveal authentication issues... Yet it authenticated fine when adding the account.
What is going on? Does the azure account have to be the default account?
I managed to fix this by changing from the sourcetree embedded git to my system git Tools>Options>Git>Git Version>Select System. Afterwards when trying again it prompted me to login on my organization domain with 2 factor as if logging in on the devops web app directly.
My system Git is using manager-core for the credential management which is probably not the same system which the embedded version used.
I tried the above solutions (and more) but for me what in the end solved the problem was that the git-password I first wrongly entered when I tried to access the repo had been saved in Keychain (MacOS) and when I tried again this password was used without giving me the option to type it in again. I deleted the password to the Azure DevOps project in Keychain and then got prompted to enter the password again whereafter I pasted the Personal Access Token (!!) generated in Azure Devops and it finally worked!
It could happen when you entered wrong credentials and you don't get asked again, try this:
Go to : Sourtree->Preferences->Advance (tab)
Under: "Default usernames for URLs which do not include one:" delete your wrong credentials.
Try accessing your repo again with right credentials.
This is not the issue which caused by Azure devops. No matter https://xxx.visualstudio.com, or the URL which like dev.azure.com, they should all available git source.
For me, I just try with multi different git URLs, and found the few of URLs are failed with same error with you. But it prompt This is a git repository after I exit the SourceTree and re-configure the clone with same URL which encountered the error previously.
This seems be the most common Sourcetree problem which encountered by many users, not just the URL of azure devops that you occurred.
Check this thread, and try with its recommend way:
Open source tree, Tools -> Options -> Click on Git Tab -> Update
Embedded Git.
Or, consider the method I used: exit the Sourcetree, and re-configure the clone with same URL. (Not recommend since this can not permanently solve this issue)
Right now my NuGet restore fails since the project build user doesn't have contributor access to the package feed.
/usr/share/dotnet/sdk/3.0.100/NuGet.targets(123,5): error : Unable to load the service index for source pkgs.dev.azure.com[..]index.json.
/usr/share/dotnet/sdk/3.0.100/NuGet.targets(123,5): error : Response status code does not indicate success: 403 (Forbidden - User 'xxxxxxx' lacks permission to complete this action. You need to have 'ReadPackages'.
The solution is to change the build authorization scope from current project to project collection. This seems very doable as seen here:
https://learn.microsoft.com/en-us/azure/devops/pipelines/build/options?view=azure-devops
But where, in DevOps' myriad menus, can this scope be set?
EDIT 2023: The Artifacts UI in DevOps has changed since this answer and this answer is no longer valid. See J-M's answer on a similar question:
https://stackoverflow.com/a/73136309/5358731
There was a workaround for this 403 error posted a few hours ago: https://developercommunity.visualstudio.com/content/problem/795493/403-error-during-nuget-restore.html
In short, this seems to affect new projects connecting to a private feed. Here's the suggested work around:
Click "Artifacts" in the project with the failing build
Select the feed you were trying to consume in your build and click the cog in the top right corner
Click "Feed Settings"
Go to the Permissions tab
Click the 3 dots [...] that appeared to the right of the tab
Click "Allow project-scoped builds"
This adds the relevant user permissions that the error the OP posted was complaining about. Hopefully Microsoft will make a proper fix for this soon.
Full credit to Tim Lynch from the developer community page.
All answers are valid but it depends.
Take into account that only Contributor and Owner roles are allowed to push packages read the docs here.
Then also remember Scoped build identities .
Azure DevOps uses two built-in identities to execute pipelines.
A collection-scoped identity, which has access to all projects in the collection (or organization for Azure DevOps Services)
A project-scoped identity, which has access to a single project
...
By default, the collection-scoped identity is used, unless the Limit
job authorization scope to current project is set in Project Settings > Settings.
With this in mind follow the next steps:
You need to check which identity is being used for your pipelines:
For me is project-scoped identity
Add/Check the Feed Permissions as it may apply (I'll leave a description below the image)
No. 1 If the identity is collection-scoped
No. 2 If the identity is project-scoped
No. 3 Give your contributors the least privilege principle if it applies. (For me its ok to leave them read the feed, and the pipeline or me are the only ones allowed to push packages)
Remember again you need to use Owner or Contributor roles.
Go to your feed settings:
In the Permissions tab verify that have at least reader permissions to "Project Collection Build Service (username)":
It appears under Organization and Project Settings. Find Pipelines/Settings and there is a toggle option named Limit job authorization scope to current project.
I've installed the Google Cloud Build app from Github Marketplace, and enabled it on several repositories, only to discover that enabling access for those repositories automatically starts running the Google Cloud Build "check" after every PR or push to a PR. Since some of those repositories are not actually ready for Google Cloud build, I needed to turn off the checks... I used the URL mentioned in the docs to get to the page where you can select which repositories should be connected to your GCP project, and unchecked a bunch of them... this disconnected them from the project, but, surprisingly, did not disable the Github checks! So now, there are Github checks on several repositories that just result in an error because they're not connected to any projects in Cloud Build.
Surely, it is not an uncommon use case to need a way to "disable Checks" on a per-repository basis - is there any way to do that?
(If not, consider it a requested feature if there are any Google Engineers reading!) ;)
I did talk to chat support, and the only way we could figure out to remove the checks would be to uninstall Google Cloud Build completely from the entire organization, which I don't want to do because we do have some setup that I want to keep, and I don't know how much of that configuration would have to be redone if I uninstalled it completely.
Here is a screenshot of the broken check that I can't disable:
I think there are 2 steps to disable CloudBuild,
1. Disable on CloudBuild itself. For some time I kept seeing 2 builds per push made, but disabling a trigger on CloudBuild helped fix that.
2. On Github, you can configure the Cloudbuild app to monitor a specific repo on the organization level setting.
3. If you feel a lot adventurous though and it's not solved, on the project level setting, you could delete the Webhooks integration for cloudbuild, as that's what Github notifies of each build.
It can be found within GH App installations:
https://console.cloud.google.com/gcb-github-registration
Select the GH account used for your link between Cloud Build and GH, then the GCP project you want to edit.
Here connected repositories can be edited, and in the second step (Trigger settings), the "Default GitHub Checks" can be disabled.
You can also goto settings of your repository and click installations inside settings.
And then remove Google cloud build from Installed apps and authorized github apps.
Cloud Build Triggers are still in beta, and have gone through several updates since this question was posted, but it now appears that the "Github Default Checks" are no longer hidden from management. They are now explicitly offered (but not automatically created) when connecting a repo, and you can finally view and disable (or delete) individual "Github Default Checks" on the trigger management page: https://console.cloud.google.com/cloud-build/triggers
I'll leave this as unanswered, because I'm uncertain this is how it is working for everyone, or that this answer will remain true, but if it works for you, feel free to vote up the answer!
To link GCP Project to the Github repository, create a trigger by clicking on resolve link, besides Action Required and then disable the same. For me this procedure worked out.
I have an organization on GitHub with private repositories. I also have Jenkins set up running on port 8080 on a server, with the GitHub plugin installed. I've created an account on GitHub for my jenkins user, which resides in the owners group.
I'm trying to trigger a job on jenkins when a change is pushed to my development branch (or master branch, neither seem to be working).
When I look at the GitHub Hook Logs in Jenkins, it says that Polling has not run yet. When I go to "Manage Jenkins", the GitHub plugin says my account is Verified when I test it.
Any insight on how to configure this? I have multiple repositories I'd like to work with, so deploy keys don't seem like the solution to me.
Update:
As Craig Ringer mentions in his answer, you can select Grant READ permissions for /github-webhook in "Configure Jenkins" under the GitHub plugin settings, allowing the webhook to be called without authentication.
Another update: Webhooks are now (Dec. 2014) available for organization: see WebHooks API for orgs.
Note: the issue 4 of the hudson-github-plugin was about:
Last GitHub Push
Polling has not run yet.
And the conclusion was:
Nevermind, the only missing piece was a permission checkbox for the github user which ain't documented anywhere on the internet.
So is this a permission issue regarding your Jenkins users?
The article "Set up Jenkins-CI on Ubuntu for painless Rails3 app CI testing" includes the following process:
To restrict the CI system and give access to your Team members to use or see the build logs, first you’ve to create an account.
Go to Manage Jenkins > Configure System,
Check the Enable Security checkbox
Under Security Realm, choose Jenkins's own user database
Check the Allow users to sign up checkbox
Under Authorization, choose Project-based Matrix Authorization Strategy
Add first user with the name admin and another with GitHub (Note: the username for Admin access has to be admin) For GitHub named user, just choose the Overall Read only permission. We’ll use this user later with the GitHub hook.
Note: The admin and GitHub user that we’ve added in the above step does not create the User. Then you’ve to create a real user with that same name. Ya, I know, its a bit weird with Jenkins UI.
Go to Manage Jenkins > Manage Users > Create User. Create both admin and GitHub users.
Hooking with the Github web-hooks
Now to run the build automagically when new commit or branch gets pushed onto Github, we have to setup the repository.
Got to the hooks page for your repository. e.g.
github.com/<username>/<project_name>/admin/hooks
Under AVAILABLE SERVICE HOOKS > Post-Receive URLs, add github:github#your-ci-server.com/github-webhook/.
The github:github is the user that we’d created earlier.
Then we have to verify Jenkins with Github. Go to Manage Jenkins > Configure System and under GitHub Web Hook, add your Github username and password and click the Test Credential button to authorize once with Github.
It looks like the accepted answer is no longer necessary with the current version of the GitHub plugin. You can instead check Grant READ permissions for /github-webhook in "Configure Jenkins" under the GitHub plugin settings, allowing the webhook to be called without authentication.
As explained in the help on this option that's quite safe, and frankly no worse than having a user named "github" with password "github" anyway.
There are two ways to achieve automatic builds on Jenkins. What you choose depends on whether GitHub can call the Jenkins server URL you provide. This may not be the case if you are running Jenkins behind a firewall.
If GitHub can reach that URL you can set up the service hook on your repo there.
If not you can set up Jenkins to poll periodically.
You may set up both, but one solution is enough to get it working. I would always go for the first if feasible as it saves resources CPU and traffic wise.
Either way you need the GitHub plugin for Jenkins.
Hope that helps a bit.