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?
Related
I have added some custom attributes to my project on GitHub. This project is shared, and I want to record any changes to these attributes. How can I do that?
I have no opinion about this subject
I'm looking to migrate a project from one org to another in Azure DevOps. We've ended up with two or three orgs, and this project that I'm looking to move has all sorts of weird and wonderful work items created and custom fields added. What I'm looking to do is move the project and then see if I can persuade the powers that be that certain things can be dropped but I have an immediate need to move as-is so that reporting and other work isn't impacted.
I have tried to get this to work with the migration tools (and tried to follow the videos) but have hit a dead-end. I think there are two issues potentially. One being the ReflectedWorkItemId. It says that it's not found in User Stories but I'm not sure how to resolve this? Do I go into user stories and add a field called 'ReflectedWorkItemId' and populate it with the work item number and/or add the same field in the destination org process?
It also mentions in the info that it can't find one of the Work Item Types - Processes. There are a few other custom work item types that have been created too but I assume it's given up on the first one. Do I have to create all of the work item types and the custom fields for each work item type in the destination org? Or am I getting the wrong end of the stick with this?
To provide sync as well as migration it is important that the tools knows which items have already been migrated. This is the purpose of the ReflectedWorkItemId field.
The field is not required in either case, however... if you don't have
the field then the system cant be re-run as it will re-copy all
completed work items. If you add the field to the target then it will
only copy those items it cant find. If you add the field to the source
(yes it needs to be the same refname), and set UpdateSoureReflectedId
to true then you can also filter the source, using a query and limit
what you load.
The former prevents duplicates, and the latter allows you to filter
the data load...
This is mentioned in this document. Here is a similar issue you can refer to.
TF201077 that usually happens when the target Project does not have a work item of that name. You can refer to this issue on github for help.
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.
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.
Recently building my github page with Jekyll.
I wanted to have a few types of post, mainly blog and study note.
I found a way to make the url the way I want them to be, however the connection is way off.
I used 2 methods, first I tried with create subfolder under _post folder
-_post
--blog
---first_post.md
--studynote
---first_note.md
I also tried create _post folder as subfolder:
-blog
--_post
---first_post.md
-studynote
--_post
---first_note.md
but no matter how I put them, they only show up in username.github.io/blog/
however their url is correct.
What should I look into to gain better understanding to Jekyll's syntax? Ruby?
Instead of putting your posts in subfolders, use categories. From the jekyll docs:
Instead of placing posts inside of folders, you can specify one or more categories that the post belongs to. When the site is generated the post will act as though it had been set with these categories normally. Categories (plural key) can be specified as a YAML list or a space-separated string.
This way, you can write a post in the _posts folder, set its category to either blog or studynote (or whatever you want it to be) and then that post will show up at username.github.io/category/post-permalink.
Also make sure that baseurl in your config file isn't set to /blog, because then everything on your site will appear under /blog. Hopefully this helps!