You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

270 lines
6.9 KiB

Unify `copies` and `artifacts` configuration Refactored `copies` configuration to allow for greater control over when and which both local build context files and variant artifacts are copied into the target image. The new configuration introduces a "local" keyword to signify when a `copies` entry should apply to the files from the local build context as opposed to files from another variant's image during a multi-stage build. variants: build: copies: - from: local source: ./src destination: . Note that with this change, the user must now explicitly define whether _any_ files should be copied in from the local build context. None will be copied in by default. To help keep configurations succinct, especially considering this new requirement, and to approximate the old `copies: variant`, a shorthand format and sane defaults for `source` and `destination` (depending whether `from` is "local" or a variant name) were implemented. variants: build: copies: [local] development: copies: - from: build - from: local source: ./config.dev.yaml destination: ./config.yaml The shorthand: copies: [ref, ...] # is equivalent to copies: [{ from: ref }, ...] And the following defaults are used when no `source` and `destination` are specified. copies: - from: local # defaults to - from: local source: . destination: . copies: - from: variant # defaults to two entries - from: variant source: /srv/app # the lives.in dir destination: /srv/app - from: variant source: /opt/local # the shared lib dir destination: /opt/local Bug: T211625 Change-Id: I4c4217905afc0762b6bd66ed594d43cc0486e3e2
5 years ago
Unify `copies` and `artifacts` configuration Refactored `copies` configuration to allow for greater control over when and which both local build context files and variant artifacts are copied into the target image. The new configuration introduces a "local" keyword to signify when a `copies` entry should apply to the files from the local build context as opposed to files from another variant's image during a multi-stage build. variants: build: copies: - from: local source: ./src destination: . Note that with this change, the user must now explicitly define whether _any_ files should be copied in from the local build context. None will be copied in by default. To help keep configurations succinct, especially considering this new requirement, and to approximate the old `copies: variant`, a shorthand format and sane defaults for `source` and `destination` (depending whether `from` is "local" or a variant name) were implemented. variants: build: copies: [local] development: copies: - from: build - from: local source: ./config.dev.yaml destination: ./config.yaml The shorthand: copies: [ref, ...] # is equivalent to copies: [{ from: ref }, ...] And the following defaults are used when no `source` and `destination` are specified. copies: - from: local # defaults to - from: local source: . destination: . copies: - from: variant # defaults to two entries - from: variant source: /srv/app # the lives.in dir destination: /srv/app - from: variant source: /opt/local # the shared lib dir destination: /opt/local Bug: T211625 Change-Id: I4c4217905afc0762b6bd66ed594d43cc0486e3e2
5 years ago
Unify `copies` and `artifacts` configuration Refactored `copies` configuration to allow for greater control over when and which both local build context files and variant artifacts are copied into the target image. The new configuration introduces a "local" keyword to signify when a `copies` entry should apply to the files from the local build context as opposed to files from another variant's image during a multi-stage build. variants: build: copies: - from: local source: ./src destination: . Note that with this change, the user must now explicitly define whether _any_ files should be copied in from the local build context. None will be copied in by default. To help keep configurations succinct, especially considering this new requirement, and to approximate the old `copies: variant`, a shorthand format and sane defaults for `source` and `destination` (depending whether `from` is "local" or a variant name) were implemented. variants: build: copies: [local] development: copies: - from: build - from: local source: ./config.dev.yaml destination: ./config.yaml The shorthand: copies: [ref, ...] # is equivalent to copies: [{ from: ref }, ...] And the following defaults are used when no `source` and `destination` are specified. copies: - from: local # defaults to - from: local source: . destination: . copies: - from: variant # defaults to two entries - from: variant source: /srv/app # the lives.in dir destination: /srv/app - from: variant source: /opt/local # the shared lib dir destination: /opt/local Bug: T211625 Change-Id: I4c4217905afc0762b6bd66ed594d43cc0486e3e2
5 years ago
Unify `copies` and `artifacts` configuration Refactored `copies` configuration to allow for greater control over when and which both local build context files and variant artifacts are copied into the target image. The new configuration introduces a "local" keyword to signify when a `copies` entry should apply to the files from the local build context as opposed to files from another variant's image during a multi-stage build. variants: build: copies: - from: local source: ./src destination: . Note that with this change, the user must now explicitly define whether _any_ files should be copied in from the local build context. None will be copied in by default. To help keep configurations succinct, especially considering this new requirement, and to approximate the old `copies: variant`, a shorthand format and sane defaults for `source` and `destination` (depending whether `from` is "local" or a variant name) were implemented. variants: build: copies: [local] development: copies: - from: build - from: local source: ./config.dev.yaml destination: ./config.yaml The shorthand: copies: [ref, ...] # is equivalent to copies: [{ from: ref }, ...] And the following defaults are used when no `source` and `destination` are specified. copies: - from: local # defaults to - from: local source: . destination: . copies: - from: variant # defaults to two entries - from: variant source: /srv/app # the lives.in dir destination: /srv/app - from: variant source: /opt/local # the shared lib dir destination: /opt/local Bug: T211625 Change-Id: I4c4217905afc0762b6bd66ed594d43cc0486e3e2
5 years ago
Unify `copies` and `artifacts` configuration Refactored `copies` configuration to allow for greater control over when and which both local build context files and variant artifacts are copied into the target image. The new configuration introduces a "local" keyword to signify when a `copies` entry should apply to the files from the local build context as opposed to files from another variant's image during a multi-stage build. variants: build: copies: - from: local source: ./src destination: . Note that with this change, the user must now explicitly define whether _any_ files should be copied in from the local build context. None will be copied in by default. To help keep configurations succinct, especially considering this new requirement, and to approximate the old `copies: variant`, a shorthand format and sane defaults for `source` and `destination` (depending whether `from` is "local" or a variant name) were implemented. variants: build: copies: [local] development: copies: - from: build - from: local source: ./config.dev.yaml destination: ./config.yaml The shorthand: copies: [ref, ...] # is equivalent to copies: [{ from: ref }, ...] And the following defaults are used when no `source` and `destination` are specified. copies: - from: local # defaults to - from: local source: . destination: . copies: - from: variant # defaults to two entries - from: variant source: /srv/app # the lives.in dir destination: /srv/app - from: variant source: /opt/local # the shared lib dir destination: /opt/local Bug: T211625 Change-Id: I4c4217905afc0762b6bd66ed594d43cc0486e3e2
5 years ago
Unify `copies` and `artifacts` configuration Refactored `copies` configuration to allow for greater control over when and which both local build context files and variant artifacts are copied into the target image. The new configuration introduces a "local" keyword to signify when a `copies` entry should apply to the files from the local build context as opposed to files from another variant's image during a multi-stage build. variants: build: copies: - from: local source: ./src destination: . Note that with this change, the user must now explicitly define whether _any_ files should be copied in from the local build context. None will be copied in by default. To help keep configurations succinct, especially considering this new requirement, and to approximate the old `copies: variant`, a shorthand format and sane defaults for `source` and `destination` (depending whether `from` is "local" or a variant name) were implemented. variants: build: copies: [local] development: copies: - from: build - from: local source: ./config.dev.yaml destination: ./config.yaml The shorthand: copies: [ref, ...] # is equivalent to copies: [{ from: ref }, ...] And the following defaults are used when no `source` and `destination` are specified. copies: - from: local # defaults to - from: local source: . destination: . copies: - from: variant # defaults to two entries - from: variant source: /srv/app # the lives.in dir destination: /srv/app - from: variant source: /opt/local # the shared lib dir destination: /opt/local Bug: T211625 Change-Id: I4c4217905afc0762b6bd66ed594d43cc0486e3e2
5 years ago
Unify `copies` and `artifacts` configuration Refactored `copies` configuration to allow for greater control over when and which both local build context files and variant artifacts are copied into the target image. The new configuration introduces a "local" keyword to signify when a `copies` entry should apply to the files from the local build context as opposed to files from another variant's image during a multi-stage build. variants: build: copies: - from: local source: ./src destination: . Note that with this change, the user must now explicitly define whether _any_ files should be copied in from the local build context. None will be copied in by default. To help keep configurations succinct, especially considering this new requirement, and to approximate the old `copies: variant`, a shorthand format and sane defaults for `source` and `destination` (depending whether `from` is "local" or a variant name) were implemented. variants: build: copies: [local] development: copies: - from: build - from: local source: ./config.dev.yaml destination: ./config.yaml The shorthand: copies: [ref, ...] # is equivalent to copies: [{ from: ref }, ...] And the following defaults are used when no `source` and `destination` are specified. copies: - from: local # defaults to - from: local source: . destination: . copies: - from: variant # defaults to two entries - from: variant source: /srv/app # the lives.in dir destination: /srv/app - from: variant source: /opt/local # the shared lib dir destination: /opt/local Bug: T211625 Change-Id: I4c4217905afc0762b6bd66ed594d43cc0486e3e2
5 years ago
Unify `copies` and `artifacts` configuration Refactored `copies` configuration to allow for greater control over when and which both local build context files and variant artifacts are copied into the target image. The new configuration introduces a "local" keyword to signify when a `copies` entry should apply to the files from the local build context as opposed to files from another variant's image during a multi-stage build. variants: build: copies: - from: local source: ./src destination: . Note that with this change, the user must now explicitly define whether _any_ files should be copied in from the local build context. None will be copied in by default. To help keep configurations succinct, especially considering this new requirement, and to approximate the old `copies: variant`, a shorthand format and sane defaults for `source` and `destination` (depending whether `from` is "local" or a variant name) were implemented. variants: build: copies: [local] development: copies: - from: build - from: local source: ./config.dev.yaml destination: ./config.yaml The shorthand: copies: [ref, ...] # is equivalent to copies: [{ from: ref }, ...] And the following defaults are used when no `source` and `destination` are specified. copies: - from: local # defaults to - from: local source: . destination: . copies: - from: variant # defaults to two entries - from: variant source: /srv/app # the lives.in dir destination: /srv/app - from: variant source: /opt/local # the shared lib dir destination: /opt/local Bug: T211625 Change-Id: I4c4217905afc0762b6bd66ed594d43cc0486e3e2
5 years ago
Unify `copies` and `artifacts` configuration Refactored `copies` configuration to allow for greater control over when and which both local build context files and variant artifacts are copied into the target image. The new configuration introduces a "local" keyword to signify when a `copies` entry should apply to the files from the local build context as opposed to files from another variant's image during a multi-stage build. variants: build: copies: - from: local source: ./src destination: . Note that with this change, the user must now explicitly define whether _any_ files should be copied in from the local build context. None will be copied in by default. To help keep configurations succinct, especially considering this new requirement, and to approximate the old `copies: variant`, a shorthand format and sane defaults for `source` and `destination` (depending whether `from` is "local" or a variant name) were implemented. variants: build: copies: [local] development: copies: - from: build - from: local source: ./config.dev.yaml destination: ./config.yaml The shorthand: copies: [ref, ...] # is equivalent to copies: [{ from: ref }, ...] And the following defaults are used when no `source` and `destination` are specified. copies: - from: local # defaults to - from: local source: . destination: . copies: - from: variant # defaults to two entries - from: variant source: /srv/app # the lives.in dir destination: /srv/app - from: variant source: /opt/local # the shared lib dir destination: /opt/local Bug: T211625 Change-Id: I4c4217905afc0762b6bd66ed594d43cc0486e3e2
5 years ago
Unify `copies` and `artifacts` configuration Refactored `copies` configuration to allow for greater control over when and which both local build context files and variant artifacts are copied into the target image. The new configuration introduces a "local" keyword to signify when a `copies` entry should apply to the files from the local build context as opposed to files from another variant's image during a multi-stage build. variants: build: copies: - from: local source: ./src destination: . Note that with this change, the user must now explicitly define whether _any_ files should be copied in from the local build context. None will be copied in by default. To help keep configurations succinct, especially considering this new requirement, and to approximate the old `copies: variant`, a shorthand format and sane defaults for `source` and `destination` (depending whether `from` is "local" or a variant name) were implemented. variants: build: copies: [local] development: copies: - from: build - from: local source: ./config.dev.yaml destination: ./config.yaml The shorthand: copies: [ref, ...] # is equivalent to copies: [{ from: ref }, ...] And the following defaults are used when no `source` and `destination` are specified. copies: - from: local # defaults to - from: local source: . destination: . copies: - from: variant # defaults to two entries - from: variant source: /srv/app # the lives.in dir destination: /srv/app - from: variant source: /opt/local # the shared lib dir destination: /opt/local Bug: T211625 Change-Id: I4c4217905afc0762b6bd66ed594d43cc0486e3e2
5 years ago
Unify `copies` and `artifacts` configuration Refactored `copies` configuration to allow for greater control over when and which both local build context files and variant artifacts are copied into the target image. The new configuration introduces a "local" keyword to signify when a `copies` entry should apply to the files from the local build context as opposed to files from another variant's image during a multi-stage build. variants: build: copies: - from: local source: ./src destination: . Note that with this change, the user must now explicitly define whether _any_ files should be copied in from the local build context. None will be copied in by default. To help keep configurations succinct, especially considering this new requirement, and to approximate the old `copies: variant`, a shorthand format and sane defaults for `source` and `destination` (depending whether `from` is "local" or a variant name) were implemented. variants: build: copies: [local] development: copies: - from: build - from: local source: ./config.dev.yaml destination: ./config.yaml The shorthand: copies: [ref, ...] # is equivalent to copies: [{ from: ref }, ...] And the following defaults are used when no `source` and `destination` are specified. copies: - from: local # defaults to - from: local source: . destination: . copies: - from: variant # defaults to two entries - from: variant source: /srv/app # the lives.in dir destination: /srv/app - from: variant source: /opt/local # the shared lib dir destination: /opt/local Bug: T211625 Change-Id: I4c4217905afc0762b6bd66ed594d43cc0486e3e2
5 years ago
Unify `copies` and `artifacts` configuration Refactored `copies` configuration to allow for greater control over when and which both local build context files and variant artifacts are copied into the target image. The new configuration introduces a "local" keyword to signify when a `copies` entry should apply to the files from the local build context as opposed to files from another variant's image during a multi-stage build. variants: build: copies: - from: local source: ./src destination: . Note that with this change, the user must now explicitly define whether _any_ files should be copied in from the local build context. None will be copied in by default. To help keep configurations succinct, especially considering this new requirement, and to approximate the old `copies: variant`, a shorthand format and sane defaults for `source` and `destination` (depending whether `from` is "local" or a variant name) were implemented. variants: build: copies: [local] development: copies: - from: build - from: local source: ./config.dev.yaml destination: ./config.yaml The shorthand: copies: [ref, ...] # is equivalent to copies: [{ from: ref }, ...] And the following defaults are used when no `source` and `destination` are specified. copies: - from: local # defaults to - from: local source: . destination: . copies: - from: variant # defaults to two entries - from: variant source: /srv/app # the lives.in dir destination: /srv/app - from: variant source: /opt/local # the shared lib dir destination: /opt/local Bug: T211625 Change-Id: I4c4217905afc0762b6bd66ed594d43cc0486e3e2
5 years ago
Unify `copies` and `artifacts` configuration Refactored `copies` configuration to allow for greater control over when and which both local build context files and variant artifacts are copied into the target image. The new configuration introduces a "local" keyword to signify when a `copies` entry should apply to the files from the local build context as opposed to files from another variant's image during a multi-stage build. variants: build: copies: - from: local source: ./src destination: . Note that with this change, the user must now explicitly define whether _any_ files should be copied in from the local build context. None will be copied in by default. To help keep configurations succinct, especially considering this new requirement, and to approximate the old `copies: variant`, a shorthand format and sane defaults for `source` and `destination` (depending whether `from` is "local" or a variant name) were implemented. variants: build: copies: [local] development: copies: - from: build - from: local source: ./config.dev.yaml destination: ./config.yaml The shorthand: copies: [ref, ...] # is equivalent to copies: [{ from: ref }, ...] And the following defaults are used when no `source` and `destination` are specified. copies: - from: local # defaults to - from: local source: . destination: . copies: - from: variant # defaults to two entries - from: variant source: /srv/app # the lives.in dir destination: /srv/app - from: variant source: /opt/local # the shared lib dir destination: /opt/local Bug: T211625 Change-Id: I4c4217905afc0762b6bd66ed594d43cc0486e3e2
5 years ago
Unify `copies` and `artifacts` configuration Refactored `copies` configuration to allow for greater control over when and which both local build context files and variant artifacts are copied into the target image. The new configuration introduces a "local" keyword to signify when a `copies` entry should apply to the files from the local build context as opposed to files from another variant's image during a multi-stage build. variants: build: copies: - from: local source: ./src destination: . Note that with this change, the user must now explicitly define whether _any_ files should be copied in from the local build context. None will be copied in by default. To help keep configurations succinct, especially considering this new requirement, and to approximate the old `copies: variant`, a shorthand format and sane defaults for `source` and `destination` (depending whether `from` is "local" or a variant name) were implemented. variants: build: copies: [local] development: copies: - from: build - from: local source: ./config.dev.yaml destination: ./config.yaml The shorthand: copies: [ref, ...] # is equivalent to copies: [{ from: ref }, ...] And the following defaults are used when no `source` and `destination` are specified. copies: - from: local # defaults to - from: local source: . destination: . copies: - from: variant # defaults to two entries - from: variant source: /srv/app # the lives.in dir destination: /srv/app - from: variant source: /opt/local # the shared lib dir destination: /opt/local Bug: T211625 Change-Id: I4c4217905afc0762b6bd66ed594d43cc0486e3e2
5 years ago
Unify `copies` and `artifacts` configuration Refactored `copies` configuration to allow for greater control over when and which both local build context files and variant artifacts are copied into the target image. The new configuration introduces a "local" keyword to signify when a `copies` entry should apply to the files from the local build context as opposed to files from another variant's image during a multi-stage build. variants: build: copies: - from: local source: ./src destination: . Note that with this change, the user must now explicitly define whether _any_ files should be copied in from the local build context. None will be copied in by default. To help keep configurations succinct, especially considering this new requirement, and to approximate the old `copies: variant`, a shorthand format and sane defaults for `source` and `destination` (depending whether `from` is "local" or a variant name) were implemented. variants: build: copies: [local] development: copies: - from: build - from: local source: ./config.dev.yaml destination: ./config.yaml The shorthand: copies: [ref, ...] # is equivalent to copies: [{ from: ref }, ...] And the following defaults are used when no `source` and `destination` are specified. copies: - from: local # defaults to - from: local source: . destination: . copies: - from: variant # defaults to two entries - from: variant source: /srv/app # the lives.in dir destination: /srv/app - from: variant source: /opt/local # the shared lib dir destination: /opt/local Bug: T211625 Change-Id: I4c4217905afc0762b6bd66ed594d43cc0486e3e2
5 years ago
Unify `copies` and `artifacts` configuration Refactored `copies` configuration to allow for greater control over when and which both local build context files and variant artifacts are copied into the target image. The new configuration introduces a "local" keyword to signify when a `copies` entry should apply to the files from the local build context as opposed to files from another variant's image during a multi-stage build. variants: build: copies: - from: local source: ./src destination: . Note that with this change, the user must now explicitly define whether _any_ files should be copied in from the local build context. None will be copied in by default. To help keep configurations succinct, especially considering this new requirement, and to approximate the old `copies: variant`, a shorthand format and sane defaults for `source` and `destination` (depending whether `from` is "local" or a variant name) were implemented. variants: build: copies: [local] development: copies: - from: build - from: local source: ./config.dev.yaml destination: ./config.yaml The shorthand: copies: [ref, ...] # is equivalent to copies: [{ from: ref }, ...] And the following defaults are used when no `source` and `destination` are specified. copies: - from: local # defaults to - from: local source: . destination: . copies: - from: variant # defaults to two entries - from: variant source: /srv/app # the lives.in dir destination: /srv/app - from: variant source: /opt/local # the shared lib dir destination: /opt/local Bug: T211625 Change-Id: I4c4217905afc0762b6bd66ed594d43cc0486e3e2
5 years ago
  1. package config_test
  2. import (
  3. "testing"
  4. "github.com/stretchr/testify/assert"
  5. "gerrit.wikimedia.org/r/blubber/build"
  6. "gerrit.wikimedia.org/r/blubber/config"
  7. )
  8. func TestArtifactsConfigYAML(t *testing.T) {
  9. cfg, err := config.ReadYAMLConfig([]byte(`---
  10. version: v4
  11. base: foo
  12. variants:
  13. build: {}
  14. production:
  15. copies:
  16. - from: build
  17. source: /foo/src
  18. destination: /foo/dst
  19. - from: build
  20. source: /bar/src
  21. destination: /bar/dst`))
  22. if assert.NoError(t, err) {
  23. variant, err := config.ExpandVariant(cfg, "production")
  24. if assert.NoError(t, err) {
  25. assert.Len(t, variant.Copies, 2)
  26. assert.Contains(t,
  27. variant.Copies,
  28. config.ArtifactsConfig{From: "build", Source: "/foo/src", Destination: "/foo/dst"},
  29. )
  30. assert.Contains(t,
  31. variant.Copies,
  32. config.ArtifactsConfig{From: "build", Source: "/bar/src", Destination: "/bar/dst"},
  33. )
  34. }
  35. }
  36. }
  37. func TestArtifactsConfigInstructions(t *testing.T) {
  38. cfg := config.ArtifactsConfig{
  39. From: "foo",
  40. Source: "/source/path",
  41. Destination: "/destination/path",
  42. }
  43. t.Run("PhasePrivileged", func(t *testing.T) {
  44. assert.Empty(t, cfg.InstructionsForPhase(build.PhasePrivileged))
  45. })
  46. t.Run("PhasePrivilegeDropped", func(t *testing.T) {
  47. assert.Empty(t, cfg.InstructionsForPhase(build.PhasePrivilegeDropped))
  48. })
  49. t.Run("PhasePreInstall", func(t *testing.T) {
  50. assert.Empty(t, cfg.InstructionsForPhase(build.PhasePreInstall))
  51. })
  52. t.Run("PhaseInstall", func(t *testing.T) {
  53. assert.Equal(t,
  54. []build.Instruction{build.CopyFrom{
  55. "foo",
  56. build.Copy{[]string{"/source/path"}, "/destination/path"},
  57. }},
  58. cfg.InstructionsForPhase(build.PhaseInstall),
  59. )
  60. })
  61. t.Run("PhasePostInstall", func(t *testing.T) {
  62. assert.Empty(t, cfg.InstructionsForPhase(build.PhasePostInstall))
  63. })
  64. }
  65. func TestArtifactsConfigValidation(t *testing.T) {
  66. t.Run("from", func(t *testing.T) {
  67. t.Run("ok", func(t *testing.T) {
  68. _, err := config.ReadYAMLConfig([]byte(`---
  69. version: v4
  70. variants:
  71. build: {}
  72. foo:
  73. copies:
  74. - from: build
  75. source: /foo
  76. destination: /bar`))
  77. assert.False(t, config.IsValidationError(err))
  78. })
  79. t.Run("missing", func(t *testing.T) {
  80. _, err := config.ReadYAMLConfig([]byte(`---
  81. version: v4
  82. variants:
  83. build: {}
  84. foo:
  85. copies:
  86. - from: ~
  87. source: /foo
  88. destination: /bar`))
  89. if assert.True(t, config.IsValidationError(err)) {
  90. msg := config.HumanizeValidationError(err)
  91. assert.Equal(t, `from: is required`, msg)
  92. }
  93. })
  94. t.Run("bad", func(t *testing.T) {
  95. _, err := config.ReadYAMLConfig([]byte(`---
  96. version: v4
  97. variants:
  98. build: {}
  99. foo:
  100. copies:
  101. - from: foo bar
  102. source: /foo
  103. destination: /bar`))
  104. if assert.True(t, config.IsValidationError(err)) {
  105. msg := config.HumanizeValidationError(err)
  106. assert.Equal(t, `from: references an unknown variant "foo bar"`, msg)
  107. }
  108. })
  109. })
  110. t.Run("from: variant", func(t *testing.T) {
  111. t.Run("source", func(t *testing.T) {
  112. t.Run("with no destination given can be empty", func(t *testing.T) {
  113. _, err := config.ReadYAMLConfig([]byte(`---
  114. version: v4
  115. variants:
  116. build: {}
  117. foo:
  118. copies:
  119. - from: build`))
  120. assert.False(t, config.IsValidationError(err))
  121. })
  122. t.Run("with destination given must not be empty", func(t *testing.T) {
  123. _, err := config.ReadYAMLConfig([]byte(`---
  124. version: v4
  125. variants:
  126. build: {}
  127. foo:
  128. copies:
  129. - from: build
  130. destination: /bar`))
  131. if assert.True(t, config.IsValidationError(err)) {
  132. msg := config.HumanizeValidationError(err)
  133. assert.Equal(t, `source: is required if "destination" is also set`, msg)
  134. }
  135. })
  136. })
  137. t.Run("destination", func(t *testing.T) {
  138. t.Run("with no source given can be empty", func(t *testing.T) {
  139. _, err := config.ReadYAMLConfig([]byte(`---
  140. version: v4
  141. variants:
  142. build: {}
  143. foo:
  144. copies:
  145. - from: build`))
  146. assert.False(t, config.IsValidationError(err))
  147. })
  148. t.Run("with source given must not be empty", func(t *testing.T) {
  149. _, err := config.ReadYAMLConfig([]byte(`---
  150. version: v4
  151. variants:
  152. build: {}
  153. foo:
  154. copies:
  155. - from: build
  156. source: /bar`))
  157. if assert.True(t, config.IsValidationError(err)) {
  158. msg := config.HumanizeValidationError(err)
  159. assert.Equal(t, `destination: is required if "source" is also set`, msg)
  160. }
  161. })
  162. })
  163. })
  164. t.Run("from: local", func(t *testing.T) {
  165. t.Run("source", func(t *testing.T) {
  166. t.Run("must be a relative path", func(t *testing.T) {
  167. _, err := config.ReadYAMLConfig([]byte(`---
  168. version: v4
  169. variants:
  170. foo:
  171. copies:
  172. - from: local
  173. source: /bad/path
  174. destination: ./foo`))
  175. if assert.True(t, config.IsValidationError(err)) {
  176. msg := config.HumanizeValidationError(err)
  177. assert.Equal(t, `source: path must be relative when "from" is "local"`, msg)
  178. }
  179. })
  180. t.Run("must not use ../", func(t *testing.T) {
  181. _, err := config.ReadYAMLConfig([]byte(`---
  182. version: v4
  183. variants:
  184. foo:
  185. copies:
  186. - from: local
  187. source: ./funny/../../business
  188. destination: ./foo`))
  189. if assert.True(t, config.IsValidationError(err)) {
  190. msg := config.HumanizeValidationError(err)
  191. assert.Equal(t, `source: path must be relative when "from" is "local"`, msg)
  192. }
  193. })
  194. })
  195. t.Run("destination", func(t *testing.T) {
  196. t.Run("must be a relative path", func(t *testing.T) {
  197. _, err := config.ReadYAMLConfig([]byte(`---
  198. version: v4
  199. variants:
  200. foo:
  201. copies:
  202. - from: local
  203. source: ./foo
  204. destination: /bad/path`))
  205. if assert.True(t, config.IsValidationError(err)) {
  206. msg := config.HumanizeValidationError(err)
  207. assert.Equal(t, `destination: path must be relative when "from" is "local"`, msg)
  208. }
  209. })
  210. t.Run("must not use ../", func(t *testing.T) {
  211. _, err := config.ReadYAMLConfig([]byte(`---
  212. version: v4
  213. variants:
  214. foo:
  215. copies:
  216. - from: local
  217. source: ./foo
  218. destination: ./funny/../../business`))
  219. if assert.True(t, config.IsValidationError(err)) {
  220. msg := config.HumanizeValidationError(err)
  221. assert.Equal(t, `destination: path must be relative when "from" is "local"`, msg)
  222. }
  223. })
  224. })
  225. })
  226. }