I am using Github as my repo as well as my Kanban/Scrum board. We use Visual Studio Team Services for our automated builds. We really like the way VSTS works and it works well with Github as the repo.
However, I want to be able to create a new Github issue/bug if and when our Continuous Integration build fails. I know you can create a VSTS Work Item but I would rather keep all issues centralized.
Is there any way to hook up VSTS to create a Github repo whenever a build fails? Or perhaps create a Github issue whenever a new VSTS Work Item is created?
We are running our own build server so possibly something can be done on that end?
Yes, you can create a github issue when VSTS build failed with two options.
Option1:
In VSTS build definition, add a powershell task in the end of the build process. Functions in the powershell should include:
Detect above build tasks in the build definition. Use REST API timeline to get build detail, you can find each task result in result parameter.
Determine to create a github issue or not. If all above build tasks are pass to build, don’t create github issue. Else, create a github issue by github API.
Option2:
Create your own website, and in VSTS use web hooks to tigger build fail information for your own website. After your own website receive the build information, it can create a github issue.
Related
I was trying to have a full change from the commit to the pull-request/review process in a Azure DevOps repo with Visual Studio Code.
All good till the point where I have to create a Pull Request.
I didn't find an embedded way to do it.
There is a plugin Pull Requests for Azure Devops but it seems to be not maintained anymore.
Do you know any other good way to do it? Or may be Microsoft can invest in this important feature?
In our team, we started using the Azure CLI but found it too verbose to be practical. We also wanted to have a similar API to the GitHub CLI.
To fix this, we developed doing-cli, which is essentially a wrapper around the Azure CLI with a feel of the GitHub CLI.
A typical workflow for us is:
doing list to see open work items
doing issue create <issue title> to create a new work item
doing pr create <issue number> to create a branch and a PR based on an existing work item
Our company requires that all PRs are linked to a work item. But sometimes you want to fix things quickly, without having to always create a new work item, create a new branch, link them and open a PR. So we implemented doing workon <title> which will do all these steps for you, as well as checkout the newly created branch.
There used to be an extension, but it got pulled.
When you install the azure cli and the devops extension and then create a pull request from the terminal:
az extension add --name azure-devops
az devops configure --defaults organization=https://dev.azure.com/contoso project=ContosoWebApp
az devops pr create --repository MyRepo --open --source-branch branch-name
That last command needs 2 parameters that can be teased out of the context in a repo folder, that way you can easily alias this to a generic command.
Very few people were uring the Azure Repos and PR for Azure DevOps extensions. And most of Microsoft's investments are in GitHub.
As suggested by Jessehouwing's answer, you can create pull requests using Azure CLI.
In addition, you can also use the REST API Pull Requests - Create:
POST https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/pullrequests?api-version=6.0
Here is an example of the request body:
{
"sourceRefName": "refs/heads/npaulk/my_work",
"targetRefName": "refs/heads/new_feature",
"title": "A new feature",
"description": "Adding a new feature"
}
I am following the steps outlined here. I am using the Deploy to Azure Extension
https://learn.microsoft.com/en-us/azure/devops/pipelines/targets/deploy-to-azure-vscode?view=azure-devops#github--azure-pipelines
I have done the following steps.
I have managed to create a simple react app and then got the GitHub + GitHub Actions portion to work no problem.
Now, I want to get GitHub Plus Azure Pipeline to work. So, I deleted the GitHub Actions/Workflow files, and starting over with the CICD setup.
Next, I have enabled Use Azure Pipelines for GitHub in the extension.
Then, as per the steps/pictures outlined in the above microsoft documentation link, I have begun the configure CICD option from the command palette.
Selected the Visual Studio Subscription
Selected the target web app
Now, at this point, as per the linked tutorial, it is supposed to ask me to choose a azure devops organization, so that the azure pipeline YAML file can kick in. This step never happens.
instead, VS Code will proceed to generate a GitHub Actions Workflow just as it did before.
What should I do to the GitHub to Azure Pipeline working from this extension?
Update 1
In case anyone is curious, I have raised a issue on the visual studio community forum. You can find that here
https://developercommunity.visualstudio.com/content/problem/1182952/github-azure-pipelines-falls-back-to-github-github.html
As of now, there is an ongoing discussion but no solution yet.
You can try reinstalling Deploy to Azure Extension and enable Use Azure Pipelines for GitHub, and then configure CI/CD option again. If the issue persists, you can report this issue here.
You can create a pipeline directly in your azure devops project. Check out below tutorial
Build, test, and deploy JavaScript and Node.js apps
You will also need to create an Azure Resource Manager service connection to deploy to your azure resource from azure devops pipeline.
Deploy an Azure Web App (Linux)
The company I work on recently purchased SonarQube Enterprise to improve code quality throughout all repositories. I found out that there is a feature that enables SonarQube to comment automatically on PRs targeting a specific branch, and I successfully managed to try that out.
Thing is:
That configuration is not scalable: I would need to manually configure every repo to follow that rule
That configuration needs a build pipeline to be defined "old school" on Azure DevOps to work, and we are moving into Pipeline as Code, starting of course with CI (where this takes place)
Anyone managed to get the PR commenting working in that scenario? Or, at least, solving the #1 problem?
Cheers
You can use REST APIs to do whatever configuration you need to do across your repositories. Refer to the REST API documentation.
Shouldn't matter, although I haven't tested it. The SonarQube tasks aren't aware of whether the build source is YAML or visual designer/classic/JSON builds. The underlying tasks and job running architecture is the same. As long as the build is hooked up to a branch policy, it should still work.
Please elaborate the steps to create a workflow of Visual
Studio Team Services and Github.
Integration of Github with VSTS and creating a workflow.
Once we create user stories in vsts, is there any way to create a
transition from one state to another(New->Active->resolved),
based on repository update(github).
There is a way to transition from on state to another when github repo is update:
Create a CI build definition for the github repo.
Add a power shell task to change the stories state.
But usually user stories are linked with repo on VSTS not github, that’s more useful and meaningful.
Automatically is only using VSTS git repo.
If you like update this, you need to create a manual integration, possible using the VSTS Rest Api.
How do you get VSTS to build when a PR is created in GitHub? I've tried several triggers in the VSTS build like refs/pull/*/merge and refs/pull/*/head. I have a build working when a commit is made to the master branch, but I can't get a build to trigger when a PR is created.
I get the following when a PR is created.
Also, the webhook history shows that a message was successfully posted to VSTS, but the build never starts.
The official Microsoft VSTS GitHub Integration extension now supports this directly.
I think it's the trigger. Try what's described in this blog post.
There is not an easy way to enable this today for PRs. It is on the VSTS feature backlog that we want to address soon.
The way to make it work today would be to do something like: add a webhook to call your own custom service endpoint. Within your service endpoint, you could then call into VSTS to queue a build, and the build would need a step to post success/fail back to GitHub.
In your custom service endpoint, you would need to make sure the user is authorized as a contributor on the GitHub repo.
On the new VSTS UI you can find it in Build Edit -> Triggers: