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.

102 lines
2.7 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 config
  2. import (
  3. "gerrit.wikimedia.org/r/blubber/build"
  4. )
  5. // VariantConfig holds configuration fields for each defined build variant.
  6. //
  7. type VariantConfig struct {
  8. Includes []string `json:"includes" validate:"dive,variantref"`
  9. Copies CopiesConfig `json:"copies" validate:"omitempty,unique,dive"`
  10. CommonConfig `json:",inline"`
  11. }
  12. // Merge takes another VariantConfig and overwrites this struct's fields.
  13. //
  14. func (vc *VariantConfig) Merge(vc2 VariantConfig) {
  15. vc.Copies.Merge(vc2.Copies)
  16. vc.CommonConfig.Merge(vc2.CommonConfig)
  17. }
  18. // InstructionsForPhase injects build instructions related to dropping
  19. // priviledge and the application entrypoint, then it delegates to its common
  20. // and copies configurations. It also enforces the correct UID/GID on all copy
  21. // instructions returned from deeper config structs.
  22. //
  23. // PhasePrivileged
  24. //
  25. // Ensure the process and file owner is root.
  26. //
  27. // PhasePrivilegeDropped
  28. //
  29. // Ensure the process and file owner is the "lives.as" user.
  30. //
  31. // PhasePreInstall
  32. //
  33. // Ensure the process and file owner is the "lives.as" user.
  34. //
  35. // PhaseInstall
  36. //
  37. // Ensure the process and file owner is the "lives.as" user.
  38. //
  39. // PhasePostInstall
  40. //
  41. // Ensure the process and file owner is the "runs.as" user, unless configured
  42. // to run insecurely as the "lives.as" user. Finally, sets the application
  43. // entrypoint.
  44. //
  45. func (vc *VariantConfig) InstructionsForPhase(phase build.Phase) []build.Instruction {
  46. instructions := vc.CommonConfig.InstructionsForPhase(phase)
  47. var switchUser string
  48. var uid, gid uint
  49. switch phase {
  50. case build.PhasePrivileged:
  51. switchUser = "root"
  52. case build.PhasePrivilegeDropped:
  53. switchUser = vc.Lives.As
  54. uid, gid = vc.Lives.UID, vc.Lives.GID
  55. case build.PhasePreInstall:
  56. uid, gid = vc.Lives.UID, vc.Lives.GID
  57. case build.PhaseInstall:
  58. uid, gid = vc.Lives.UID, vc.Lives.GID
  59. case build.PhasePostInstall:
  60. if vc.Runs.Insecurely.True {
  61. uid, gid = vc.Lives.UID, vc.Lives.GID
  62. } else {
  63. switchUser = vc.Runs.As
  64. uid, gid = vc.Runs.UID, vc.Runs.GID
  65. }
  66. if len(vc.EntryPoint) > 0 {
  67. instructions = append(instructions, build.EntryPoint{vc.EntryPoint})
  68. }
  69. }
  70. // CopiesConfig may not implement InstructionsForPhase for all possible
  71. // phases, which makes the expansion of it here less than efficient, but to
  72. // assume which phases it does implement would result in gross coupling
  73. instructions = append(instructions, vc.Copies.Expand(vc.Lives.In).InstructionsForPhase(phase)...)
  74. if switchUser != "" {
  75. instructions = append(
  76. []build.Instruction{
  77. build.User{switchUser},
  78. build.Home(switchUser),
  79. },
  80. instructions...,
  81. )
  82. }
  83. if uid != 0 {
  84. instructions = build.ApplyUser(uid, gid, instructions)
  85. }
  86. return instructions
  87. }