Fix String.Format to handle formatting of multiple types correctly, not only DateTime

[DamienBraillard]

Hi,

First, thanks for the hard work and the great library !

I started using Handlebars.Net and the associated Handlebars.Net.Helpers because I need to format values (which Stubble can't do easily). What I need to format is an "Instant" value representing a date from the "NodaTime" library.

I was quite surprised to get an error The method Format cannot be used on value '2001-11-21T00:00:00Z' of Type 'NodaTime.Instant'.

Looking into the code, it seems that only DateTime is supported:

[HandlebarsWriter(WriterType.String)]
public string Format(object value, string format)
{
    switch (value)
    {
        case DateTime dateTime:
            return dateTime.ToString(format, Context.Configuration.FormatProvider);

        default:
            throw new NotSupportedException($"The method {nameof(Format)} cannot be used on value '{value}' of Type '{value?.GetType()}'.");
    }
}

The method should make use of ICustomFormatter and IFormattable to format values as these interfaces are intended for this purpose (this is what the String.Format method uses to format string). Using these interfaces would allow formatting anything that can be like the String.Format method does.

Here is an example of a failing test that attempts to format a Decimal (But it is the same for NodaTime Instant):

[Fact]
public void TestFormat()
{
    // Arrange
    var data = new { MyValue = 1.2m };
    var template = @"{{String.Format MyValue ""N2""}}";

    var x = data.MyValue.ToString("N2");
    
    // Act
    var compiledTemplate = _target.PublicGetCompiledTemplate(template);

    // Assert
    var rendered = compiledTemplate(data);
    rendered.Should().Be("1.20");
}

[DamienBraillard]

If it's any help about the build failing, it seems that the task "Prepare analysis on SonarCloud" did not run because: "References service endpoint. PRs from repository forks are not allowed to access secrets in the pipeline. For more information see https://go.microsoft.com/fwlink/?linkid=862029"

This then caused the "SonarCloud: Run Code Analysis" task to fail because it was not prepared !

[StefH]

@DamienBraillard . Thank you for the PR. I'll take a look.

About the CI-build failing, I don't know/see the difference between this CI build and this CI build (https://github.com/WireMock-Net/WireMock.Net/blob/master/azure-pipelines-ci.yml)

A PR on WireMock.Net does work correctly?
WireMock-Net/WireMock.Net#607

[0xced]

About the CI failure: The step Prepare analysis on SonarCloud did not run, eventually causing the SonarCloud: Run Code Analysis step to fail. The following warning gives a hint at what is happening:

References service endpoint. PRs from repository forks are not allowed to access secrets in the pipeline. For more information see https://go.microsoft.com/fwlink/?linkid=862029

How is you RUN_SONAR variable configured? Is it marked as secret in your Azure DevOps configuration?

See the Azure Pipelines documentation on Contributions from forks:

By default with GitHub pipelines, secrets associated with your build pipeline are not made available to pull request builds of forks. These secrets are enabled by default with GitHub Enterprise Server pipelines. Secrets include:

• A security token with access to your GitHub repository.
• These items, if your pipeline uses them:
  • Service connection credentials
  • Files from the secure files library
  • Build variables marked secret

[StefH]

@0xced
No, only the MyGet key is secret, see:

[0xced]

The secret variables was not the cause. Searching for "PRs from repository forks are not allowed to access secrets in the pipeline" lead me to the source code of the Azure Pipeline agent runner. And the key in this error message was this: References service endpoint.

Apparently, the task is skipped because you have configured service connection credentials.

[StefH]

@0xced
For my other project, I've this set:

And for this project, this checkbox is not enabled.

However, I think that enabling this checkbox is unsafe, like someone can see the secret MyGetKey ?

[0xced]

However, I think that enabling this checkbox is unsafe, like someone can see the secret MyGetKey ?

Indeed, your secret MyGetKey could be retrieved by someone forking your repository if you make secrets available to builds of forks and you don't want that.

Do you have a service connection configured? I think this could be the actual cause of the skipped task. The secret variables was just red herring.

[StefH]

Correct, I've a service connection:

[StefH]

@DamienBraillard @0xced

I think for now I'll approve + merge this PR.

And update the pipeline yml to include ne(variables['Build.Reason'], 'PullRequest') for the sonarcloud and myget steps