Support Azure Devops

[neist]

Hi

I'm using semantic-release with GIT on Azure Devops (not my choice).

Unfortunately Azure Devops is not covered by hosts-config.js and I have to adjust urls for issues and commits, because Azure Devops isn't following the normal url pattern - see this.

In order to do this I've tried using custom partials in writerOpts, but I have a few cases where this is not enough. If however I could modify the context (not just finalizeContext), I could make everything work correctly.

So my suggestion is to make it possible to provide changelogContext through Options, in order to handle edge cases, where hosts-config.js isn't covering.

Something like this:

module.exports = {
  plugins: [
    "@semantic-release/commit-analyzer",
    [
      "@semantic-release/release-notes-generator",
      {
        changelogContext: {
          host: "https://dev.azure.com/",
          owner: "[AzureOrganization]",
          repository: "[AzureProject]",
          commit: "_git/[AzureRepo]/commit",
          issue: "_workitems/edit"
        }
      }
    ]
  ]
}

I will gladly provide a pull request, if you agree with the need for this.

All the best!

[pvdlg]

I would prefer to not add a new option and instead improve the algorithm to detect Azure URLs and generate changelogContext properly.

[neist]

That's fair. The only reason I suggested to do it through changelogContext, was because simply detecting and extending hosts-config.js will not make it work correctly. It's still necessary to provide custom partials to conventional-commits-writer in order to handle the non-standard URL format Azure DevOps is using. I believe this situation is an edge-case and changelogContext provides a needed "escape hatch".

[pvdlg]

Can you provide an example of the edge case you are talking about? Like in which case we won't be able to determine all the values for changelogContext based on the repository URL?

[pvdlg]

Closing as no answer was provided

[ronnetzer]

@pvdlg Is there any plan to add support to azure DevOps?
Currently, I'm unable to link issues correctly as <repository> isn't part of the url.
Azure formats are:
commit: <host>/<owner>/_git/<repository>/commit/<commit-sha>
issue: <host>/<owner>/_workitems/edit/<issue-number>

the <host> will usually be <organization>.visualstudio.com.

also ssh format is a bit different:
<organization>@vs-ssh.visualstudio.com:v3/<organization>/<owner>/<repository>

edit:
just sharing the solution if anyone else also has this issue

module.export = {
  ...,
  plugins: [
    ...,
    ['@semantic-release/release-notes-generator', {
      preset: 'angular',
      writerOpts: {
        finalizeContext: function(context) {
          return {
            ...context,
            repository: null,
            repoUrl: '<host>/<owner>',
            commit: '_git/<repository>/commit',
            issue: '_workitems/edit'
          };
        }
      }
    }]
  ]
}

[patr00n]

@pvdlg default issue link format isn't suitable for Azure DevOps, because issues there don't belong to repositories.
Here is the actual pattern: https://dev.azure.com/<owner>/<project>/_workitems/edit/<issue_number>/ I think it can be useful to add a property that can accept full issues path.
So could you please reopen this issue?

[nausaf]

ronnetzer's solution didn't work for me. I also tried setting repository and repoUrl to different values which didn't work either:

writerOpts: {
          finalizeContext: function (context) {
            return {
              ...context,
              repository: process.env.SYSTEM_TEAMPROJECT,
              repoUrl: process.env.SYSTEM_COLLECTIONURI,
              commit: '_git/<repository>/commit',
              issue: '_workitems/edit',
            };
          },
        },

This could be because I am using preset: 'conventionalcommits' instead of preset: 'angular'.

What did work was adding issueUrlFormat and commitUrlFormat to presetConfig in configuration of @semantic-release/release-notes-generator, as follows:

...,
[
      '@semantic-release/release-notes-generator',
      {
        preset: 'conventionalcommits',
        presetConfig: {
            ...,
            issueUrlFormat: `${process.env.SYSTEM_COLLECTIONURI}{{repository}}/_workitems/edit/{{id}}/`,
          commitUrlFormat: `${process.env.SYSTEM_COLLECTIONURI}{{repository}}/_git/{{repository}}/commit/{{hash}}`,
        },
        writerOpts: {
          finalizeContext: function (context) {
            return {
              ...context,
              repository: process.env.SYSTEM_TEAMPROJECT,
              repoUrl: process.env.SYSTEM_COLLECTIONURI,
              commit: '_git/<repository>/commit',
              issue: '_workitems/edit',
            };
          },
        },
        //parserOpts really does need to be duplicated here
        //(declaring it in the commitAnalyzer plugin once is not enough)
        //probabaly because release-notes-generator too has to parse
        //the commits
        parserOpts: {
          mergePattern:
            '^Merged PR (\\d+): (\\w*)(?:\\(([\\w\\$\\.\\-\\*]*)\\))?\\: (.*)$',
          mergeCorrespondence: ['id', 'type', 'scope', 'subject'],
          noteKeywords: ['BREAKING CHANGE', 'BREAKING CHANGES'],
        },
    },
],

Note that I still need that writerOpts even if it doesn't work as if I take it out the generated release notes do not have commit link nor the issue link. This would happen even if I replace all references to {{repository}} in issueUrlFormat and commitUrlFormat with actual value of repository (${process.env.SYSTEM_TEAMPROJECT}).

By the way, expressions like process.env.SYSTEM_TEAMPROJECT evaluate to Azure Pipelines predefined variables like System.TeamProject. As the predefined variables page states:

In YAML pipelines, you can reference predefined variables as environment variables. For example, the variable Build.ArtifactStagingDirectory becomes the variable BUILD_ARTIFACTSTAGINGDIRECTORY.

[faceless7171]

For me solution from @nausaf didn't work either. The one I came up with:

[
      '@semantic-release/release-notes-generator',
      {
        preset: 'conventionalcommits',
        presetConfig: {
          ...,
        issueUrlFormat: `${process.env.SYSTEM_COLLECTIONURI}${process.env.SYSTEM_TEAMPROJECT}/_workitems/edit/{{id}}`,
        commitUrlFormat: `${process.env.SYSTEM_COLLECTIONURI}${process.env.SYSTEM_TEAMPROJECT}/_git/{{repository}}/commit/{{hash}}`
        },
        writerOpts: {
          finalizeContext: function (context) {
            return {
              ...context,
              repository: process.env.BUILD_REPOSITORY_NAME,
              repoUrl: process.env.BUILD_REPOSITORY_URI,
              commit: `_git/<repository>/commit`,
              issue: '_workitems/edit',
            };
          },
        },
        parserOpts: {
          mergePattern:
            '^Merged PR (\\d+): (\\w*)(?:\\(([\\w\\$\\.\\-\\* ]*)\\))?\\: (.*)$',
          mergeCorrespondence: ['id', 'type', 'scope', 'subject'],
          noteKeywords: ['BREAKING CHANGE', 'BREAKING CHANGES'],
        },
    },
],

[scrocquesel-ml150]

@pvdlg Could this issue be reopen ? Given solutions require a shareable configuration or release.config.js and I would prefer to be able to use a yaml semantic release configuration file.