[FEATURE] Nightly build pipeline and preview version of VSCode extension

[nselvara]

Hi there,

Thank you very much again for the valuable contributions.
I'd like to propose adding support for nightly builds of the language server as well as a preview release channel for the VSCode extension.

This would allow contributors and advanced users to:

• Test upcoming features and bug fixes early
• Provide feedback before stable releases
• Validate fixes for specific issues (e.g. linked to main branch commits)

---

Proposed features:

• A GitHub Actions-based nightly CI build for the VHDL LS server binary (e.g., uploaded as an artifact or GitHub release with nightly tag)
• A preview version of the VSCode extension (via separate release channel or prerelease tag on the marketplace)

---

Why it’s useful:

• Enables faster testing of bug fixes and experimental features
• Reduces feedback loops for contributors
• Helps in catching regressions early
• Encourages community engagement without destabilising the main release

---

Optional ideas:

• Include the git commit SHA and build timestamp in the LSP version string
• Provide instructions in the README on how to switch to preview/nightly builds

Thanks a lot for your great work - I'd be happy to help test things if this gets set up!

[Xcodo]

Given how few changes there have been to the VSCode extension, I think it would be simpler to use the same extension, but to have an additional option in the vhdlls.languageServer setting. Perhaps embeddedNightly?

[Xcodo]

I could potentially work on this (perhaps slowly!) if @Schottkyc137 is in favour of it.

[nselvara]

That sounds great - I agree that keeping a single VSCode extension and toggling the LSP mode via the vhdlls.languageServer setting (e.g. embeddedNightly) is a clean and user-friendly solution.

Alternatively (or in addition), publishing a preview version of the same extension that can be selected during installation could make it easier for early adopters to opt in without needing to manually adjust settings.

Both approaches could coexist:

• Config toggle (embeddedNightly) - for developers, CI pipelines, and power users
• Preview/insiders channel - for those who just want to "install and go"

By the way, I've drafted a nightly-build.yml GitHub Actions workflow that could serve as a starting point. It hasn't been tested yet, but I'd be happy to help adapt or refine it if needed:

name: Nightly Build

on:
  schedule:
    - cron: '0 1 * * *'  # Every day at 01:00 UTC
  workflow_dispatch:

jobs:
  build-nightly:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Set up Rust
        uses: actions/setup-rust@v1
        with:
          rust-version: stable

      - name: Build project
        run: cargo build --release

      - name: Upload nightly artifact
        uses: actions/upload-artifact@v4
        with:
          name: vhdl-ls-nightly
          path: target/release/vhdl_ls

      - name: Create nightly release
        uses: softprops/action-gh-release@v1
        with:
          tag_name: nightly-${{ github.run_number }}
          name: Nightly Build ${{ github.run_number }}
          body: |
            This is an automated nightly build of `vhdl-ls`.
            Built from commit `${{ github.sha }}` on run `${{ github.run_id }}`.
          draft: false
          prerelease: true
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        continue-on-error: true  # Avoid failure if the release already exists

Happy to help test or polish things on my end once it's underway.
Let's see what @Schottkyc137 thinks - looking forward to it!

Thanks again for the great work!

[Xcodo]

I noticed an exiting PR, VHDL-LS/rust_hdl_vscode#89, that could be an alternative way of doing this too. It has support for "latest" or a defined version, but could also have support for "nightly".

[nselvara]

Yeah, I think this is easily addable and the PR is anyway open - so the change can be added there as well.

[Schottkyc137]

I'm generally very much in favour of this, but don't have time to implement it / it would be low on my priority list. So it's nice to see that there are people interested in developing this. Therefore, It's a +1 from my side.
Concerning the aforementioned PR, I have sort of stopped development for two reasons. The first obviously is time, but the second is the lack of test in rust_hdl_vscode. Essentially I was worried that, if I submit these changes, more things would break than the things that would work. Additionally, there are other popular solutions that already integrate vhdl_ls, so the native extension also landed low on my priority list. But maybe it's worth putting some more effort into this.