I have a service hook configured to point to a server which receives a request from Azure Devops every time a pull request is made, which then in turn makes a call to the Azure Devops services REST API to create another pull request.
This second part is done using a PAT (Personal Access Token) for the time being generated from my account. This means that all the pull requests created automatically are made under my name, meaning I receive all the emails and notifications related to this automation.
Is there a way I can create a "fake" identity (without adding an actual user which may authenticate) with a different token which can be used for this automation (opening all pull requests under that identity)?
Is there a way I can create a "fake" identity (without adding an actual user which may authenticate) with a different token which can be used for this automation (opening all pull requests under that identity)?
Short answer is no.
Notification could be setting with three Levels : Origination,project,personal. It is not related with the PAT token.
Based on my experience, the Azure Devops also has no way to know which request is automation or manual way to create PR.
So if you don't want to receive the created PR notification, you could disable it on the personal level.
You also could customize the receive emails with project setting to receive the related information.For more information please refer to this Document.
Related
We have successfully integrated SonarQube into our build pipelines on Azure DevOps and have used a developer's account to generate a PAT for pull request decoration. The problem is now that the developer's account is posting comments across all our repos on different Pull Requests. It seems the alternative is to create a whole new user titled 'SonarQube' (or similar) in our Active Directory and generate a new PAT to do this, which seems overkill. Any alternative options would be appreciated.
Creating a separate identity that would belong to SonarQube is the only option. The identity posts the comments using the DevOps API where the PAT is the only identification of the identity.
Using a developer's account for PR decoration not only feels strange when reading the comments, but it is also fragile. When the developer leaves the company, their account will be terminated and suddenly, PR decoration will break and it may not be immediately clear why. Also, the developer could revoke the PAT at any time by mistake. In a larger organization, no single developer will have the right to comment on pull requests everywhere, so multiple developer accounts will be in use, which makes the configuration even more complex and fragile.
We're building a microservice to interact with Github REST API to read repository information within our organization. At the moment, we use individual user id and personal access token (created for the user id) to access the remote api programmatically.
Our requirement is to have a service account to access the api that has read privileges and no coupling with any individual. I was looking at Github Apps to perform the integration but it seem a bit complicated for our purpose as it focuses on making changes and handling events. We only need to read the repositories and collect information such as pull requests, commits etc. done on those repositories.
Are there any other simpler ways to achieve this?
I am tasked to help automate the workflow related to automating a few tasks related to management of our organization account on GitHub. For example, add and remove users from the org, create new repos, add external collaborators etc. The requests for this actions will come from a system where a user fill in a form and this system will curl to the GitHub API after the request is reviewed and approved.
By reading the GitHub API documentation I can set up the curls for this, but I am unsure about authentication best practices. My first idea would be to create a user account specific for this use case, make it admin for the org, and create an OAuth token with scopes needed to be allowed to make this requests. However, it feels a bit too hacky to create an individual account for something that is not an individual, and then make it admin of the whole organization.
Is there a better way to approach this?
Is it possible to create a Github Check for pull requests? I know there are WebHooks, but is there a way to also hook into the UI?
Aim:
Pull Request made. Perform validation and update pull request if valid.
Pull Request merged. Create web call to URL. Update Github issue with confirmation.
What's the best way to do this? Is it only via Web Hooks, API calls and getting write oAuth credentials?
Note: you now (August 2018) officially have the notion of Checks
When checks are set up in a repository, pull requests have a Checks tab where you can view detailed build output from status checks and rerun failed checks.
I know there are WebHooks, but is there a way to also hook into the UI?
The recommended way of doing this is to use required status checks and the Status API, in combination with webhooks:
https://help.github.com/articles/about-required-status-checks/
https://developer.github.com/v3/repos/statuses/
Users set up required status checks on the repository so that merging a pull request is blocked if a specific status isn't success.
At the same time, webhooks trigger an external process when a pull request is updated, and that process creates statuses based on the output of that process. If the process completes successfully, then the process should create a success status which will be shown in the UI and unblock the merging of the pull request.
Is it only via Web Hooks, API calls and getting write oAuth credentials?
In order to create statuses, you will indeed need to authenticate with the credentials of a user that has push access to the repository (e.g. via a token from that user with the right scopes).
I'm trying to Enable/Disable a logic app on Azure using the management APIs. I always get a 403 saying the client: with object id does not have authorization to perform 'Microsoft.Logic/workflows/disable/action' ...
I do use the authentication token in my request and so far have been able to use the API to list all workflows, get trigger histories and in/out messages using the same method.
Any suggestion?
I've seen this issue a lot before if you are calling the http:// instead of https:// - we are looking into automatically redirecting, but for now you will need to make sure you are calling the https:// endpoint with the correct method (in this case a PUT)
EDIT: We discovered the issue was the account being used to perform the enable/disable didn't have contribute permissions.