I recently discovered that you can create Milestones and Project Boards on Github repositories.
With project boards, you can place issues and pull requests and move them around the boards (Kanban).
But what is the purpose of having pull request inside boards ? Aren't pull request associated with issues ? Why would I place pull request inside board ?
UPDATE:
As user #BertrandMartel pointed out(read answer below), it's all about how you use issues and pull request. Since Github is home for Open Source Development, users of software could create an issue to report something, but developers can create pull request to do their work. Developers don't have to report an issue, they only create features. Same is applied for end users; they probably want to point out if something is missing or not working properly. They are not expected to work on a project(create pull request).
When you add a pull request or an issue to the project board, it means you create a reference to an Issue or a pull request. No modification is done to the Pull request, it just says that this card links back to that pull request
Also a pull request is not associated with an issue. In fact a pull request is a special type of issue (note that it has a number field which is incrementing like the issue number when you create one). A pull request may be linked to other issues
But what is the purpose of having pull request inside boards
You can assign notes to it and associate them with a kanban style card which can be moved between different columns. Each columns having different meaning in terms of project management for your team
The model is the following :
Project
ProjectColumn
ProjectCard
ProjectCardItem (may point to Issue or pull requests)
Here is a graphical representation from graphql voyager :
From About project board :
Project boards are made up of issues, pull requests, and notes that
are categorized as cards in columns of your choosing. You can drag and
drop or use keyboard shortcuts to reorder cards within a column, move
cards from column to column, and change the order of columns.
Project board cards contain relevant metadata for issues and pull
requests, like labels, assignees, the status, and who opened it. You
can view and make lightweight edits to issues and pull requests within
your project board by clicking on the issue or pull request's title.
Related
I'm attempting to utilize Power BI and the Analytics Views provided in Azure DevOps to create reports. I noticed an issue regarding the template(s) used that caused for no data to appear in the datasets in Power BI.
Scenario: If a user uses the Scrum template in Azure DevOps, it calls the Refinement Backlog level of work "Backlog items". If a user goes into change that to "Stories" it changes how the queries grab the group of work items in that level.enter image description here You can easily change the query to match the new name of the backlog level. You cannot add multiple "projects" to that query and see the data in the dataset if other projects are using the default name.
Issue: I attempted to change the name back to the original name of "Backlog items" instead of "Stories" and run the query in the Analytics Views to grab the data from multiple projects with the same "Backlog items" level but nothing appears in that project that was renamed back to the original name.
How to reproduce:
Open a project in Azure DevOps
Access Analytics Views
Under any Backlog query, edit and add additional projects to retrieve data in this view and save
Open Power BI and connect to the recently changed query
In Azure DevOps, access Organization Settings and go to Process
Access the project the above query is located and open the template
Modify the name of the backlog level to something other than "Backlog items"enter image description here
Save and go back to Power BI and refresh data
Actual result - you should not see the data from that project due to the name change
Go back and change the name back to the original name and refresh the dataset in Power BI
Result:
You still do not see the deta in the dataset even though you renamed it back to the original name. Besides 'resetting' the backlog level back to the original default state, is there a way to get it to recognize the original name if you renamed it back? Is there another step to making it recognize the name change? Since it's in the cloud, I waited 24 hours after the name change back to the original name but still didn't work. I noticed the same thing will happen on the Portfolio Backlog level (i.e. Epic).
Besides 'resetting' the backlog level back to the original default
state, is there a way to get it to recognize the original name if you
renamed it back?
I seem to reproduce similar issue like yours and then I use steps below to make it work:
1.Reset the Backlog and refresh the page.
2.Then navigate to the Analytics views, edit the View(the view in your step3) which can't be recognized now.
No matter it's Backlog items backlog or Stories backlog here, delete them all and Verify the view. Then click Save button.
3.Refresh current page and edit the View again, add the Backlog Items backlog back, Verify the view, Save the view. Now refresh the data in Power BI, the data should come back.
Above steps are what I use to work around the issue, hope it helps :)
I have a list of pull requests, each linked to the specific work items. I want to run a pipeline only for some of the work items. Therefore I would like to somehow automatically cherry-pick only commits/pull requests related to work items I want to build. Either using tags on work items or something similar. In the build, I need only the files which were changed, so I was thinking of using git diff.
Is that possible using the Azure Pipelines?
If I understand your request correctly, you need to run the build pipeline only for those pull requests which meet certain requirements, for example, are linked to the work items tagged with specific words. Although I'm sure there's no out-of-the-box solution to this, I think it is possible to achieve with the Conditions concept and the REST API.
I would follow these steps:
The very first build step in the build job should be a script to find out if this particular pull request being built is related to the target work items. It can be a PowerShell build step, which should:
Get the pull request ID - it is available as a predefined system variable called System.PullRequest.PullRequestId
Make a REST API call to get work item IDs related to this pull request. It will return a collection of {id, url} pairs, where id is an ID of the work item in question
For each found work item ID, make a REST API call to get the details of the work item, in particular, you're interested in the System.Tags property of the response
Again, for each work item, parse the System.Tags property value to find out if it contains necessary tags
If at least one related work item contains the tags you're interested in, set the flag variable called i.e. ShouldRunTheRestOfThePipeline to true
Conditionalize the further steps of the job with the custom condition. You can read more about the syntax of the expression here. In particular, the Q&A section describes how to use the variable set in the previous build step in a subsequent step's condition
Now, regarding your notes about taking only changed files. In fact, the pull request nature is to keep the changed files compared to the target branch it is created against. So, you don't need to do any extra actions to git diff - the pull request already contains all you need.
Finally, I would suggest you reconsider the requirements of this setup, 'cause it sounds a bit unnatural to me. There are other options for how not to trigger a pipeline. For example, it can be decided based on the branch/tag name, both include and exclude options are available. Or, you can specify file paths to include or exclude, for instance, never trigger a pipeline if only docs/* were changed. The wildcard syntax is supported, which makes this tool even more flexible.
Hope this can help you build a suitable solution to your specific scenario.
I'm trying to find all PRs across all repos that have a given branch name. I'm using GitHub Enterprise.
SearchIssuesResult contains a List<Issue> Items property. The individual Issues in that list have a Repository property, but it is null, and its sibling property PullRequest doesn't seem to have all the data populated in it.
I therefore want to load the PR directly using the PullRequestsClient.Get method or similar, but this needs a repository ID. I've hit this with a debugger and the Issue results don't seem to contain one anywhere in the hierarchy.
I can infer an owner and name from various URLs that I do have available (e.g. the HtmlUrl property on the Issue) but that seems very hacky and ugly. Is there a better way to do this than relying on URL formats?
In VSTS (now Azure DevOps), multiple updates can be pushed to a pull request (PR). You can compare any update with its previous update, and you can compare a rolled-up view of all updates with the original code before any changes were made. But how do I compare two arbitrary, non-sequential updates?
My scenario is that a PR has had quite a bit of back-and-forth with a total of 8 updates pushed. I last reviewed update 5, but now 3 more updates exist. I don't want to review 6-5, 7-6, 8-7 or all updates, I just want to review 8-5. How do I do that?
A workaround (in the absence of any user interface to configure two non-sequential updates to be compared) is to edit the iteration=xxxand base=xxx query string parameters in the url, e.g.:
https://xxx.visualstudio.com/xxx/_git/xxx/pullrequest/123?iteration=8&base=5&_a=files
This updates the UI as shown below:
I discovered this because I received an automated email from VSTS notifying me about the latest pushed updates. The email included a "View pull request" button. I clicked the button which took me to the PR in VSTS (I think to the Overview section). There was a notification banner towards the top of the page with a link about comparing update 5 with update 8 which I had never seen before. This sounded promising, so I clicked the link and it took me to the Files section and showed the differences between update 5 and 8 which is exactly what I wanted!
However, subsequent visits to the page (or clicking the "View pull request" button in the email again) don't show that link again, and I can't find anywhere in the UI that lets me define the two updates to compare. So this seems like a one-time opportunity. Miss it, and it's gone forever. I'd still like to know if there's a way to define two non-sequential updates to be compared in the UI, however, the poor man's url hack is a viable workaround for now.
We are trying to use GitHub for issue tracking in one of our projects and while its very simply to use, we aren't sure its powerful enough at the same time to fulfil our needs to organize our issue management since we can't find a way to customize it.
Question: Is it possible to add custom attributes in GitHub for issue tracking, search/sort and export the list of issues with those attributes? For example, we'd like to add and use following attributes:
External Issue ID: There is an external list of issues/change requests maintained by a separate group that we need to associate
our issues with and need a field to specify the external issue ID.
Priority: so that we can easily discuss and prioritize what we want to tackle first
Severity: to identify impact on the system
Type of Issue: Bug, Change Request, New Requirement
Class: Performance, Security, Function, Compliance etc.
Source: to track whether issue was reported by a specific customer (which could be in hundreds), end user, internal team,
partner etc.
Date Opened: I think this is maintained internally by GitHub but not exposed anywhere in the UI
Date Closed
etc.
We understand some of these can be implemented with labels but there would be too many of them to assign and they do not allow exclusivity (for example you can only specify one priority - high, medium, or low assigning - to an issue)
Any ideas if and how this can be implemented in GitHub?
If not, any recommendations?
Thanks!
As you mentioned already, this so far is only done by using labels, for example the way i do priority is having multiple labels:
Priority: Blocker
Priority: High
....
Yes, unfortunately this feature is not intended to exclusively select one value per category as these are labels.
There is a github issue that proposes a new feature to GitHub so that we can have a Priority attribute in every GitHub issue right here
https://github.com/isaacs/github/issues/472
Not sure about all the other custom attributes, but maybe this would be a good start for your idea.
There does not seem to be a way to create custom parameters. You may be able to do this by storing the data inline in the text of the issue and then parsing that issue text programatically, but that's kind of a hack.
For instance, if you wanted to link a GitHub issue to an internal bug tracker like JIRA, just use the JIRA issue name in the text of the GitHub issue and then write a regular expression to parse it back out. This requires a little bit of extra plumbing on top of GitHub.
Date opened and closed are available in the API. See documentation.
(Incidentally, I'd note that the lack of customisation and complexity is a key feature of GitHub's issue tracking system: it is designed for developers, not project managers who want to tweak it into a confusing JIRA-like hellscape of misery.)
Update June 2021: you could use custom fields for those attributes!
New beta features within GitHub Issues, with better ways to plan, track, and manage projects.
Read more on the GitHub Issues page or in the FAQ.
✨ NEW – Project planning for developers
Available in limited public beta
Built like a spreadsheet, project tables give you a live canvas to filter, sort, and group issues and pull requests.
Tailor them to your needs with custom fields and saved views.
Sign up for the beta now.
That includes:
Extend issues with custom fields with support for text, number, date and single-select types
Change custom field values right from the issues sidebar
Filter, sort, and group by any field
Use tags
Most of the time you can put the kinds of things you want in the body of the issue as text or use a tag for things like priority. You only need to set priority if it's not the default one.