Bump Scriban from 5.0.0 to 5.5.1 in /src #146
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?s=60&v=4){kind=small}
Bumps [Scriban](https://github.com/scriban/scriban) from 5.0.0 to 5.5.1. - [Release notes](https://github.com/scriban/scriban/releases) - [Changelog](https://github.com/scriban/scriban/blob/master/changelog.md) - [Commits](scriban/scriban@5.0.0...5.5.1) --- updated-dependencies: - dependency-name: Scriban dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <[email protected]>
dependabot
bot
added
the
dependencies
|
Superseded by #152. |
gep13
added a commit
that referenced
this pull request
Sep 1, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 1, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 1, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 8, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 8, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 8, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 8, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 8, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 8, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 8, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 8, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 8, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 8, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 8, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 8, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 8, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 8, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 8, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 11, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 11, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 11, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 12, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 12, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 12, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 12, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 12, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 26, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 26, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 26, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 26, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 26, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 26, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 26, 2023
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.
gep13
added a commit
that referenced
this pull request
Sep 26, 2023
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.
gep13
added a commit
that referenced
this pull request
Oct 4, 2023
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.
gep13
added a commit
that referenced
this pull request
Oct 4, 2023
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.
gep13
added a commit
that referenced
this pull request
Oct 4, 2023
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.
gep13
added a commit
that referenced
this pull request
Oct 4, 2023
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.
gep13
added a commit
that referenced
this pull request
Oct 4, 2023
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.
gep13
added a commit
that referenced
this pull request
Oct 4, 2023
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.
gep13
added a commit
that referenced
this pull request
Oct 4, 2023
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.
gep13
added a commit
that referenced
this pull request
Nov 10, 2023
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.
gep13
added a commit
that referenced
this pull request
Nov 10, 2023
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.
gep13
added a commit
that referenced
this pull request
Nov 10, 2023
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.
gep13
added a commit
that referenced
this pull request
Nov 10, 2023
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.
gep13
added a commit
that referenced
this pull request
Nov 10, 2023
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.
gep13
added a commit
that referenced
this pull request
Nov 10, 2023
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.
gep13
added a commit
that referenced
this pull request
Nov 10, 2023
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.
gep13
added a commit
that referenced
this pull request
Nov 10, 2023
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.
gep13
added a commit
that referenced
this pull request
Nov 10, 2023
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.
gep13
added a commit
that referenced
this pull request
Nov 10, 2023
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.
gep13
added a commit
that referenced
this pull request
Nov 10, 2023
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.
gep13
added a commit
that referenced
this pull request
Nov 14, 2023
* release/0.16.0: (36 commits) Bump Octokit from 7.1.0 to 9.0.0 in /src Bump Microsoft.NET.Test.Sdk from 17.7.2 to 17.8.0 in /src Bump NSubstitute from 5.0.0 to 5.1.0 in /src Bump Scriban from 5.7.0 to 5.9.0 in /src Bump IDisposableAnalyzers from 4.0.6 to 4.0.7 in /src Bump Roslynator.Analyzers from 4.5.0 to 4.6.2 in /src Bump YamlDotNet from 13.7.0 to 13.7.1 in /src Bump NUnit from 3.13.3 to 3.14.0 in /src Bump ApprovalTests from 5.8.0 to 5.9.0 in /src Remove unnecessary entries in nuspec files Update src/GitReleaseManager.Cli/GitReleaseManager.Cli.csproj Adjust the nuget nuspec and the chocolatey nuspec to reflect the fact the GitReleaseMAnager.Cli targets net6.0 Switch Cli to only net6.0 and Core to net6.0 and net7.0 (maint) Refactor IoC registration (maint) Update wording and handling of culture (maint) Remove unnecessary code (maint) Fix warnings about lack of culture info (#146) Alter scriban template (#146) Prevent usage of unsupported functionality (#146) Add GitLab VCS Provider ...
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Bumps Scriban from 5.0.0 to 5.5.1.
Release notes
Sourced from Scriban's releases.
... (truncated)
Changelog
Sourced from Scriban's changelog.
Commits
c6ca2f9Update dependenciesee1f66dFix object.eval to not render if a single statement is passed (#470)402fcd9Merge pull request #468 from Mertsch/FixCompactDocumentation6163d77Fix array.compact docudbcd324Merge pull request #457 from bradtglass/doc-fix807466dFix a minor syntax error in the docs for case/when statementse2849b7Merge pull request #450 from kae/masterfbd06d8Add TemplateContext case insensitivity (#449)b849c54Fix auto-indent (#435)5d192a7Improve enumeration by computing last lazily (#428)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)