-
Notifications
You must be signed in to change notification settings - Fork 38
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
Add support for GitLab #523
Conversation
509b006
to
ad6a575
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition, is there any reason why the tests for GitHub specific tests aren't replicated for the GitLab provider?
0e42308
to
090c7df
Compare
@AdmiringWorm if/when you get a minute, can you please have another review of this? Thanks! |
@AdmiringWorm I have fixed up the remaining issues, and squashed them into the PR Review commit. Once you are happy, I can look to squash that commit into other commits, or move forward with it as a standalone commit. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
@gep13 I'll leave it up to you to squash the Review commit whatever commit you feel is appropriate.
7289d26
to
3e51f66
Compare
When exporting releases, if not providing a specific tagName, the output was: Exporting release null Which isn't very helpful. This commit changes this output so that if the tagName is included, include it in the output, if it isn't, assume that all releases are being exported, and output this instead.
Looking at the upcoming work for GitLab, it is clear that we need to extend, at the very least, the internal GRM representation. This is due to the fact that GitLab has both an "internal" and "public" Id for the milestone. It seems to be the case that the internal one, typically a higher number, is used when updating/changing a milestone, whereas the public one is used when linking to a milestone within the project. We need to use both of these, so we need to capture both of them. For something like the GitHub provider, which doesn't make this distinction, we will simply map the single Id to both the internal and public properties.
Within the scriban templates used for creating release notes, there is a hard-coded query string portion, which is used when linking to milestones from the generated release notes. When there was a single VCS provider, i.e. GitHub, this was fine. Now that we are introducing another provider, we need to make this configurable. This commit introduces a new method, GetMilestoneUrlQueryString(), which each VCS provider will need to implement, to return the correct value. In addition, the scriban template has been updated to make use of this, as well as the model that is passed into the generation of the template.
In order to fully support GitLab, we need to introduce come breaking changes to the GitReleaseManager API. GitLab has the concept of both a public and an internal number for things like a milestone. Due to this, the decision has been made to not assume the property that is required for a method. For example, when deleting a release, let's not assume that we want/need the number of the release, instead, let's pass the entire release to the method, and then internally, the implementation of the method can decide what property it needs to use to perform the operation. This approach as been implemented across all of the API surface, so we now pass in the entire Release, or Label, or Issue. This has meant quite a few changes across things like the tests to accommodate this change.
Similar to the last commit for extending the milestone model to have a internal number, we need to do the same thing with the issue model. This is due to the fact that GitLab has both an "internal" and "public" Id for the issue.
Within GitHub, an issue and a pull request are essentially the same thing, at least in terms of how GRM uses them. However, in GitLab, they are uniquely different, and have their own unique numbers, where as in GitHub an issue or pull request just get the next number for the repository. So that we don't have to change too many things in GRM, let's introduce the concept of an IsPullRequest property to the issue model, that way the VcsProvider can provide this information if required, and then use the information to do the right thing when it comes to fetching and updating the information, but internally, GRM will just have a collection of issues, which it then acts on when required.
This commit introduces a new GitLabProvider class, and implements the necessary methods to allow GRM to create release notes on GitLab. This is made possible by using the NGitLab library. A new option has been added to the base command, which allows settings of the --provider at the command line. The default value for this option is GitHub, so everything continues to work as it is expected to.
There are some pieces of functionality that currently either don't make sense to support in GitLab. For example, the label command. This command was originally created to plug a hole in missing functionality on GitHub, however the label management in GitLab is far better, and the crude creation of labels from GRM doesn't make sense. Therefore, any attempt to use this command for GitLab returns an error code. Similarly, the addassets command is not supported. This is mainly due to the fact that assets work very differently in GitLab and we need to figure out how to do what is required via the NGitLab library, as I don't think the support currently exists in there. Finally, the updating of comments when closing a milestone also isn't supported, since this also doesn't seem to be supported in NGitLab, but I will be following up with the team over there to make sure.
GitLab doesn't support emojis when they are "connected" to each other, where GitHub does. Rather than fight this, let's just add a space between the emojis. This doesn't cause any difference in the rendered output, so shouldn't impact on any existing usage.
To only create the client when it is actually required.
3e51f66
to
e208f76
Compare
@AdmiringWorm I have squashed the final commit, and created some others, but the code itself hasn't changed. I am going to move forward with merging this once the CI build completes. |
Merge pull request #523 from gep13/support-gitlab Add support for GitLab
Description
This PR adds support to allow creation, and maintenance of, releases on GitLab. This has been made possible using the NGItLab library. There are some items that have been left unimplemented, see the commit messages for more details.
Related Issue
Fixes #146
Motivation and Context
I work on some projects that use GitLab for private work, and I want the ability to create release notes in the same way as done on public projects on GitHub.
How Has This Been Tested?
create
command to create release from the milestone - this will create an "upcoming release"discard
command to delete the releasecreate
command againpublish
command to update the release to actually being releasesclose
command to close the milestoneopen
command to open the milestoneexport
command to grab a markdown file version of the release that was createdThe above are some sample things to do to verify things are working as expected, but various other tests have also been completed. Let me know if you run into any problems with anything.
Screenshots (if appropriate):
N#A
Checklist: