From 23fc4b1f086971d2e8a2b9fbada324334d97d6d2 Mon Sep 17 00:00:00 2001
From: Roger Peppe <rogpeppe@gmail.com>
Date: Tue, 23 Jul 2024 10:42:35 +0100
Subject: [PATCH] cmd/cue: add tests for symbolic links
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This adds explicit tests for the behavior of CUE when it encounters
symbolic links. Namely:

- symbolic links are followed for files that are directly part of the
build.
- symbolic links are disallowed for embedded files.
- symbolic links are silently dropped when publishing modules.

Modulo the fact that modules did not exist previously, this
matches previous behavior (checked against v0.4.3): the
non-module parts of `symlink.txtar` test pass against v0.4.3.

For #3300.

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: Iaf6c4668101f3e91d78a8cab5734efea0a2a9624
Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1198252
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
---
 cmd/cue/cmd/testdata/script/symlink.txtar | 109 ++++++++++++++++++++++
 1 file changed, 109 insertions(+)
 create mode 100644 cmd/cue/cmd/testdata/script/symlink.txtar

diff --git a/cmd/cue/cmd/testdata/script/symlink.txtar b/cmd/cue/cmd/testdata/script/symlink.txtar
new file mode 100644
index 00000000000..4ed0dd1c996
--- /dev/null
+++ b/cmd/cue/cmd/testdata/script/symlink.txtar
@@ -0,0 +1,109 @@
+[!unix] skip 'no symbolic links available for this test'
+
+# This test tests behaviour around symbolic links:
+# - symbolic links are followed for files that are directly part of the build.
+# - symbolic links are disallowed for embedded files.
+# - symbolic links are silently dropped when publishing modules.
+
+# TODO this does not test behavior when a zip file contains
+# a symbolic link, but simple inspection of the modzip.Unzip
+# code suffices to prove that no symbolic links can be created.
+# If someone is using their own code to create zip files rather than
+# modzip (hopefully unlikely) and those zip files contain symbolic
+# links, then it's their own fault and nothing especially untoward
+# should happen.
+
+# Symbolic link is followed for a single file.
+symlink y.cue -> x.cue
+exec cue eval y.cue
+cmp stdout want-stdout-1
+
+# Symbolic link is followed when part of a package,
+# including when there are dependencies.
+symlink z.cue -> _p/z.cue
+! exec cue eval
+stderr 'cannot find package "deps.example/d1"'
+exec cue mod tidy
+cmp cue.mod/module.cue want-module
+exec cue eval
+cmp stdout want-stdout-2
+
+# Check what happens when a module with symlinks is
+# published to a registry.
+memregistry MEMREGISTRY
+env CUE_REGISTRY=test.example=$MEMREGISTRY+insecure,$CUE_REGISTRY
+exec cue mod publish v0.0.1
+cd _use_main
+exec cue mod tidy
+cmp cue.mod/module.cue $WORK/want-module-2
+exec cue eval
+cmp stdout $WORK/want-stdout-3
+
+-- want-stdout-1 --
+x: true
+-- want-module --
+module: "test.example/main"
+language: {
+	version: "v0.9.2"
+}
+source: {
+	kind: "self"
+}
+deps: {
+	"deps.example/d1@v0": {
+		v:       "v0.0.1"
+		default: true
+	}
+}
+-- want-module-2 --
+module: "test2.example/main"
+language: {
+	version: "v0.9.2"
+}
+deps: {
+	"test.example/main@v0": {
+		v:       "v0.0.1"
+		default: true
+	}
+}
+-- want-stdout-2 --
+x: true
+z: true
+dep: {
+    self: "deps.example/d1"
+}
+-- want-stdout-3 --
+x: true
+-- cue.mod/module.cue --
+module: "test.example/main"
+language: version: "v0.9.2"
+source: kind: "self"
+
+-- x.cue --
+package main
+
+x: true
+-- _p/z.cue --
+package main
+
+import "deps.example/d1"
+
+z: true
+dep: d1
+-- _use_main/main.cue --
+package main
+
+import "test.example/main"
+
+main
+-- _use_main/cue.mod/module.cue --
+module: "test2.example/main"
+language: version: "v0.9.2"
+
+-- _registry/deps.example_d1_v0.0.1/cue.mod/module.cue --
+module: "deps.example/d1"
+language: version: "v0.9.2"
+
+-- _registry/deps.example_d1_v0.0.1/x.cue --
+package d1
+self: "deps.example/d1"