Skip to content
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

Merged
merged 13 commits into from
Nov 10, 2023
Merged

Add support for GitLab #523

merged 13 commits into from
Nov 10, 2023

Conversation

gep13
Copy link
Member

@gep13 gep13 commented Sep 1, 2023

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?

  1. Create both a public and private repository on GitLab
  2. Get token to allow maintenance of these projects
  3. Create a milestone and some issues using standard GRM labels
  4. Run the create command to create release from the milestone - this will create an "upcoming release"
  5. Run the discard command to delete the release
  6. Run the create command again
  7. Run the publish command to update the release to actually being releases
  8. Run the close command to close the milestone
  9. Run the open command to open the milestone
  10. Run the export command to grab a markdown file version of the release that was created

The 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:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

@gep13 gep13 requested a review from AdmiringWorm September 1, 2023 16:02
@gep13 gep13 force-pushed the support-gitlab branch 5 times, most recently from 509b006 to ad6a575 Compare September 12, 2023 06:29
Copy link
Member

@AdmiringWorm AdmiringWorm left a 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?

src/GitReleaseManager.Cli/Program.cs Outdated Show resolved Hide resolved
src/GitReleaseManager.Cli/Program.cs Outdated Show resolved Hide resolved
src/GitReleaseManager.Core/Commands/AddAssetsCommand.cs Outdated Show resolved Hide resolved
src/GitReleaseManager.Core/Commands/ExportCommand.cs Outdated Show resolved Hide resolved
src/GitReleaseManager.Core/Commands/ExportCommand.cs Outdated Show resolved Hide resolved
src/GitReleaseManager.Core/VcsService.cs Outdated Show resolved Hide resolved
src/GitReleaseManager.Core/VcsService.cs Outdated Show resolved Hide resolved
src/GitReleaseManager.Core/VcsService.cs Outdated Show resolved Hide resolved
src/GitReleaseManager.Core/VcsService.cs Outdated Show resolved Hide resolved
@gep13
Copy link
Member Author

gep13 commented Oct 3, 2023

@AdmiringWorm if/when you get a minute, can you please have another review of this? Thanks!

@gep13 gep13 requested a review from AdmiringWorm October 4, 2023 19:46
@gep13
Copy link
Member Author

gep13 commented Oct 4, 2023

@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.

Copy link
Member

@AdmiringWorm AdmiringWorm left a 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.

gep13 added 13 commits November 10, 2023 20:28
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.
@gep13
Copy link
Member Author

gep13 commented Nov 10, 2023

@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.

@gep13 gep13 merged commit 696a07e into GitTools:develop Nov 10, 2023
2 checks passed
@gep13 gep13 deleted the support-gitlab branch November 10, 2023 20:39
gittools-bot pushed a commit that referenced this pull request Nov 10, 2023
Merge pull request #523 from gep13/support-gitlab

Add support for GitLab
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow management of releases on GitLab
2 participants