-
Notifications
You must be signed in to change notification settings - Fork 431
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GenerateReleaseNotes: Can it roll up release notes between deployments to specific environments #34
Comments
Nice feature to ask for, the issue is walking the history of builds and releases to get the list of builds to include. As the task currently works with a list of builds the work required will just be to generate the list, not sure how hard that will be. There is no single call to the REST API that will do it. So it is on the backlog just not sure when I will have time to look into it |
Are there any pointers anywhere for developing and testing these tasks? For example, if I wanted to look at this one myself. I can find my way through the powershell, it's the testing, packaging and debugging process that I'm not clear on. |
This would be good. |
I have noticed that the VSTS/TFS front end has this feature. Before you deploy to an environment it will list all the changesets/workitems between the previous release (on that environment) and the new one. Looking at dev tools the changesets URL looks like this: https://tfs.domain.com/tfs/collection/%GUID%/%GUID%/_api/_versioncontrol/history?__v=5 I am unable to find any MS documentation on this endpoint and therefore assume it is private. |
Any news on this issue? Maybe would be easier to have an option to enter a previuos release ID manually (for example the release that was last deployed to PROD). |
Sorry not had time to look at developing this feature, real world keeps getting in the way. Other projects have kept me busy. So no ETA for this feature, not even sure of the logic needed behind the scenes Something like
Does that sound like it would work? |
If I understand correctly, this logic will work with references to the same environment. Maybe with an (optional) extra filed to enter a previous release ID, the work items list can be generated using: |
OK, that makes sense, how does it sound if we by default look for the last successful deployment to the same environment stage, but allow a parameter based override with the name of the environment stage to check against to allow user use case? |
Oh yes, that would be a very elegant solution. |
This feature has been shipped in V2.0.4. There are more notes on its usage in http://blogs.blackmarble.co.uk/blogs/rfennell/post/2017/01/05/Version-20x-of-my-Generate-Release-Notes-VSTS-Task-has-been-released-with-release-rollup-support |
Sorry, I found a couple of issues:
##[error]System.Management.Automation.MethodInvocationException: Exception calling "DownloadString" with "1" argument(s): "The remote server returned an error: (404) Not Found." ---> System.Net.WebException: The remote server returned an error: (404) Not Found. |
So in your example the release notes are triggered by release 4? As you should be able to see in the logic I thought I always added the triggering release, then look for other relevant releases. Have you tried running the release in verbose mode (set the global variable of system.debug to the value true). The logs should give more info, at present that error just means 'it failed'. |
On the None,None issue. I suspect that these are coming from the actual PowerShell ln.411 of the script adds the word none if there is no data to expand. I think the best option is to make the value a property, so you can choose to have a blank or any word you want (defaulting to None). I will get that done ASAP |
Just shipped 2.1.1 which allows you to change the text for the None message. Make it blank and that should fix that issue |
I've not tested the fixed version, but quick tests on the first V2 release suggest it doesn't roll up multiple builds that are rolled into a single release. I've been using release-listingrollups-template.md. |
@gigeld give your scenario of Release 4, 5, 6, 7, where:
I would only expect the $release (and release notes files) to contain Releases 5, 6 and 7 i.e.
Release 4 should not be included as that was successful and its workitem/commits etc are all listed in its release notes. So this behaviour is by design - if I understand you correctly |
@SeanWilliamson2004 Remember that historic releases are only included since the last successful release to the stage being monitored (by default the current stage). This means if you last release succeeded the release notes will only contain information for the current release. If you enable detail logging (set a global variable system.debug set to true) the log file will details out all the choice it made to get the data set |
@SeanWilliamson2004 short answer is no - you are correct the task just does not work that way. Looking at VSTS itself, on the summary page you highlight, it gets the list of work items that differ between the current release and the current one using the REST call request
where 271 and 278 are the release IDs, the important item is that the parameter baseReleaseId is not documented in the API, but the whole of RM REST API is only preview. Similarly a POST request is done to
(with a suitable playload listing commit SHAs) This task could be re-written to use this mechanism, but it would be a very serious rewrite. In fact I think it could be another extension as it does the job in a very different way. All that said, at this time I would be reticent in making this change as the REST calls I need to make are not officially published |
@rfennell you're right - the release of the last successful deployment shouldn't be included in the release notes. We needed that information and without much thinking I thought to be the last release in the $releases variable. Sorry, it was my mistake. |
I'm seeing the same 404 as another user above:
|
@gigeld great so that is one issue sorted - this thread is getting complex! |
@gregpakes Leaping back a long way in this thread to a, previous point you made, yes the VSTS UI seems to have its own magic way to get the differences, as I mentioned above to @SeanWilliamson2004 I am investigating with MS as to when these APIs might be added to the official API Secondly on your last post, can you give some more context?
If this shows data (or the empty data set i.e. not the 4040 error) I think we need to add some more debug logging to show which rest calls are being made. My gut feeling is I suspect it might be due to some TFVC/Git issue. ** which source control is the artifact using?** In fact what are the details of the artifact behind this build? I have modified the logging in 2.2.x to try to help pinpoint this issue |
@rfennell it's all good here. Thanks again for your prompt support! Man, you rock! :) |
@rfennell Thanks for the detailed reply. The 404 is no longer replicatable for me. I suspect the issue is that the builds it is trying to reference have been deleted. Our builds are very big, so we only keep a couple successful ones around. So I am guessing it was trying to get details from the build, but failed with a 404? |
That makes sense, maybe should trap that |
I am going to close this monster, multi person issue. If anyone still has issues please open new issues that focus on just that issue, thanks |
@rfennell Any luck with trapping that 404 error? In our pipelines is thrown when some builds have been deleted (usually by the retention policy). The Generate Release Notes task will still list all the Work Items found in the available builds but because of the 404 errors,, the task will display in red, as 'Failed'. |
I have not looked, let me log a new issue #72 |
Is it possible for the release notes task to roll up the release notes based on the builds that have been generated between deployments to different environments?
For example in my project, every release goes to dev environment, but not all releases make it to test, stage, prod etc.
I would love for the release notes for Prod environment deployment to reflect all the releases/builds that have occurred since last release to Prod.
See:
The text was updated successfully, but these errors were encountered: