Publish releases

[shana]

Allow publishing releases directly from build artifacts available in Visual Studio.

It should probably:

• [ ] Check that the project configuration is in Release mode
• [ ] Fire off a build if one does not exist (or warn?)
• [ ] Ask for tag name
• [ ] Ask for description (need markdown support)

It could also:

• [ ] Generate changelog from closed issues between previous release tag and current branch

  Notice

If you're looking to do this for GSoC, you should concentrate on getting a proposal together rather than start implementing things right away for the feature. If you're not doing this for GSoC, please leave this task for GSoC students, for now (if this task is not picked up for GSoC, then feel free to take it up, but until then, I would prefer to reserve it for GSoC).

[haacked]

:heart_eyes:

[haacked]

At the same time, I want to encourage people to set up a CI deployment (such as from AppVeyor), but this feature would be great for really small projects and one-offs etc.

[shana]

Yeah, I just published a repo with a little thing which might only have a release or two and immediately wanted to upload the latest build as a release. Even if CI is set up later, for bootstrapping a project it would be pretty useful.

[gitexperience]

working around with this project (Releases Management in Visual Studio), is it worth to create a new popup window for that , or do i propose to complete the things within the Team Explorer pad itself?

[shana]

I'm actually leaning towards having our own separate pane for GitHub-specific features instead of putting this stuff in Team Explorer (see #20 for an example of a GitHub feature living in its own space in VS).

For the purposes of this, assume that you have a toolwindow pane to work with outside of Team Explorer.

[gitexperience]

That was a really cool discussion. Lots of measurements were taken into consideration . My question is :- Is it fine to put the "Releases" option in the team explorer shown in the image by arrow.. And then as you click on it , rest of the functionality will be performed on the GITHUB pane?? Any other suggestion on this?

[shana]

My question is :- Is it fine to put the "Releases" option in the team explorer shown in the image by arrow..

Yes, that's reasonable

[haacked]

Yes, that's reasonable

:thumbsup:

[gitexperience]

Ok with the UI part ,The core tasks here seems to be getting build artifacts for new or existing release . What i am thinking is ,Octokit has defined most of the functionality for working with PRs , Releases etc. , i can use them to manage the information to be displayed regarding releases on the GITHUB pane. Now , other thing is to make a new release from the GitHub pane itself, i am thinking of two options to do this :- One is to use REST API and other is to use something like $(Build.ArtifactStagingDirectory) to store build artifacts to some place and then make it accessible while creating releases . After you create the release , all the releases will be shown with download option .. My question is :- Is this approach fine ? Please correct me where i am wrong.
P.S. :- I can also think of reducing the overhead of storing the artifacts at some other place , and make it directly accessible while creating release, need to do some work on that ..

[shana]

@gitexperience Not sure what you mean by storing the artifacts in some other place. Do you mean uploading them somewhere, or copying them somewhere else on the system?

[gitexperience]

Yes ..

[shana]

@gitexperience Can you elaborate on the advantages of doing that?

[gitexperience]

@shana , i thought this as one of the way to use build artifacts. Still finding out a better way to do it , because a issue can arise as you deploy the release to various environments, you will be deploying and validating the same artifacts on all environments. So, storing it somewhere on the system locally might create a problem. Your suggestions on this?

[shana]

@gitexperience I'm sorry, but I honestly don't understand what you're trying to say. The build artifacts are the result of a Visual Studio build and are stored locally in the output directory of the project(s). Why would you need to put them somewhere else?

[gitexperience]

@shana , actually i am taking one possibility in the mind ( i might be wrong ), what if your build produces artifacts outside of the sources directory. But now I think it can be configured based upon the output path which is given using Build properties of the project (even if it points outside the source) . So,then there will be no need to copy it to the separate location ?

[shana]

@gitexperience Yes, where the build is putting the artifacts is not relevant, it'll put them wherever it's configured to put them. A lot of projects, including this one, don't output build artifacts to the default location.

[gitexperience]

@shana , in the image given below Pull Requests, Pulse , Graphs and Issues are pointing directly to the browser . But in the description given here #20 , things were quite arranged , like Pull Requests points to the GitHub pane.

If possible, will you please point me to the code of the commits discussed in the above link ?This will help me.. Because while i was doing a code review, i saw this file PR , it is opening the things in browser.

[shana]

@gitexperience Those are mockups, the code is not done yet.

[gitexperience]

@shana thankyou !! One more thing, i am facing problem with GitHub pane,may be it is not working for my build .

I have some pull requests in my repository and it is not showing anything. Is this feature still in a implementation phase because documentation has not defined any functionality related to GitHub pane ? Looking at the code here GitHubPaneView.xaml.cs , i can see commands but not their implementation , means it is in implementation phase ?

[gitexperience]

If things are still in implementation phase, i would love to join the process completely rather than working on release part only . Its just that i am working around with the codebase , and clearing some doubts .Will not take too long . :)

[shana]

@gitexperience As I said earlier, assume the UI will be hosted in a docked toolwindow. I mentioned #20 as an example of how a feature would likely show up in VS. I suggest you get acquainted wih how VS extensions work, hosting UI on toolwindows, and VS extension APIs.

[gitexperience]

@shana I think it would be fair to use the "ToolWindowPane" class in the click of a "Release" button from the team explorer that would open up the release section in the GitHub pane , rather than creating the release option in "Other Windows" itself.? Right now i am focussing to create the functionalities on the separate toolwindow (as you advised) and then will integrate it with the github pane . Would it be proper ?

[shana]

@gitexperience I've already answered both of those questions before, please read things thoroughly before asking repeated questions (one of them you even answered yourself)

[gitexperience]

@shana I am really sorry for repeated queries , actually i was over-involved with the UX part ,so just want to make sure nothing go wrong , but now after doing a bit of code-review , i feel the things are flexible and extensible. Right now , everything is fine for me regarding .vsct file , except the "Pull Request" shown in the screenshot below :- , i am unable to find this in layout defined in the .vsct file . Please point me to its declaration. Thankyou !!

[shana]

@gitexperience As I said before, those are mockups, the code isn't yet on the main branch. As the notice says, if you're doing this for GSoC you should be concentrating on creating a proposal, not implementing the feature straight away. You should be looking into how VS extensions are done, looking at Octokit.Net, ReactiveUI, and figuring out in general how the workflow will work and what is required to implement it, create mockups of the UI (mockups are wireframes, not the real thing). I'm not going to choose a student based on who is the first to throw code at me, that's not how this works. This is not a race.

[asahajit]

That will be a kick-ass feature. I expect the community version to also get this update.