Восстановление библиотек Libman JS в Azure DevOps Build Pipeline - PullRequest
2 голосов
/ 14 января 2020

Я настроил счастливый конвейер сборки Azure DevOps, который запускается при фиксации в ветви, затем восстанавливает пакеты Nuget, создает мое веб-приложение Mvc .Core и развертывает его в Azure приложении. Служба.

Однако библиотеки JS, на которые есть ссылки в LibMan, не восстанавливаются и не развертываются в Azure. Как заставить это произойти?

Я включил пакет сборки LibMan (который я прочитал будет выполнять задачу автоматически ), но без радости.

<PackageReference Include="Microsoft.Web.LibraryManager.Build" Version="2.0.96" />    

Действительно ли мне нужно добавить в конвейер пользовательскую команду ядра *. 1024 *, чтобы установить инструмент LibraryManager Cli , а затем вызвать его восстановить библиотеки JS ? Это кажется более сложным, чем я ожидал, и я не нашел примеров того, как кто-то делал бы это онлайн.

Есть ли другой подход для включения библиотек JS в систему контроля версий? Я действительно хотел избежать этого, если это возможно, но если это стандартный подход, то я рад сделать это, я думаю.

Любой совет или примеры YAML способов достижения этого в Azure DevOps будет очень признателен.

Ответы [ 2 ]

2 голосов
/ 15 января 2020

Восстановление Libman JS Библиотеки в Azure DevOps Build Pipeline

Вам не нужно добавлять пользовательскую команду .net core в конвейер для восстановления библиотек JS .

Я создал образец для тестирования LibMan пакета сборки, и он отлично работает на Azure devops.

Чтобы использовать пакет сборки LibMan, сначала необходимо установить правильный libman.json с JS библиотеками в вашем проекте, например:

{
  "version": "1.0",
  "defaultProvider": "cdnjs",
  "libraries": [
    {
      "provider": "cdnjs",
      "library": "jquery@3.2.1",
      "destination": "wwwroot/lib/jquery",
      "files": [
        "jquery.min.js",
        "jquery.js",
        "jquery.min.map"
      ]


    }
  ]
}

Это потому, что пакет LibMan восстановит библиотеки JS на основе libman.json. Вы найдете следующую цель в microsoft.web.librarymanager.build.targets в пакете LibMan:

<Target Name="LibraryManagerRestore" Condition="'$(LibraryRestore)' != 'False'">

    <Microsoft.Web.LibraryManager.Build.RestoreTask
        FileName="libman.json"
        ProjectDirectory="$(MSBuildProjectDirectory)"
        ProviderAssemblies="$(LibraryProviderAssemblies)">

        <Output TaskParameter="FilesWritten" ItemName="_FilesWritten"/>
    </Microsoft.Web.LibraryManager.Build.RestoreTask>

    <ItemGroup>
        <FilesForPackagingFromProject  Include="%(_FilesWritten.Identity)">
            <DestinationRelativePath>%(_FilesWritten.Identity)</DestinationRelativePath>
        </FilesForPackagingFromProject>
    </ItemGroup>
</Target>

. Эти цели будут анализироваться только MSBuild во время сборки,

Итак , во-вторых, эти JS библиотеки будут восстановлены, когда вы соберете свой проект вместо восстановления пакетов.

В качестве теста я удаляю JS libraries из своего репозитория:

enter image description here

Затем, после завершения сборки tnet, я могу получить JS libraries в папке wwwroot/lib/jquery:

enter image description here

Если проблема все еще не решена, убедитесь, что вы можете восстановить библиотеки JS при сборке из Visual Studio без Azure Devops.

Кстати, вы также можете использовать задачу Libman (Preview) вместо MSBuild для восстановления пакетов, определенных в libman.json.

Надеюсь, это поможет.

1 голос
/ 20 января 2020

Проблема с восстановлением библиотек LibMan JS в нашем случае оказалась настройкой файла проекта, добавленной другим разработчиком месяцы go, когда у них были проблемы с медленным временем сборки, , как упоминалось здесь .

 <PropertyGroup>
    <LibraryRestore>false</LibraryRestore>
  </PropertyGroup>

Как только я нашел и удалил этот параметр, неудивительно, что восстановление LibMan работало отлично, и без особенно медленного времени сборки.

Я думаю, идеальная ситуация была бы не пытаться выполнить восстановление LibMan при каждой сборке, но вручную на машинах разработчика, а затем в качестве конкретного шага c в конвейере сборки DevOps? Но в любом случае, теперь все работает.

...