Skip to content
This repository has been archived by the owner on Jun 21, 2023. It is now read-only.

Publish releases #223

Open
5 tasks
shana opened this issue Feb 19, 2016 · 26 comments
Open
5 tasks

Publish releases #223

shana opened this issue Feb 19, 2016 · 26 comments

Comments

@shana
Copy link
Contributor

shana commented Feb 19, 2016

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
Copy link
Contributor

haacked commented Feb 19, 2016

😍

@haacked
Copy link
Contributor

haacked commented Feb 19, 2016

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
Copy link
Contributor Author

shana commented Feb 19, 2016

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
Copy link
Contributor

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
Copy link
Contributor Author

shana commented Mar 1, 2016

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
Copy link
Contributor

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.. release window
And then as you click on it , rest of the functionality will be performed on the GITHUB pane??
Any other suggestion on this?

@shana
Copy link
Contributor Author

shana commented Mar 1, 2016

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
Copy link
Contributor

haacked commented Mar 1, 2016

Yes, that's reasonable

👍

@gitexperience
Copy link
Contributor

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
Copy link
Contributor Author

shana commented Mar 2, 2016

@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
Copy link
Contributor

Yes ..

@shana
Copy link
Contributor Author

shana commented Mar 2, 2016

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

@gitexperience
Copy link
Contributor

@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
Copy link
Contributor Author

shana commented Mar 2, 2016

@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
Copy link
Contributor

@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
Copy link
Contributor Author

shana commented Mar 2, 2016

@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
Copy link
Contributor

@shana , in the image given below
query
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
Copy link
Contributor Author

shana commented Mar 3, 2016

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

@gitexperience
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link
Contributor Author

shana commented Mar 3, 2016

@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
Copy link
Contributor

@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
Copy link
Contributor Author

shana commented Mar 4, 2016

@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
Copy link
Contributor

@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 :-
pull request , i am unable to find this in layout defined in the .vsct file . Please point me to its declaration.
Thankyou !!

@shana
Copy link
Contributor Author

shana commented Mar 6, 2016

@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
Copy link

asahajit commented May 18, 2020

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Archived in project
Development

No branches or pull requests

4 participants