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.

97 lines
2.3 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
  1. package docker_test
  2. import (
  3. "strings"
  4. "testing"
  5. "github.com/stretchr/testify/assert"
  6. "gerrit.wikimedia.org/r/blubber/config"
  7. "gerrit.wikimedia.org/r/blubber/docker"
  8. "gerrit.wikimedia.org/r/blubber/meta"
  9. )
  10. func TestSingleStageHasNoName(t *testing.T) {
  11. cfg, err := config.ReadYAMLConfig([]byte(`---
  12. version: v4
  13. base: foo/bar
  14. variants:
  15. development: {}`))
  16. assert.Nil(t, err)
  17. dockerOut, _ := docker.Compile(cfg, "development")
  18. dockerfile := dockerOut.String()
  19. assert.Contains(t, dockerfile, "FROM foo/bar\n")
  20. }
  21. func TestMultiStageIncludesStageNames(t *testing.T) {
  22. cfg, err := config.ReadYAMLConfig([]byte(`---
  23. version: v4
  24. base: foo/bar
  25. variants:
  26. build: {}
  27. production:
  28. copies:
  29. - from: build
  30. source: .
  31. destination: .`))
  32. if assert.NoError(t, err) {
  33. dockerOut, _ := docker.Compile(cfg, "production")
  34. dockerfile := dockerOut.String()
  35. assert.Contains(t, dockerfile, "FROM foo/bar AS build\n")
  36. assert.Contains(t, dockerfile, "FROM foo/bar AS production\n")
  37. assert.Equal(t, 1, strings.Count(dockerfile, "FROM foo/bar AS build\n"))
  38. assert.Equal(t, 1, strings.Count(dockerfile, "FROM foo/bar AS production\n"))
  39. }
  40. }
  41. func TestMultipleArtifactsFromSameStage(t *testing.T) {
  42. cfg, err := config.ReadYAMLConfig([]byte(`---
  43. version: v4
  44. base: foo/bar
  45. variants:
  46. build: {}
  47. production:
  48. copies:
  49. - from: build
  50. source: .
  51. destination: .
  52. - from: build
  53. source: bar
  54. destination: bar`))
  55. assert.Nil(t, err)
  56. dockerOut, _ := docker.Compile(cfg, "production")
  57. dockerfile := dockerOut.String()
  58. assert.Contains(t, dockerfile, "FROM foo/bar AS build\n")
  59. assert.Contains(t, dockerfile, "FROM foo/bar AS production\n")
  60. assert.Equal(t, 1, strings.Count(dockerfile, "FROM foo/bar AS build\n"))
  61. assert.Equal(t, 1, strings.Count(dockerfile, "FROM foo/bar AS production\n"))
  62. }
  63. func TestMetaDataLabels(t *testing.T) {
  64. cfg, err := config.ReadYAMLConfig([]byte(`---
  65. version: v4
  66. base: foo/bar
  67. variants:
  68. development: {}`))
  69. assert.Nil(t, err)
  70. dockerOut, _ := docker.Compile(cfg, "development")
  71. dockerfile := dockerOut.String()
  72. version := meta.FullVersion()
  73. assert.Contains(t, dockerfile,
  74. "LABEL blubber.variant=\"development\" blubber.version=\""+version+"\"\n",
  75. )
  76. }