Option two is to integrate the Systemd nix service with the existing NixOs home manager configuration as part of the service. # so rather than creating our own restart mechanism, we leverage systemd to do this for us. # Unfortunately the monitor does not kill itself when it stops monitoring, # Even if it is later recreated it will not restart monitoring it. # When a monitored directory is deleted, it will stop being monitored. # See the comments above Restart in the service config.ĭone < <(inotifywait -q -m -e CREATE,ISDIR -e DELETE_SELF -format '%w%f:%e' "$bin_dir")ĭescription = "Automatically fix the VS Code server used by the remote SSH extension" when "Uninstall VS Code Server from Host" has been run. # The monitored directory is deleted, e.g. Inotifywait -qq -e DELETE_SELF "$bin_dir/node" # Create a trigger to know when their node is being created and replace it for our symlink. # A new version of the VS Code Server is being created. NixosConfigurations.some-host = rec \ || Nixos-vscode-server.url ="github:mudrii/nixos-vscode-ssh-fix/main" Nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable" We have two options, both using user Systemd service that monitors /home/$USER/.vscode-server/*. SolutionĪfter some googling, we found few potential solutions we could implement in nix native expressions: Original solution. The workaround that was provided wasn’t elegant for our taste and we strive to automate our infrastructure as code in all aspects and any manual fix wasn’t acceptable. You can find a good description in the VScode GitHub issue. Problem to Be Solvedĭuring initial testing, we noticed once we try to connect to a remote ssh development environment, we encounter errors due to the nature of Nix. All our NixOs configuration was in the git repository.Ī good source of the documentation Remote Development using SSH and Remote Development Tips and Tricks. NixOS is based on nix functional programming configuration language where everything is declarative. My team used the VScode Remote SSH plugin to develop applications from Local laptops and remote Google Cloud VM running on NixOS.ĭevelopment laptops that the team was using were limited in resources.įrom the beginning, we decided to use remote development on NixOs as it allowed us to manage consistency in package management and manage dependency for Python and node.js projects.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |