In Azure DevOps :
We have a build pipeline, configured through the GUI editor.
I would like to share a link with my colleagues which points to a precise revision of this build pipeline
("sharing with my colleagues" = mention it in our internal issue tracker)
Question
Is there a way (through devop's GUI) to view the state of a build pipeline at a given revision?
A way with a shareable url?
I don't think you can show a precise revision of a build definition in the UI without to revert to this revision. you can see a revision of the build in a JSON format. if you go to "History" Tab and compare the difference between versions:
You will get a screen with the current version and the other (in JSON).
The URL in the comparison page is also unique to this comparison so you can share it.
Another option is to use the Rest API to get the precise revision, but also only in JSON format:
https://dev.azure.com/shaykia/{project-GUID}/_apis/build/Definitions/{build-id}?revision={revision-id}
The above call returns a JSON of specific revision, you can also share it.
(You can get all the revisions with Get Definition Revisions API).
Related
I see this feature is available, but I can't seem to get it to work the way I expect it to. Am I misunderstanding the capabilities of this feature?
When creating a build pipeline there is an option (since 2017) to automatically link a build to work items. Under this option is an Include and Exclude list for branch specifications. The default is Include * which searches all branches for work to link since the last successful build.
I'm trying to implement a branch naming convention because we have many solutions in the same repository and don't want work items relating to system 1 to be linked to the build of system 2.
To do this I'm using an Include sub2/* branch spec, but the build doesn't seem to link correctly.
Custom Branch Spec
Change on Branch Outside Spec
No Other Commits Linked to the Work Item
The Work Item Still Shows on the Build
BUT the build doesn't create an Integrated in Build link on the work item.
For changes made WITHIN the branch spec
The functionality of the build showing the work items in the progression (seen above) includes the work item as expected, but the Integrated in Build link is still not added to the work item.
I have created a TFS build using TFVC as a source code repository. Now, I want to get a full information on all changesets that happened among previous and current build.
Any rest api for this ?
Same sort of thing is available in jenkins using following rest api
http://server:port/job/jobname/lastBuild/api/xml
According to get list of changesets rest api
GET https://{instance}/DefaultCollection/_apis/tfvc/changesets?api-version={version}
There are multiple options such as by item path, by person. However it's not able to do what you want directly.
You could use in a date range option. Then you just need to get the starttime and finshtime of your previous and current build through this API- Get build details by Timeline
GET https://{instance}/DefaultCollection/{project}/_apis/build/builds/{buildId}/timeline?api-version={version}
You can use Get build details - Changes in VSTS Rest API.
I'm trying to study TFS REST API, but to no avail it is just hard to understand what parameter is what in the sample request given in the documentation.
What i would ultimately like to do is retrieve a list of all the commits done in lets say a particular project that have a bug associated with them. I want to retrieve a list of all these commits but only the ones associated with a bug fix.
Can someone please help me with this?
Not sure which version control system you are using, TFVC or GIT. Assuming you talked about GIT since the commit mentioned in your question.
There is a related REST API to Get a list of commits. For what parameter is what, there are also a detail table with notes. Such as fromDate which stands for Start date to search from.
To retrieve the commits with bug fixed comment
To retrieve a list of all the commits in a particular project you could use the branch parameter. Usually should fix the bug in a QA branch or DEV branch.
GET https://fabrikam-fiber-inc.visualstudio.com/DefaultCollection/_apis/git/repositories/278d5cd2-584d-4b63-824a-2ba458937249/commits?api-version=3.0-preview&branch=master
Then you just need to filter the comment with bug keyword commits.
To retrieve the commits related bug workitem
It's more accurate and convenient. First you need to get the bug workitems in your project. Using Get a list of work items Rest API with specific field such as "System.WorkItemType": "Bug", "System.TeamProject": "Your project name"
GET https://fabrikam-fiber-inc.visualstudio.com/DefaultCollection/_apis/wit/workitems?ids=297,299,300&fields=System.Id,System.Title,System.WorkItemType,Microsoft.VSTS.Scheduling.RemainingWork&api-version=1.0
When you associate a commit with the bug workitem, TFS will automatically add it as a linked item in workitem specified. Then you just need to get a workitem with links and attachments.
Assume you already have the Bug ID, you can use Get a WorkItem with links and attachments api to get all the commits associated with the bug.
Is there a way to automatically generate a change log from Github issues?
Ideally I want to be able to point at a closed milestone and generate either a plain text list of closed issues with their titles or, even better, a list with markup for links to the issues and the title of the issues themselves.
You can try to use Github-Changelog-Generator. (I'm author of this project)
It generates changelog from tags and merged pull-requests.
This script also have a support of GitHub Issues.
This changelog was generated by this script. CHANGELOG.md
Example:
Changelog
1.2.5 (2015-01-15)
Full Changelog
Implemented enhancements:
Use milestone to specify in which version bug was fixed #22
Fixed bugs:
Error when trying to generate log for repo without tags #32
Merged pull requests:
PrettyPrint class is included using lowercase 'pp' #43 (schwing)
support enterprise github via command line options #42 (glenlovett)
This isn't for Github specifically, but through Git you can run the log through pretty print to generate a changelog style html page.
From https://coderwall.com/p/5cv5lg
git log v2.1.0...v2.1.1 --pretty=format:'<li> view commit • %s</li> ' --reverse | grep "#changelog"
You can use the GitHub API to get a list of issues associated with a given milestone.
For example:
curl https://api.github.com/repos/<user>/<project>/issues\?milestone\=1\&state\=closed
replace <user> and <project> with the username and project and this will return a json list of all closed issues of the milestone with the id 1. You can then, for example, use a script to extract the information you are interested. Here is a python example that prints the list of issues as restructured text:
import json
with open("issues.json") as of:
data = json.load(of)
for issue in data:
t = issue['title']
n = issue['number']
url = issue['html_url']
print "* %s [`Issue %s <%s>`_]" % (t, n, url)
See if the following tool will do for you github-changes.
Disclosure: I'm the author of the tool.
We created an open source project to generate changelog from the list of closed github issues since a given datetime. It's available here: https://github.com/piwik/github-changelog-generator
Not directly through GitHub: that would be a kind of hook that you could put in place, and which would based on naming convention or comment convention that your project might follow.
Even using the issues title isn't always a sure way to generate meaningful change log, unless you review and edit if needed each and every issue title of your project.
In other words, it is very dependent on how you manage your project and not easily generalized to all GitHub repos.
I said as much in a very similar question "Publish a project release (binary/source packages) on Github?".
In addition of a third-party solution (or a GitHub Action like generate-changelog), you might soon Q3 2021, have a native feature from GitHub:
One of the most important parts of the software lifecycle is releasing your code for others to consume.
GitHub Releases will make that even easier by providing compelling and automatic release notes.
When creating a Release, you can click a button to automatically generate release notes.
If you want something more custom, you can a REST API to get the generated release notes and integrate them into your existing releases process.
We also want to ensure that these release notes look amazing when a maintainer shares them and make them easier to discover. We have done a complete redesign of releases to make projects announcements look stunning.
We are surfacing these releases in the feed to increase discovery.
We are also improving the open graph data for releases so they look equally fantastic when shared off of the GitHub platform.
Intended Outcome
Our number one goal is to make it easy for maintainers to create great release notes so more people can discover that amazing work maintainers are doing.
With minimal effort many projects will be able to benefit from detailed release notes.
For maintainers who put more time into their release notes to write editorialized content the intended outcome is that we free up time they are currently spending to maintain custom infrastructure and compile a changelog so they can focus on the most important content for their customers, high quality editorialized content.
Our other goal is to ensure that the release notes look great and are something maintainers and developers are excited to read and share.
How will it work?
The new Releases UI will be able to be enable with feature preview
A new button in the Release creation UI will be able to be pressed to generate release notes from any tag
The generated notes will be able to be configured via a .github/release.yml
A new REST API will allow customers to generate notes at their own convenience to further automate and customize the experience with GitHub actions.
I helped build a jQuery plugin for this recently that uses GitHub issues to communicate app updates directly to the user. The repo can be found here https://github.com/uberVU/github-changelog
Usage is pretty simple:
$(function() {
var $demoChangelog = $('.demo-changelog');
//call the plugin on a dom none
$demoChangelog.changelog({
//give it a repo to monitor
githubRepo: 'uberVU/github-changelog-playground',
});
//manually check for new closed issues
$('.demo-button').on('click', function(e) {
e.stopPropagation();
$demoChangelog.changelog('checkForUpdates');
});
});
My team is working with VSS and we are having difficulties managing versions:
We want to take a "snapshot" of the project we're working on, so we can keep working on it, but when we need to - we can get the files of the snapshot and built them for a release. (Is that called branching?)
Alternatively, getting all project files by date would be great too. (Meaning I would get the last checked-in version of each file in the project prior to the specified date.)
Is there any tutorial regarding this? I searched the net a bit and only found very simple howto's.
Thanks.
As Cannonade wrote, a label might be what you want. But since you explicitly mentioned branching in your question, you should be aware of the differences between a label and a branch:
With a label, you simply mark the current state of all files in your source safe database (the repository). If you created a label "V1.0", you can now at any time easily retrieve exactly that state and rebuild the V1.0 release for example.
With a branch, you create a copy of the current state of your repository. E.g. if you create a copy named "1.0", you can then continue with the development e.g. towards V2.0. Should you ever need to fix a bug for V1.0, then you can do this on the "1.0" branch.
So branches should be used to work on different versions of your projects in parallel. Labels should then be used to mark special versions on your branches (e.g. the ones used to create a release).
One last note: SourceSafe does not have a specific "branch" command. Instead you "Share" your solution and select the option "Branch after share". You can find more information about it in MSDN.
And a very last note: We stopped using SourceSafe about 1.5 years ago and switched to subversion (which is opensource and free). Have a look at subversion or other solutions. I can not imagine ever going back to SourceSafe.
You can apply a label to a current snapshot of source safe (like BUILD1) and then get the tree based on that label at a later date.