FacilityLanguageServer Package

[jeff-huff]

• Package Facility.LanguageServer as a NuGet package for use with dnx in Agent LSP configurations.

{
  "lspServers": {
    "facility": {
      "command": "dnx",
      "args": [
        "--yes",
        "--prerelease",
        "Facility.LanguageServer",
      ],
      "fileExtensions": {
        ".fsd": "facility",
      }
    }
  }
}

NOTE:

• Needs help with the FaithlifePrivateBuild package actions and probably the ci.yaml. Not sure what doing both the NuGet package and the release file should look like.
• Does it need to package an win-x64 file?
• Will need the Project Secrets configured to publish the package.

[ddunkin]

Packing is failing in CI because of the win-x64 runtime. Maybe we don't need that. I think I was trying to not require a dotnet runtime to be installed on Windows, but that seems like a reasonable requirement.

[ddunkin]

Is this still needed?

[jeff-huff]

Do we still want to create GitHub releases that show up in the repo Releases section? Not sure how that is actually triggered.

What should the relationship between publishing a package and creating a release be? Do we want a package and release on every successful build, or a package on every build and manual release, or both only when a manual release is created?

[ddunkin]

The currently favored convention is a release whenever the version changes. Changing the version should tag the repo, create a release with the zip, and publish nuget packages.

[jeff-huff]

Can you describe the release process? The previous release did not have a tag on the commit.

9de7f6d

[ddunkin]

The process is currently to push a tag to release.

FacilityLanguageServer/README.md

Line 11 in 46ebc47

To publish, use GitHub to [publish a new release](https://github.com/FacilityApi/FacilityLanguageServer/releases) using a new tag called `v1.2.3`, where `1.2.3` matches the version in [Directory.Build.props](https://github.com/FacilityApi/FacilityLanguageServer/blob/master/Directory.Build.props).

The 2.5.2 and 2.5.3 versions were never actually published because no tags were pushed. Other Facility repos use an automatic publish whenever the version changes, e.g. FacilityCSharp.

Because this PR's change would now publish nuget packages, it would be preferable to publish them the same way as the other Facility repos, automatically when the version changes. The VS Code extension includes the language server, which it downloads as a zip from the release at build time. It would be simplest to keep that mechanism rather than add a dependency on a dotnet tool.

cc @ejball

[jeff-huff]

We could add a gh release create <tag> <file> after the publish step but we would need to know the new release tag. If we have gh release run on pushes of tags it would need to build again since artifacts are only available in the same workflow run.

[ddunkin]

For nuget packages, we run publish every time and take advantage of skip duplicates. The rest of the build would have to be smarter about knowing when the new version was actually pushed.

[jeff-huff]

Ok, how about a new workflow that runs on tags and creates the release.

release.yml

[jeff-huff]

I added a guard for windows-latest to the package and upload steps. Not sure why it would fail with those.

[ddunkin]

Let's just remove the Windows-specific build altogether.

[ddunkin]

We do want to keep this zip because this is what the VS Code plugin uses.

[ddunkin]

The Visual Studio extension uses the Windows build. I would think that could be modified to use dotnet instead, but I'm not 100% sure.
https://github.com/FacilityApi/FacilityVisualStudio/blame/a5cd6f81f63927b88547c514605251dc8fc8b80c/README.md#L8

[ejball]

Is this still in progress?

[ddunkin]

Is this still in progress?

I don't really have time to work on it. The tag checking hack is gross. Ideally there would be a clean way to know if a tag was created and create the release then. Or maybe we could always try to create the release and ignore failure?