2015-09-05 15:49:06 -04:00
|
|
|
package dockerfile
|
2014-08-05 16:17:40 -04:00
|
|
|
|
2014-08-07 01:56:44 -04:00
|
|
|
// This file contains the dispatchers for each command. Note that
|
|
|
|
// `nullDispatch` is not actually a command, but support for commands we parse
|
|
|
|
// but do nothing with.
|
|
|
|
//
|
|
|
|
// See evaluator.go for a higher level discussion of the whole evaluator
|
|
|
|
// package.
|
|
|
|
|
2014-08-05 16:17:40 -04:00
|
|
|
import (
|
|
|
|
"fmt"
|
2015-08-26 19:39:16 -04:00
|
|
|
"os"
|
2014-08-05 18:41:09 -04:00
|
|
|
"path/filepath"
|
2014-10-21 15:26:20 -04:00
|
|
|
"regexp"
|
2015-05-05 11:39:37 -04:00
|
|
|
"runtime"
|
2014-11-12 03:22:08 -05:00
|
|
|
"sort"
|
2014-08-05 16:17:40 -04:00
|
|
|
"strings"
|
2014-08-05 18:41:09 -04:00
|
|
|
|
2015-03-26 18:22:04 -04:00
|
|
|
"github.com/Sirupsen/logrus"
|
2015-12-31 08:57:58 -05:00
|
|
|
"github.com/docker/docker/api"
|
2015-12-16 11:01:36 -05:00
|
|
|
"github.com/docker/docker/builder"
|
2015-08-18 13:30:44 -04:00
|
|
|
"github.com/docker/docker/pkg/signal"
|
2015-08-26 19:39:16 -04:00
|
|
|
"github.com/docker/docker/pkg/system"
|
2015-12-21 20:05:55 -05:00
|
|
|
runconfigopts "github.com/docker/docker/runconfig/opts"
|
2016-01-04 19:05:26 -05:00
|
|
|
"github.com/docker/engine-api/types/container"
|
|
|
|
"github.com/docker/engine-api/types/strslice"
|
2015-12-18 12:58:48 -05:00
|
|
|
"github.com/docker/go-connections/nat"
|
2014-08-05 16:17:40 -04:00
|
|
|
)
|
|
|
|
|
2014-08-07 01:56:44 -04:00
|
|
|
// ENV foo bar
|
|
|
|
//
|
|
|
|
// Sets the environment variable foo to bar, also makes interpolation
|
|
|
|
// in the dockerfile available from the next statement on via ${foo}.
|
|
|
|
//
|
2015-09-06 13:26:40 -04:00
|
|
|
func env(b *Builder, args []string, attributes map[string]bool, original string) error {
|
2014-09-25 22:28:24 -04:00
|
|
|
if len(args) == 0 {
|
Remove static errors from errors package.
Moving all strings to the errors package wasn't a good idea after all.
Our custom implementation of Go errors predates everything that's nice
and good about working with errors in Go. Take as an example what we
have to do to get an error message:
```go
func GetErrorMessage(err error) string {
switch err.(type) {
case errcode.Error:
e, _ := err.(errcode.Error)
return e.Message
case errcode.ErrorCode:
ec, _ := err.(errcode.ErrorCode)
return ec.Message()
default:
return err.Error()
}
}
```
This goes against every good practice for Go development. The language already provides a simple, intuitive and standard way to get error messages, that is calling the `Error()` method from an error. Reinventing the error interface is a mistake.
Our custom implementation also makes very hard to reason about errors, another nice thing about Go. I found several (>10) error declarations that we don't use anywhere. This is a clear sign about how little we know about the errors we return. I also found several error usages where the number of arguments was different than the parameters declared in the error, another clear example of how difficult is to reason about errors.
Moreover, our custom implementation didn't really make easier for people to return custom HTTP status code depending on the errors. Again, it's hard to reason about when to set custom codes and how. Take an example what we have to do to extract the message and status code from an error before returning a response from the API:
```go
switch err.(type) {
case errcode.ErrorCode:
daError, _ := err.(errcode.ErrorCode)
statusCode = daError.Descriptor().HTTPStatusCode
errMsg = daError.Message()
case errcode.Error:
// For reference, if you're looking for a particular error
// then you can do something like :
// import ( derr "github.com/docker/docker/errors" )
// if daError.ErrorCode() == derr.ErrorCodeNoSuchContainer { ... }
daError, _ := err.(errcode.Error)
statusCode = daError.ErrorCode().Descriptor().HTTPStatusCode
errMsg = daError.Message
default:
// This part of will be removed once we've
// converted everything over to use the errcode package
// FIXME: this is brittle and should not be necessary.
// If we need to differentiate between different possible error types,
// we should create appropriate error types with clearly defined meaning
errStr := strings.ToLower(err.Error())
for keyword, status := range map[string]int{
"not found": http.StatusNotFound,
"no such": http.StatusNotFound,
"bad parameter": http.StatusBadRequest,
"conflict": http.StatusConflict,
"impossible": http.StatusNotAcceptable,
"wrong login/password": http.StatusUnauthorized,
"hasn't been activated": http.StatusForbidden,
} {
if strings.Contains(errStr, keyword) {
statusCode = status
break
}
}
}
```
You can notice two things in that code:
1. We have to explain how errors work, because our implementation goes against how easy to use Go errors are.
2. At no moment we arrived to remove that `switch` statement that was the original reason to use our custom implementation.
This change removes all our status errors from the errors package and puts them back in their specific contexts.
IT puts the messages back with their contexts. That way, we know right away when errors used and how to generate their messages.
It uses custom interfaces to reason about errors. Errors that need to response with a custom status code MUST implementent this simple interface:
```go
type errorWithStatus interface {
HTTPErrorStatusCode() int
}
```
This interface is very straightforward to implement. It also preserves Go errors real behavior, getting the message is as simple as using the `Error()` method.
I included helper functions to generate errors that use custom status code in `errors/errors.go`.
By doing this, we remove the hard dependency we have eeverywhere to our custom errors package. Yes, you can use it as a helper to generate error, but it's still very easy to generate errors without it.
Please, read this fantastic blog post about errors in Go: http://dave.cheney.net/2014/12/24/inspecting-errors
Signed-off-by: David Calavera <david.calavera@gmail.com>
2016-02-25 10:53:35 -05:00
|
|
|
return errAtLeastOneArgument("ENV")
|
2014-08-05 16:17:40 -04:00
|
|
|
}
|
|
|
|
|
2014-09-25 22:28:24 -04:00
|
|
|
if len(args)%2 != 0 {
|
|
|
|
// should never get here, but just in case
|
Remove static errors from errors package.
Moving all strings to the errors package wasn't a good idea after all.
Our custom implementation of Go errors predates everything that's nice
and good about working with errors in Go. Take as an example what we
have to do to get an error message:
```go
func GetErrorMessage(err error) string {
switch err.(type) {
case errcode.Error:
e, _ := err.(errcode.Error)
return e.Message
case errcode.ErrorCode:
ec, _ := err.(errcode.ErrorCode)
return ec.Message()
default:
return err.Error()
}
}
```
This goes against every good practice for Go development. The language already provides a simple, intuitive and standard way to get error messages, that is calling the `Error()` method from an error. Reinventing the error interface is a mistake.
Our custom implementation also makes very hard to reason about errors, another nice thing about Go. I found several (>10) error declarations that we don't use anywhere. This is a clear sign about how little we know about the errors we return. I also found several error usages where the number of arguments was different than the parameters declared in the error, another clear example of how difficult is to reason about errors.
Moreover, our custom implementation didn't really make easier for people to return custom HTTP status code depending on the errors. Again, it's hard to reason about when to set custom codes and how. Take an example what we have to do to extract the message and status code from an error before returning a response from the API:
```go
switch err.(type) {
case errcode.ErrorCode:
daError, _ := err.(errcode.ErrorCode)
statusCode = daError.Descriptor().HTTPStatusCode
errMsg = daError.Message()
case errcode.Error:
// For reference, if you're looking for a particular error
// then you can do something like :
// import ( derr "github.com/docker/docker/errors" )
// if daError.ErrorCode() == derr.ErrorCodeNoSuchContainer { ... }
daError, _ := err.(errcode.Error)
statusCode = daError.ErrorCode().Descriptor().HTTPStatusCode
errMsg = daError.Message
default:
// This part of will be removed once we've
// converted everything over to use the errcode package
// FIXME: this is brittle and should not be necessary.
// If we need to differentiate between different possible error types,
// we should create appropriate error types with clearly defined meaning
errStr := strings.ToLower(err.Error())
for keyword, status := range map[string]int{
"not found": http.StatusNotFound,
"no such": http.StatusNotFound,
"bad parameter": http.StatusBadRequest,
"conflict": http.StatusConflict,
"impossible": http.StatusNotAcceptable,
"wrong login/password": http.StatusUnauthorized,
"hasn't been activated": http.StatusForbidden,
} {
if strings.Contains(errStr, keyword) {
statusCode = status
break
}
}
}
```
You can notice two things in that code:
1. We have to explain how errors work, because our implementation goes against how easy to use Go errors are.
2. At no moment we arrived to remove that `switch` statement that was the original reason to use our custom implementation.
This change removes all our status errors from the errors package and puts them back in their specific contexts.
IT puts the messages back with their contexts. That way, we know right away when errors used and how to generate their messages.
It uses custom interfaces to reason about errors. Errors that need to response with a custom status code MUST implementent this simple interface:
```go
type errorWithStatus interface {
HTTPErrorStatusCode() int
}
```
This interface is very straightforward to implement. It also preserves Go errors real behavior, getting the message is as simple as using the `Error()` method.
I included helper functions to generate errors that use custom status code in `errors/errors.go`.
By doing this, we remove the hard dependency we have eeverywhere to our custom errors package. Yes, you can use it as a helper to generate error, but it's still very easy to generate errors without it.
Please, read this fantastic blog post about errors in Go: http://dave.cheney.net/2014/12/24/inspecting-errors
Signed-off-by: David Calavera <david.calavera@gmail.com>
2016-02-25 10:53:35 -05:00
|
|
|
return errTooManyArguments("ENV")
|
2014-09-25 22:28:24 -04:00
|
|
|
}
|
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
if err := b.flags.Parse(); err != nil {
|
2015-05-05 17:27:42 -04:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2015-01-27 10:57:34 -05:00
|
|
|
// TODO/FIXME/NOT USED
|
|
|
|
// Just here to show how to use the builder flags stuff within the
|
|
|
|
// context of a builder command. Will remove once we actually add
|
|
|
|
// a builder command to something!
|
|
|
|
/*
|
2015-09-06 13:26:40 -04:00
|
|
|
flBool1 := b.flags.AddBool("bool1", false)
|
|
|
|
flStr1 := b.flags.AddString("str1", "HI")
|
2015-01-27 10:57:34 -05:00
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
if err := b.flags.Parse(); err != nil {
|
2015-01-27 10:57:34 -05:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
fmt.Printf("Bool1:%v\n", flBool1)
|
|
|
|
fmt.Printf("Str1:%v\n", flStr1)
|
|
|
|
*/
|
|
|
|
|
2014-09-25 22:28:24 -04:00
|
|
|
commitStr := "ENV"
|
|
|
|
|
|
|
|
for j := 0; j < len(args); j++ {
|
|
|
|
// name ==> args[j]
|
|
|
|
// value ==> args[j+1]
|
|
|
|
newVar := args[j] + "=" + args[j+1] + ""
|
|
|
|
commitStr += " " + newVar
|
2014-08-05 16:17:40 -04:00
|
|
|
|
2014-09-25 22:28:24 -04:00
|
|
|
gotOne := false
|
2015-09-06 13:26:40 -04:00
|
|
|
for i, envVar := range b.runConfig.Env {
|
2014-09-25 22:28:24 -04:00
|
|
|
envParts := strings.SplitN(envVar, "=", 2)
|
|
|
|
if envParts[0] == args[j] {
|
2015-09-06 13:26:40 -04:00
|
|
|
b.runConfig.Env[i] = newVar
|
2014-09-25 22:28:24 -04:00
|
|
|
gotOne = true
|
|
|
|
break
|
|
|
|
}
|
2014-08-13 06:07:41 -04:00
|
|
|
}
|
2014-09-25 22:28:24 -04:00
|
|
|
if !gotOne {
|
2015-09-06 13:26:40 -04:00
|
|
|
b.runConfig.Env = append(b.runConfig.Env, newVar)
|
2014-09-25 22:28:24 -04:00
|
|
|
}
|
|
|
|
j++
|
2014-08-13 06:07:41 -04:00
|
|
|
}
|
2014-09-25 22:28:24 -04:00
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
return b.commit("", b.runConfig.Cmd, commitStr)
|
2014-08-05 16:17:40 -04:00
|
|
|
}
|
|
|
|
|
2014-08-07 01:56:44 -04:00
|
|
|
// MAINTAINER some text <maybe@an.email.address>
|
|
|
|
//
|
|
|
|
// Sets the maintainer metadata.
|
2015-09-06 13:26:40 -04:00
|
|
|
func maintainer(b *Builder, args []string, attributes map[string]bool, original string) error {
|
2014-08-05 16:17:40 -04:00
|
|
|
if len(args) != 1 {
|
Remove static errors from errors package.
Moving all strings to the errors package wasn't a good idea after all.
Our custom implementation of Go errors predates everything that's nice
and good about working with errors in Go. Take as an example what we
have to do to get an error message:
```go
func GetErrorMessage(err error) string {
switch err.(type) {
case errcode.Error:
e, _ := err.(errcode.Error)
return e.Message
case errcode.ErrorCode:
ec, _ := err.(errcode.ErrorCode)
return ec.Message()
default:
return err.Error()
}
}
```
This goes against every good practice for Go development. The language already provides a simple, intuitive and standard way to get error messages, that is calling the `Error()` method from an error. Reinventing the error interface is a mistake.
Our custom implementation also makes very hard to reason about errors, another nice thing about Go. I found several (>10) error declarations that we don't use anywhere. This is a clear sign about how little we know about the errors we return. I also found several error usages where the number of arguments was different than the parameters declared in the error, another clear example of how difficult is to reason about errors.
Moreover, our custom implementation didn't really make easier for people to return custom HTTP status code depending on the errors. Again, it's hard to reason about when to set custom codes and how. Take an example what we have to do to extract the message and status code from an error before returning a response from the API:
```go
switch err.(type) {
case errcode.ErrorCode:
daError, _ := err.(errcode.ErrorCode)
statusCode = daError.Descriptor().HTTPStatusCode
errMsg = daError.Message()
case errcode.Error:
// For reference, if you're looking for a particular error
// then you can do something like :
// import ( derr "github.com/docker/docker/errors" )
// if daError.ErrorCode() == derr.ErrorCodeNoSuchContainer { ... }
daError, _ := err.(errcode.Error)
statusCode = daError.ErrorCode().Descriptor().HTTPStatusCode
errMsg = daError.Message
default:
// This part of will be removed once we've
// converted everything over to use the errcode package
// FIXME: this is brittle and should not be necessary.
// If we need to differentiate between different possible error types,
// we should create appropriate error types with clearly defined meaning
errStr := strings.ToLower(err.Error())
for keyword, status := range map[string]int{
"not found": http.StatusNotFound,
"no such": http.StatusNotFound,
"bad parameter": http.StatusBadRequest,
"conflict": http.StatusConflict,
"impossible": http.StatusNotAcceptable,
"wrong login/password": http.StatusUnauthorized,
"hasn't been activated": http.StatusForbidden,
} {
if strings.Contains(errStr, keyword) {
statusCode = status
break
}
}
}
```
You can notice two things in that code:
1. We have to explain how errors work, because our implementation goes against how easy to use Go errors are.
2. At no moment we arrived to remove that `switch` statement that was the original reason to use our custom implementation.
This change removes all our status errors from the errors package and puts them back in their specific contexts.
IT puts the messages back with their contexts. That way, we know right away when errors used and how to generate their messages.
It uses custom interfaces to reason about errors. Errors that need to response with a custom status code MUST implementent this simple interface:
```go
type errorWithStatus interface {
HTTPErrorStatusCode() int
}
```
This interface is very straightforward to implement. It also preserves Go errors real behavior, getting the message is as simple as using the `Error()` method.
I included helper functions to generate errors that use custom status code in `errors/errors.go`.
By doing this, we remove the hard dependency we have eeverywhere to our custom errors package. Yes, you can use it as a helper to generate error, but it's still very easy to generate errors without it.
Please, read this fantastic blog post about errors in Go: http://dave.cheney.net/2014/12/24/inspecting-errors
Signed-off-by: David Calavera <david.calavera@gmail.com>
2016-02-25 10:53:35 -05:00
|
|
|
return errExactlyOneArgument("MAINTAINER")
|
2014-08-05 16:17:40 -04:00
|
|
|
}
|
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
if err := b.flags.Parse(); err != nil {
|
2015-05-05 17:27:42 -04:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2014-08-05 16:17:40 -04:00
|
|
|
b.maintainer = args[0]
|
2015-09-06 13:26:40 -04:00
|
|
|
return b.commit("", b.runConfig.Cmd, fmt.Sprintf("MAINTAINER %s", b.maintainer))
|
2014-08-05 16:17:40 -04:00
|
|
|
}
|
|
|
|
|
2015-02-17 10:20:06 -05:00
|
|
|
// LABEL some json data describing the image
|
|
|
|
//
|
|
|
|
// Sets the Label variable foo to bar,
|
|
|
|
//
|
2015-09-06 13:26:40 -04:00
|
|
|
func label(b *Builder, args []string, attributes map[string]bool, original string) error {
|
2015-02-17 10:20:06 -05:00
|
|
|
if len(args) == 0 {
|
Remove static errors from errors package.
Moving all strings to the errors package wasn't a good idea after all.
Our custom implementation of Go errors predates everything that's nice
and good about working with errors in Go. Take as an example what we
have to do to get an error message:
```go
func GetErrorMessage(err error) string {
switch err.(type) {
case errcode.Error:
e, _ := err.(errcode.Error)
return e.Message
case errcode.ErrorCode:
ec, _ := err.(errcode.ErrorCode)
return ec.Message()
default:
return err.Error()
}
}
```
This goes against every good practice for Go development. The language already provides a simple, intuitive and standard way to get error messages, that is calling the `Error()` method from an error. Reinventing the error interface is a mistake.
Our custom implementation also makes very hard to reason about errors, another nice thing about Go. I found several (>10) error declarations that we don't use anywhere. This is a clear sign about how little we know about the errors we return. I also found several error usages where the number of arguments was different than the parameters declared in the error, another clear example of how difficult is to reason about errors.
Moreover, our custom implementation didn't really make easier for people to return custom HTTP status code depending on the errors. Again, it's hard to reason about when to set custom codes and how. Take an example what we have to do to extract the message and status code from an error before returning a response from the API:
```go
switch err.(type) {
case errcode.ErrorCode:
daError, _ := err.(errcode.ErrorCode)
statusCode = daError.Descriptor().HTTPStatusCode
errMsg = daError.Message()
case errcode.Error:
// For reference, if you're looking for a particular error
// then you can do something like :
// import ( derr "github.com/docker/docker/errors" )
// if daError.ErrorCode() == derr.ErrorCodeNoSuchContainer { ... }
daError, _ := err.(errcode.Error)
statusCode = daError.ErrorCode().Descriptor().HTTPStatusCode
errMsg = daError.Message
default:
// This part of will be removed once we've
// converted everything over to use the errcode package
// FIXME: this is brittle and should not be necessary.
// If we need to differentiate between different possible error types,
// we should create appropriate error types with clearly defined meaning
errStr := strings.ToLower(err.Error())
for keyword, status := range map[string]int{
"not found": http.StatusNotFound,
"no such": http.StatusNotFound,
"bad parameter": http.StatusBadRequest,
"conflict": http.StatusConflict,
"impossible": http.StatusNotAcceptable,
"wrong login/password": http.StatusUnauthorized,
"hasn't been activated": http.StatusForbidden,
} {
if strings.Contains(errStr, keyword) {
statusCode = status
break
}
}
}
```
You can notice two things in that code:
1. We have to explain how errors work, because our implementation goes against how easy to use Go errors are.
2. At no moment we arrived to remove that `switch` statement that was the original reason to use our custom implementation.
This change removes all our status errors from the errors package and puts them back in their specific contexts.
IT puts the messages back with their contexts. That way, we know right away when errors used and how to generate their messages.
It uses custom interfaces to reason about errors. Errors that need to response with a custom status code MUST implementent this simple interface:
```go
type errorWithStatus interface {
HTTPErrorStatusCode() int
}
```
This interface is very straightforward to implement. It also preserves Go errors real behavior, getting the message is as simple as using the `Error()` method.
I included helper functions to generate errors that use custom status code in `errors/errors.go`.
By doing this, we remove the hard dependency we have eeverywhere to our custom errors package. Yes, you can use it as a helper to generate error, but it's still very easy to generate errors without it.
Please, read this fantastic blog post about errors in Go: http://dave.cheney.net/2014/12/24/inspecting-errors
Signed-off-by: David Calavera <david.calavera@gmail.com>
2016-02-25 10:53:35 -05:00
|
|
|
return errAtLeastOneArgument("LABEL")
|
2015-02-17 10:20:06 -05:00
|
|
|
}
|
|
|
|
if len(args)%2 != 0 {
|
|
|
|
// should never get here, but just in case
|
Remove static errors from errors package.
Moving all strings to the errors package wasn't a good idea after all.
Our custom implementation of Go errors predates everything that's nice
and good about working with errors in Go. Take as an example what we
have to do to get an error message:
```go
func GetErrorMessage(err error) string {
switch err.(type) {
case errcode.Error:
e, _ := err.(errcode.Error)
return e.Message
case errcode.ErrorCode:
ec, _ := err.(errcode.ErrorCode)
return ec.Message()
default:
return err.Error()
}
}
```
This goes against every good practice for Go development. The language already provides a simple, intuitive and standard way to get error messages, that is calling the `Error()` method from an error. Reinventing the error interface is a mistake.
Our custom implementation also makes very hard to reason about errors, another nice thing about Go. I found several (>10) error declarations that we don't use anywhere. This is a clear sign about how little we know about the errors we return. I also found several error usages where the number of arguments was different than the parameters declared in the error, another clear example of how difficult is to reason about errors.
Moreover, our custom implementation didn't really make easier for people to return custom HTTP status code depending on the errors. Again, it's hard to reason about when to set custom codes and how. Take an example what we have to do to extract the message and status code from an error before returning a response from the API:
```go
switch err.(type) {
case errcode.ErrorCode:
daError, _ := err.(errcode.ErrorCode)
statusCode = daError.Descriptor().HTTPStatusCode
errMsg = daError.Message()
case errcode.Error:
// For reference, if you're looking for a particular error
// then you can do something like :
// import ( derr "github.com/docker/docker/errors" )
// if daError.ErrorCode() == derr.ErrorCodeNoSuchContainer { ... }
daError, _ := err.(errcode.Error)
statusCode = daError.ErrorCode().Descriptor().HTTPStatusCode
errMsg = daError.Message
default:
// This part of will be removed once we've
// converted everything over to use the errcode package
// FIXME: this is brittle and should not be necessary.
// If we need to differentiate between different possible error types,
// we should create appropriate error types with clearly defined meaning
errStr := strings.ToLower(err.Error())
for keyword, status := range map[string]int{
"not found": http.StatusNotFound,
"no such": http.StatusNotFound,
"bad parameter": http.StatusBadRequest,
"conflict": http.StatusConflict,
"impossible": http.StatusNotAcceptable,
"wrong login/password": http.StatusUnauthorized,
"hasn't been activated": http.StatusForbidden,
} {
if strings.Contains(errStr, keyword) {
statusCode = status
break
}
}
}
```
You can notice two things in that code:
1. We have to explain how errors work, because our implementation goes against how easy to use Go errors are.
2. At no moment we arrived to remove that `switch` statement that was the original reason to use our custom implementation.
This change removes all our status errors from the errors package and puts them back in their specific contexts.
IT puts the messages back with their contexts. That way, we know right away when errors used and how to generate their messages.
It uses custom interfaces to reason about errors. Errors that need to response with a custom status code MUST implementent this simple interface:
```go
type errorWithStatus interface {
HTTPErrorStatusCode() int
}
```
This interface is very straightforward to implement. It also preserves Go errors real behavior, getting the message is as simple as using the `Error()` method.
I included helper functions to generate errors that use custom status code in `errors/errors.go`.
By doing this, we remove the hard dependency we have eeverywhere to our custom errors package. Yes, you can use it as a helper to generate error, but it's still very easy to generate errors without it.
Please, read this fantastic blog post about errors in Go: http://dave.cheney.net/2014/12/24/inspecting-errors
Signed-off-by: David Calavera <david.calavera@gmail.com>
2016-02-25 10:53:35 -05:00
|
|
|
return errTooManyArguments("LABEL")
|
2015-02-17 10:20:06 -05:00
|
|
|
}
|
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
if err := b.flags.Parse(); err != nil {
|
2015-05-05 17:27:42 -04:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2015-02-17 10:20:06 -05:00
|
|
|
commitStr := "LABEL"
|
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
if b.runConfig.Labels == nil {
|
|
|
|
b.runConfig.Labels = map[string]string{}
|
2015-02-17 10:20:06 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
for j := 0; j < len(args); j++ {
|
|
|
|
// name ==> args[j]
|
|
|
|
// value ==> args[j+1]
|
|
|
|
newVar := args[j] + "=" + args[j+1] + ""
|
|
|
|
commitStr += " " + newVar
|
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
b.runConfig.Labels[args[j]] = args[j+1]
|
2015-02-17 10:20:06 -05:00
|
|
|
j++
|
|
|
|
}
|
2015-09-06 13:26:40 -04:00
|
|
|
return b.commit("", b.runConfig.Cmd, commitStr)
|
2015-02-17 10:20:06 -05:00
|
|
|
}
|
|
|
|
|
2014-08-07 01:56:44 -04:00
|
|
|
// ADD foo /path
|
|
|
|
//
|
|
|
|
// Add the file 'foo' to '/path'. Tarball and Remote URL (git, http) handling
|
|
|
|
// exist here. If you do not wish to have this automatic handling, use COPY.
|
|
|
|
//
|
2015-09-06 13:26:40 -04:00
|
|
|
func add(b *Builder, args []string, attributes map[string]bool, original string) error {
|
2014-09-16 12:58:20 -04:00
|
|
|
if len(args) < 2 {
|
Remove static errors from errors package.
Moving all strings to the errors package wasn't a good idea after all.
Our custom implementation of Go errors predates everything that's nice
and good about working with errors in Go. Take as an example what we
have to do to get an error message:
```go
func GetErrorMessage(err error) string {
switch err.(type) {
case errcode.Error:
e, _ := err.(errcode.Error)
return e.Message
case errcode.ErrorCode:
ec, _ := err.(errcode.ErrorCode)
return ec.Message()
default:
return err.Error()
}
}
```
This goes against every good practice for Go development. The language already provides a simple, intuitive and standard way to get error messages, that is calling the `Error()` method from an error. Reinventing the error interface is a mistake.
Our custom implementation also makes very hard to reason about errors, another nice thing about Go. I found several (>10) error declarations that we don't use anywhere. This is a clear sign about how little we know about the errors we return. I also found several error usages where the number of arguments was different than the parameters declared in the error, another clear example of how difficult is to reason about errors.
Moreover, our custom implementation didn't really make easier for people to return custom HTTP status code depending on the errors. Again, it's hard to reason about when to set custom codes and how. Take an example what we have to do to extract the message and status code from an error before returning a response from the API:
```go
switch err.(type) {
case errcode.ErrorCode:
daError, _ := err.(errcode.ErrorCode)
statusCode = daError.Descriptor().HTTPStatusCode
errMsg = daError.Message()
case errcode.Error:
// For reference, if you're looking for a particular error
// then you can do something like :
// import ( derr "github.com/docker/docker/errors" )
// if daError.ErrorCode() == derr.ErrorCodeNoSuchContainer { ... }
daError, _ := err.(errcode.Error)
statusCode = daError.ErrorCode().Descriptor().HTTPStatusCode
errMsg = daError.Message
default:
// This part of will be removed once we've
// converted everything over to use the errcode package
// FIXME: this is brittle and should not be necessary.
// If we need to differentiate between different possible error types,
// we should create appropriate error types with clearly defined meaning
errStr := strings.ToLower(err.Error())
for keyword, status := range map[string]int{
"not found": http.StatusNotFound,
"no such": http.StatusNotFound,
"bad parameter": http.StatusBadRequest,
"conflict": http.StatusConflict,
"impossible": http.StatusNotAcceptable,
"wrong login/password": http.StatusUnauthorized,
"hasn't been activated": http.StatusForbidden,
} {
if strings.Contains(errStr, keyword) {
statusCode = status
break
}
}
}
```
You can notice two things in that code:
1. We have to explain how errors work, because our implementation goes against how easy to use Go errors are.
2. At no moment we arrived to remove that `switch` statement that was the original reason to use our custom implementation.
This change removes all our status errors from the errors package and puts them back in their specific contexts.
IT puts the messages back with their contexts. That way, we know right away when errors used and how to generate their messages.
It uses custom interfaces to reason about errors. Errors that need to response with a custom status code MUST implementent this simple interface:
```go
type errorWithStatus interface {
HTTPErrorStatusCode() int
}
```
This interface is very straightforward to implement. It also preserves Go errors real behavior, getting the message is as simple as using the `Error()` method.
I included helper functions to generate errors that use custom status code in `errors/errors.go`.
By doing this, we remove the hard dependency we have eeverywhere to our custom errors package. Yes, you can use it as a helper to generate error, but it's still very easy to generate errors without it.
Please, read this fantastic blog post about errors in Go: http://dave.cheney.net/2014/12/24/inspecting-errors
Signed-off-by: David Calavera <david.calavera@gmail.com>
2016-02-25 10:53:35 -05:00
|
|
|
return errAtLeastOneArgument("ADD")
|
2014-08-05 16:17:40 -04:00
|
|
|
}
|
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
if err := b.flags.Parse(); err != nil {
|
2015-05-05 17:27:42 -04:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2015-09-29 13:51:40 -04:00
|
|
|
return b.runContextCommand(args, true, true, "ADD")
|
2014-08-05 16:17:40 -04:00
|
|
|
}
|
|
|
|
|
2014-08-07 01:56:44 -04:00
|
|
|
// COPY foo /path
|
|
|
|
//
|
|
|
|
// Same as 'ADD' but without the tar and remote url handling.
|
|
|
|
//
|
2015-09-06 13:26:40 -04:00
|
|
|
func dispatchCopy(b *Builder, args []string, attributes map[string]bool, original string) error {
|
2014-09-16 12:58:20 -04:00
|
|
|
if len(args) < 2 {
|
Remove static errors from errors package.
Moving all strings to the errors package wasn't a good idea after all.
Our custom implementation of Go errors predates everything that's nice
and good about working with errors in Go. Take as an example what we
have to do to get an error message:
```go
func GetErrorMessage(err error) string {
switch err.(type) {
case errcode.Error:
e, _ := err.(errcode.Error)
return e.Message
case errcode.ErrorCode:
ec, _ := err.(errcode.ErrorCode)
return ec.Message()
default:
return err.Error()
}
}
```
This goes against every good practice for Go development. The language already provides a simple, intuitive and standard way to get error messages, that is calling the `Error()` method from an error. Reinventing the error interface is a mistake.
Our custom implementation also makes very hard to reason about errors, another nice thing about Go. I found several (>10) error declarations that we don't use anywhere. This is a clear sign about how little we know about the errors we return. I also found several error usages where the number of arguments was different than the parameters declared in the error, another clear example of how difficult is to reason about errors.
Moreover, our custom implementation didn't really make easier for people to return custom HTTP status code depending on the errors. Again, it's hard to reason about when to set custom codes and how. Take an example what we have to do to extract the message and status code from an error before returning a response from the API:
```go
switch err.(type) {
case errcode.ErrorCode:
daError, _ := err.(errcode.ErrorCode)
statusCode = daError.Descriptor().HTTPStatusCode
errMsg = daError.Message()
case errcode.Error:
// For reference, if you're looking for a particular error
// then you can do something like :
// import ( derr "github.com/docker/docker/errors" )
// if daError.ErrorCode() == derr.ErrorCodeNoSuchContainer { ... }
daError, _ := err.(errcode.Error)
statusCode = daError.ErrorCode().Descriptor().HTTPStatusCode
errMsg = daError.Message
default:
// This part of will be removed once we've
// converted everything over to use the errcode package
// FIXME: this is brittle and should not be necessary.
// If we need to differentiate between different possible error types,
// we should create appropriate error types with clearly defined meaning
errStr := strings.ToLower(err.Error())
for keyword, status := range map[string]int{
"not found": http.StatusNotFound,
"no such": http.StatusNotFound,
"bad parameter": http.StatusBadRequest,
"conflict": http.StatusConflict,
"impossible": http.StatusNotAcceptable,
"wrong login/password": http.StatusUnauthorized,
"hasn't been activated": http.StatusForbidden,
} {
if strings.Contains(errStr, keyword) {
statusCode = status
break
}
}
}
```
You can notice two things in that code:
1. We have to explain how errors work, because our implementation goes against how easy to use Go errors are.
2. At no moment we arrived to remove that `switch` statement that was the original reason to use our custom implementation.
This change removes all our status errors from the errors package and puts them back in their specific contexts.
IT puts the messages back with their contexts. That way, we know right away when errors used and how to generate their messages.
It uses custom interfaces to reason about errors. Errors that need to response with a custom status code MUST implementent this simple interface:
```go
type errorWithStatus interface {
HTTPErrorStatusCode() int
}
```
This interface is very straightforward to implement. It also preserves Go errors real behavior, getting the message is as simple as using the `Error()` method.
I included helper functions to generate errors that use custom status code in `errors/errors.go`.
By doing this, we remove the hard dependency we have eeverywhere to our custom errors package. Yes, you can use it as a helper to generate error, but it's still very easy to generate errors without it.
Please, read this fantastic blog post about errors in Go: http://dave.cheney.net/2014/12/24/inspecting-errors
Signed-off-by: David Calavera <david.calavera@gmail.com>
2016-02-25 10:53:35 -05:00
|
|
|
return errAtLeastOneArgument("COPY")
|
2014-08-05 16:17:40 -04:00
|
|
|
}
|
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
if err := b.flags.Parse(); err != nil {
|
2015-05-05 17:27:42 -04:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2015-09-29 13:51:40 -04:00
|
|
|
return b.runContextCommand(args, false, false, "COPY")
|
2014-08-05 16:17:40 -04:00
|
|
|
}
|
2014-08-05 18:41:09 -04:00
|
|
|
|
2014-08-07 01:56:44 -04:00
|
|
|
// FROM imagename
|
|
|
|
//
|
|
|
|
// This sets the image the dockerfile will build on top of.
|
|
|
|
//
|
2015-09-06 13:26:40 -04:00
|
|
|
func from(b *Builder, args []string, attributes map[string]bool, original string) error {
|
2014-08-05 18:41:09 -04:00
|
|
|
if len(args) != 1 {
|
Remove static errors from errors package.
Moving all strings to the errors package wasn't a good idea after all.
Our custom implementation of Go errors predates everything that's nice
and good about working with errors in Go. Take as an example what we
have to do to get an error message:
```go
func GetErrorMessage(err error) string {
switch err.(type) {
case errcode.Error:
e, _ := err.(errcode.Error)
return e.Message
case errcode.ErrorCode:
ec, _ := err.(errcode.ErrorCode)
return ec.Message()
default:
return err.Error()
}
}
```
This goes against every good practice for Go development. The language already provides a simple, intuitive and standard way to get error messages, that is calling the `Error()` method from an error. Reinventing the error interface is a mistake.
Our custom implementation also makes very hard to reason about errors, another nice thing about Go. I found several (>10) error declarations that we don't use anywhere. This is a clear sign about how little we know about the errors we return. I also found several error usages where the number of arguments was different than the parameters declared in the error, another clear example of how difficult is to reason about errors.
Moreover, our custom implementation didn't really make easier for people to return custom HTTP status code depending on the errors. Again, it's hard to reason about when to set custom codes and how. Take an example what we have to do to extract the message and status code from an error before returning a response from the API:
```go
switch err.(type) {
case errcode.ErrorCode:
daError, _ := err.(errcode.ErrorCode)
statusCode = daError.Descriptor().HTTPStatusCode
errMsg = daError.Message()
case errcode.Error:
// For reference, if you're looking for a particular error
// then you can do something like :
// import ( derr "github.com/docker/docker/errors" )
// if daError.ErrorCode() == derr.ErrorCodeNoSuchContainer { ... }
daError, _ := err.(errcode.Error)
statusCode = daError.ErrorCode().Descriptor().HTTPStatusCode
errMsg = daError.Message
default:
// This part of will be removed once we've
// converted everything over to use the errcode package
// FIXME: this is brittle and should not be necessary.
// If we need to differentiate between different possible error types,
// we should create appropriate error types with clearly defined meaning
errStr := strings.ToLower(err.Error())
for keyword, status := range map[string]int{
"not found": http.StatusNotFound,
"no such": http.StatusNotFound,
"bad parameter": http.StatusBadRequest,
"conflict": http.StatusConflict,
"impossible": http.StatusNotAcceptable,
"wrong login/password": http.StatusUnauthorized,
"hasn't been activated": http.StatusForbidden,
} {
if strings.Contains(errStr, keyword) {
statusCode = status
break
}
}
}
```
You can notice two things in that code:
1. We have to explain how errors work, because our implementation goes against how easy to use Go errors are.
2. At no moment we arrived to remove that `switch` statement that was the original reason to use our custom implementation.
This change removes all our status errors from the errors package and puts them back in their specific contexts.
IT puts the messages back with their contexts. That way, we know right away when errors used and how to generate their messages.
It uses custom interfaces to reason about errors. Errors that need to response with a custom status code MUST implementent this simple interface:
```go
type errorWithStatus interface {
HTTPErrorStatusCode() int
}
```
This interface is very straightforward to implement. It also preserves Go errors real behavior, getting the message is as simple as using the `Error()` method.
I included helper functions to generate errors that use custom status code in `errors/errors.go`.
By doing this, we remove the hard dependency we have eeverywhere to our custom errors package. Yes, you can use it as a helper to generate error, but it's still very easy to generate errors without it.
Please, read this fantastic blog post about errors in Go: http://dave.cheney.net/2014/12/24/inspecting-errors
Signed-off-by: David Calavera <david.calavera@gmail.com>
2016-02-25 10:53:35 -05:00
|
|
|
return errExactlyOneArgument("FROM")
|
2014-08-05 18:41:09 -04:00
|
|
|
}
|
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
if err := b.flags.Parse(); err != nil {
|
2015-05-05 17:27:42 -04:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2014-08-05 18:41:09 -04:00
|
|
|
name := args[0]
|
|
|
|
|
2016-01-03 22:45:06 -05:00
|
|
|
var (
|
|
|
|
image builder.Image
|
|
|
|
err error
|
|
|
|
)
|
|
|
|
|
2015-08-14 21:17:19 -04:00
|
|
|
// Windows cannot support a container with no base image.
|
2015-12-31 08:57:58 -05:00
|
|
|
if name == api.NoBaseImageSpecifier {
|
2015-08-14 21:17:19 -04:00
|
|
|
if runtime.GOOS == "windows" {
|
|
|
|
return fmt.Errorf("Windows does not support FROM scratch")
|
|
|
|
}
|
2014-10-28 17:06:23 -04:00
|
|
|
b.image = ""
|
|
|
|
b.noBaseImage = true
|
2016-01-03 22:45:06 -05:00
|
|
|
} else {
|
|
|
|
// TODO: don't use `name`, instead resolve it to a digest
|
|
|
|
if !b.options.PullParent {
|
2016-01-20 18:32:02 -05:00
|
|
|
image, err = b.docker.GetImageOnBuild(name)
|
2016-01-03 22:45:06 -05:00
|
|
|
// TODO: shouldn't we error out if error is different from "not found" ?
|
|
|
|
}
|
|
|
|
if image == nil {
|
2016-03-18 17:42:40 -04:00
|
|
|
image, err = b.docker.PullOnBuild(b.clientCtx, name, b.options.AuthConfigs, b.Output)
|
2016-01-03 22:45:06 -05:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2014-08-05 18:41:09 -04:00
|
|
|
}
|
|
|
|
}
|
2016-01-03 22:45:06 -05:00
|
|
|
|
2015-09-29 13:51:40 -04:00
|
|
|
return b.processImageFrom(image)
|
2014-08-05 18:41:09 -04:00
|
|
|
}
|
|
|
|
|
2014-08-07 01:56:44 -04:00
|
|
|
// ONBUILD RUN echo yo
|
|
|
|
//
|
|
|
|
// ONBUILD triggers run when the image is used in a FROM statement.
|
|
|
|
//
|
|
|
|
// ONBUILD handling has a lot of special-case functionality, the heading in
|
|
|
|
// evaluator.go and comments around dispatch() in the same file explain the
|
|
|
|
// special cases. search for 'OnBuild' in internals.go for additional special
|
|
|
|
// cases.
|
|
|
|
//
|
2015-09-06 13:26:40 -04:00
|
|
|
func onbuild(b *Builder, args []string, attributes map[string]bool, original string) error {
|
2015-02-04 12:34:25 -05:00
|
|
|
if len(args) == 0 {
|
Remove static errors from errors package.
Moving all strings to the errors package wasn't a good idea after all.
Our custom implementation of Go errors predates everything that's nice
and good about working with errors in Go. Take as an example what we
have to do to get an error message:
```go
func GetErrorMessage(err error) string {
switch err.(type) {
case errcode.Error:
e, _ := err.(errcode.Error)
return e.Message
case errcode.ErrorCode:
ec, _ := err.(errcode.ErrorCode)
return ec.Message()
default:
return err.Error()
}
}
```
This goes against every good practice for Go development. The language already provides a simple, intuitive and standard way to get error messages, that is calling the `Error()` method from an error. Reinventing the error interface is a mistake.
Our custom implementation also makes very hard to reason about errors, another nice thing about Go. I found several (>10) error declarations that we don't use anywhere. This is a clear sign about how little we know about the errors we return. I also found several error usages where the number of arguments was different than the parameters declared in the error, another clear example of how difficult is to reason about errors.
Moreover, our custom implementation didn't really make easier for people to return custom HTTP status code depending on the errors. Again, it's hard to reason about when to set custom codes and how. Take an example what we have to do to extract the message and status code from an error before returning a response from the API:
```go
switch err.(type) {
case errcode.ErrorCode:
daError, _ := err.(errcode.ErrorCode)
statusCode = daError.Descriptor().HTTPStatusCode
errMsg = daError.Message()
case errcode.Error:
// For reference, if you're looking for a particular error
// then you can do something like :
// import ( derr "github.com/docker/docker/errors" )
// if daError.ErrorCode() == derr.ErrorCodeNoSuchContainer { ... }
daError, _ := err.(errcode.Error)
statusCode = daError.ErrorCode().Descriptor().HTTPStatusCode
errMsg = daError.Message
default:
// This part of will be removed once we've
// converted everything over to use the errcode package
// FIXME: this is brittle and should not be necessary.
// If we need to differentiate between different possible error types,
// we should create appropriate error types with clearly defined meaning
errStr := strings.ToLower(err.Error())
for keyword, status := range map[string]int{
"not found": http.StatusNotFound,
"no such": http.StatusNotFound,
"bad parameter": http.StatusBadRequest,
"conflict": http.StatusConflict,
"impossible": http.StatusNotAcceptable,
"wrong login/password": http.StatusUnauthorized,
"hasn't been activated": http.StatusForbidden,
} {
if strings.Contains(errStr, keyword) {
statusCode = status
break
}
}
}
```
You can notice two things in that code:
1. We have to explain how errors work, because our implementation goes against how easy to use Go errors are.
2. At no moment we arrived to remove that `switch` statement that was the original reason to use our custom implementation.
This change removes all our status errors from the errors package and puts them back in their specific contexts.
IT puts the messages back with their contexts. That way, we know right away when errors used and how to generate their messages.
It uses custom interfaces to reason about errors. Errors that need to response with a custom status code MUST implementent this simple interface:
```go
type errorWithStatus interface {
HTTPErrorStatusCode() int
}
```
This interface is very straightforward to implement. It also preserves Go errors real behavior, getting the message is as simple as using the `Error()` method.
I included helper functions to generate errors that use custom status code in `errors/errors.go`.
By doing this, we remove the hard dependency we have eeverywhere to our custom errors package. Yes, you can use it as a helper to generate error, but it's still very easy to generate errors without it.
Please, read this fantastic blog post about errors in Go: http://dave.cheney.net/2014/12/24/inspecting-errors
Signed-off-by: David Calavera <david.calavera@gmail.com>
2016-02-25 10:53:35 -05:00
|
|
|
return errAtLeastOneArgument("ONBUILD")
|
2015-02-04 12:34:25 -05:00
|
|
|
}
|
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
if err := b.flags.Parse(); err != nil {
|
2015-05-05 17:27:42 -04:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2014-08-05 18:41:09 -04:00
|
|
|
triggerInstruction := strings.ToUpper(strings.TrimSpace(args[0]))
|
|
|
|
switch triggerInstruction {
|
|
|
|
case "ONBUILD":
|
Remove static errors from errors package.
Moving all strings to the errors package wasn't a good idea after all.
Our custom implementation of Go errors predates everything that's nice
and good about working with errors in Go. Take as an example what we
have to do to get an error message:
```go
func GetErrorMessage(err error) string {
switch err.(type) {
case errcode.Error:
e, _ := err.(errcode.Error)
return e.Message
case errcode.ErrorCode:
ec, _ := err.(errcode.ErrorCode)
return ec.Message()
default:
return err.Error()
}
}
```
This goes against every good practice for Go development. The language already provides a simple, intuitive and standard way to get error messages, that is calling the `Error()` method from an error. Reinventing the error interface is a mistake.
Our custom implementation also makes very hard to reason about errors, another nice thing about Go. I found several (>10) error declarations that we don't use anywhere. This is a clear sign about how little we know about the errors we return. I also found several error usages where the number of arguments was different than the parameters declared in the error, another clear example of how difficult is to reason about errors.
Moreover, our custom implementation didn't really make easier for people to return custom HTTP status code depending on the errors. Again, it's hard to reason about when to set custom codes and how. Take an example what we have to do to extract the message and status code from an error before returning a response from the API:
```go
switch err.(type) {
case errcode.ErrorCode:
daError, _ := err.(errcode.ErrorCode)
statusCode = daError.Descriptor().HTTPStatusCode
errMsg = daError.Message()
case errcode.Error:
// For reference, if you're looking for a particular error
// then you can do something like :
// import ( derr "github.com/docker/docker/errors" )
// if daError.ErrorCode() == derr.ErrorCodeNoSuchContainer { ... }
daError, _ := err.(errcode.Error)
statusCode = daError.ErrorCode().Descriptor().HTTPStatusCode
errMsg = daError.Message
default:
// This part of will be removed once we've
// converted everything over to use the errcode package
// FIXME: this is brittle and should not be necessary.
// If we need to differentiate between different possible error types,
// we should create appropriate error types with clearly defined meaning
errStr := strings.ToLower(err.Error())
for keyword, status := range map[string]int{
"not found": http.StatusNotFound,
"no such": http.StatusNotFound,
"bad parameter": http.StatusBadRequest,
"conflict": http.StatusConflict,
"impossible": http.StatusNotAcceptable,
"wrong login/password": http.StatusUnauthorized,
"hasn't been activated": http.StatusForbidden,
} {
if strings.Contains(errStr, keyword) {
statusCode = status
break
}
}
}
```
You can notice two things in that code:
1. We have to explain how errors work, because our implementation goes against how easy to use Go errors are.
2. At no moment we arrived to remove that `switch` statement that was the original reason to use our custom implementation.
This change removes all our status errors from the errors package and puts them back in their specific contexts.
IT puts the messages back with their contexts. That way, we know right away when errors used and how to generate their messages.
It uses custom interfaces to reason about errors. Errors that need to response with a custom status code MUST implementent this simple interface:
```go
type errorWithStatus interface {
HTTPErrorStatusCode() int
}
```
This interface is very straightforward to implement. It also preserves Go errors real behavior, getting the message is as simple as using the `Error()` method.
I included helper functions to generate errors that use custom status code in `errors/errors.go`.
By doing this, we remove the hard dependency we have eeverywhere to our custom errors package. Yes, you can use it as a helper to generate error, but it's still very easy to generate errors without it.
Please, read this fantastic blog post about errors in Go: http://dave.cheney.net/2014/12/24/inspecting-errors
Signed-off-by: David Calavera <david.calavera@gmail.com>
2016-02-25 10:53:35 -05:00
|
|
|
return fmt.Errorf("Chaining ONBUILD via `ONBUILD ONBUILD` isn't allowed")
|
2014-08-05 18:41:09 -04:00
|
|
|
case "MAINTAINER", "FROM":
|
Remove static errors from errors package.
Moving all strings to the errors package wasn't a good idea after all.
Our custom implementation of Go errors predates everything that's nice
and good about working with errors in Go. Take as an example what we
have to do to get an error message:
```go
func GetErrorMessage(err error) string {
switch err.(type) {
case errcode.Error:
e, _ := err.(errcode.Error)
return e.Message
case errcode.ErrorCode:
ec, _ := err.(errcode.ErrorCode)
return ec.Message()
default:
return err.Error()
}
}
```
This goes against every good practice for Go development. The language already provides a simple, intuitive and standard way to get error messages, that is calling the `Error()` method from an error. Reinventing the error interface is a mistake.
Our custom implementation also makes very hard to reason about errors, another nice thing about Go. I found several (>10) error declarations that we don't use anywhere. This is a clear sign about how little we know about the errors we return. I also found several error usages where the number of arguments was different than the parameters declared in the error, another clear example of how difficult is to reason about errors.
Moreover, our custom implementation didn't really make easier for people to return custom HTTP status code depending on the errors. Again, it's hard to reason about when to set custom codes and how. Take an example what we have to do to extract the message and status code from an error before returning a response from the API:
```go
switch err.(type) {
case errcode.ErrorCode:
daError, _ := err.(errcode.ErrorCode)
statusCode = daError.Descriptor().HTTPStatusCode
errMsg = daError.Message()
case errcode.Error:
// For reference, if you're looking for a particular error
// then you can do something like :
// import ( derr "github.com/docker/docker/errors" )
// if daError.ErrorCode() == derr.ErrorCodeNoSuchContainer { ... }
daError, _ := err.(errcode.Error)
statusCode = daError.ErrorCode().Descriptor().HTTPStatusCode
errMsg = daError.Message
default:
// This part of will be removed once we've
// converted everything over to use the errcode package
// FIXME: this is brittle and should not be necessary.
// If we need to differentiate between different possible error types,
// we should create appropriate error types with clearly defined meaning
errStr := strings.ToLower(err.Error())
for keyword, status := range map[string]int{
"not found": http.StatusNotFound,
"no such": http.StatusNotFound,
"bad parameter": http.StatusBadRequest,
"conflict": http.StatusConflict,
"impossible": http.StatusNotAcceptable,
"wrong login/password": http.StatusUnauthorized,
"hasn't been activated": http.StatusForbidden,
} {
if strings.Contains(errStr, keyword) {
statusCode = status
break
}
}
}
```
You can notice two things in that code:
1. We have to explain how errors work, because our implementation goes against how easy to use Go errors are.
2. At no moment we arrived to remove that `switch` statement that was the original reason to use our custom implementation.
This change removes all our status errors from the errors package and puts them back in their specific contexts.
IT puts the messages back with their contexts. That way, we know right away when errors used and how to generate their messages.
It uses custom interfaces to reason about errors. Errors that need to response with a custom status code MUST implementent this simple interface:
```go
type errorWithStatus interface {
HTTPErrorStatusCode() int
}
```
This interface is very straightforward to implement. It also preserves Go errors real behavior, getting the message is as simple as using the `Error()` method.
I included helper functions to generate errors that use custom status code in `errors/errors.go`.
By doing this, we remove the hard dependency we have eeverywhere to our custom errors package. Yes, you can use it as a helper to generate error, but it's still very easy to generate errors without it.
Please, read this fantastic blog post about errors in Go: http://dave.cheney.net/2014/12/24/inspecting-errors
Signed-off-by: David Calavera <david.calavera@gmail.com>
2016-02-25 10:53:35 -05:00
|
|
|
return fmt.Errorf("%s isn't allowed as an ONBUILD trigger", triggerInstruction)
|
2014-08-05 18:41:09 -04:00
|
|
|
}
|
|
|
|
|
2014-10-21 15:26:20 -04:00
|
|
|
original = regexp.MustCompile(`(?i)^\s*ONBUILD\s*`).ReplaceAllString(original, "")
|
2014-08-05 18:41:09 -04:00
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
b.runConfig.OnBuild = append(b.runConfig.OnBuild, original)
|
|
|
|
return b.commit("", b.runConfig.Cmd, fmt.Sprintf("ONBUILD %s", original))
|
2014-08-05 18:41:09 -04:00
|
|
|
}
|
|
|
|
|
2014-08-07 01:56:44 -04:00
|
|
|
// WORKDIR /tmp
|
|
|
|
//
|
|
|
|
// Set the working directory for future RUN/CMD/etc statements.
|
|
|
|
//
|
2015-09-06 13:26:40 -04:00
|
|
|
func workdir(b *Builder, args []string, attributes map[string]bool, original string) error {
|
2014-08-05 18:41:09 -04:00
|
|
|
if len(args) != 1 {
|
Remove static errors from errors package.
Moving all strings to the errors package wasn't a good idea after all.
Our custom implementation of Go errors predates everything that's nice
and good about working with errors in Go. Take as an example what we
have to do to get an error message:
```go
func GetErrorMessage(err error) string {
switch err.(type) {
case errcode.Error:
e, _ := err.(errcode.Error)
return e.Message
case errcode.ErrorCode:
ec, _ := err.(errcode.ErrorCode)
return ec.Message()
default:
return err.Error()
}
}
```
This goes against every good practice for Go development. The language already provides a simple, intuitive and standard way to get error messages, that is calling the `Error()` method from an error. Reinventing the error interface is a mistake.
Our custom implementation also makes very hard to reason about errors, another nice thing about Go. I found several (>10) error declarations that we don't use anywhere. This is a clear sign about how little we know about the errors we return. I also found several error usages where the number of arguments was different than the parameters declared in the error, another clear example of how difficult is to reason about errors.
Moreover, our custom implementation didn't really make easier for people to return custom HTTP status code depending on the errors. Again, it's hard to reason about when to set custom codes and how. Take an example what we have to do to extract the message and status code from an error before returning a response from the API:
```go
switch err.(type) {
case errcode.ErrorCode:
daError, _ := err.(errcode.ErrorCode)
statusCode = daError.Descriptor().HTTPStatusCode
errMsg = daError.Message()
case errcode.Error:
// For reference, if you're looking for a particular error
// then you can do something like :
// import ( derr "github.com/docker/docker/errors" )
// if daError.ErrorCode() == derr.ErrorCodeNoSuchContainer { ... }
daError, _ := err.(errcode.Error)
statusCode = daError.ErrorCode().Descriptor().HTTPStatusCode
errMsg = daError.Message
default:
// This part of will be removed once we've
// converted everything over to use the errcode package
// FIXME: this is brittle and should not be necessary.
// If we need to differentiate between different possible error types,
// we should create appropriate error types with clearly defined meaning
errStr := strings.ToLower(err.Error())
for keyword, status := range map[string]int{
"not found": http.StatusNotFound,
"no such": http.StatusNotFound,
"bad parameter": http.StatusBadRequest,
"conflict": http.StatusConflict,
"impossible": http.StatusNotAcceptable,
"wrong login/password": http.StatusUnauthorized,
"hasn't been activated": http.StatusForbidden,
} {
if strings.Contains(errStr, keyword) {
statusCode = status
break
}
}
}
```
You can notice two things in that code:
1. We have to explain how errors work, because our implementation goes against how easy to use Go errors are.
2. At no moment we arrived to remove that `switch` statement that was the original reason to use our custom implementation.
This change removes all our status errors from the errors package and puts them back in their specific contexts.
IT puts the messages back with their contexts. That way, we know right away when errors used and how to generate their messages.
It uses custom interfaces to reason about errors. Errors that need to response with a custom status code MUST implementent this simple interface:
```go
type errorWithStatus interface {
HTTPErrorStatusCode() int
}
```
This interface is very straightforward to implement. It also preserves Go errors real behavior, getting the message is as simple as using the `Error()` method.
I included helper functions to generate errors that use custom status code in `errors/errors.go`.
By doing this, we remove the hard dependency we have eeverywhere to our custom errors package. Yes, you can use it as a helper to generate error, but it's still very easy to generate errors without it.
Please, read this fantastic blog post about errors in Go: http://dave.cheney.net/2014/12/24/inspecting-errors
Signed-off-by: David Calavera <david.calavera@gmail.com>
2016-02-25 10:53:35 -05:00
|
|
|
return errExactlyOneArgument("WORKDIR")
|
2014-08-05 18:41:09 -04:00
|
|
|
}
|
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
if err := b.flags.Parse(); err != nil {
|
2015-05-05 17:27:42 -04:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2015-08-26 19:39:16 -04:00
|
|
|
// This is from the Dockerfile and will not necessarily be in platform
|
|
|
|
// specific semantics, hence ensure it is converted.
|
|
|
|
workdir := filepath.FromSlash(args[0])
|
2015-06-01 19:42:27 -04:00
|
|
|
|
2015-08-26 19:39:16 -04:00
|
|
|
if !system.IsAbs(workdir) {
|
2015-09-06 13:26:40 -04:00
|
|
|
current := filepath.FromSlash(b.runConfig.WorkingDir)
|
2015-08-26 19:39:16 -04:00
|
|
|
workdir = filepath.Join(string(os.PathSeparator), current, workdir)
|
2014-08-05 18:41:09 -04:00
|
|
|
}
|
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
b.runConfig.WorkingDir = workdir
|
2014-12-12 13:32:11 -05:00
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
return b.commit("", b.runConfig.Cmd, fmt.Sprintf("WORKDIR %v", workdir))
|
2014-08-05 18:41:09 -04:00
|
|
|
}
|
|
|
|
|
2014-08-07 01:56:44 -04:00
|
|
|
// RUN some command yo
|
|
|
|
//
|
|
|
|
// run a command and commit the image. Args are automatically prepended with
|
2015-05-05 11:39:37 -04:00
|
|
|
// 'sh -c' under linux or 'cmd /S /C' under Windows, in the event there is
|
|
|
|
// only one argument. The difference in processing:
|
2014-08-07 01:56:44 -04:00
|
|
|
//
|
2015-05-05 11:39:37 -04:00
|
|
|
// RUN echo hi # sh -c echo hi (Linux)
|
|
|
|
// RUN echo hi # cmd /S /C echo hi (Windows)
|
2014-08-07 01:56:44 -04:00
|
|
|
// RUN [ "echo", "hi" ] # echo hi
|
|
|
|
//
|
2015-09-06 13:26:40 -04:00
|
|
|
func run(b *Builder, args []string, attributes map[string]bool, original string) error {
|
2014-10-28 17:06:23 -04:00
|
|
|
if b.image == "" && !b.noBaseImage {
|
Remove static errors from errors package.
Moving all strings to the errors package wasn't a good idea after all.
Our custom implementation of Go errors predates everything that's nice
and good about working with errors in Go. Take as an example what we
have to do to get an error message:
```go
func GetErrorMessage(err error) string {
switch err.(type) {
case errcode.Error:
e, _ := err.(errcode.Error)
return e.Message
case errcode.ErrorCode:
ec, _ := err.(errcode.ErrorCode)
return ec.Message()
default:
return err.Error()
}
}
```
This goes against every good practice for Go development. The language already provides a simple, intuitive and standard way to get error messages, that is calling the `Error()` method from an error. Reinventing the error interface is a mistake.
Our custom implementation also makes very hard to reason about errors, another nice thing about Go. I found several (>10) error declarations that we don't use anywhere. This is a clear sign about how little we know about the errors we return. I also found several error usages where the number of arguments was different than the parameters declared in the error, another clear example of how difficult is to reason about errors.
Moreover, our custom implementation didn't really make easier for people to return custom HTTP status code depending on the errors. Again, it's hard to reason about when to set custom codes and how. Take an example what we have to do to extract the message and status code from an error before returning a response from the API:
```go
switch err.(type) {
case errcode.ErrorCode:
daError, _ := err.(errcode.ErrorCode)
statusCode = daError.Descriptor().HTTPStatusCode
errMsg = daError.Message()
case errcode.Error:
// For reference, if you're looking for a particular error
// then you can do something like :
// import ( derr "github.com/docker/docker/errors" )
// if daError.ErrorCode() == derr.ErrorCodeNoSuchContainer { ... }
daError, _ := err.(errcode.Error)
statusCode = daError.ErrorCode().Descriptor().HTTPStatusCode
errMsg = daError.Message
default:
// This part of will be removed once we've
// converted everything over to use the errcode package
// FIXME: this is brittle and should not be necessary.
// If we need to differentiate between different possible error types,
// we should create appropriate error types with clearly defined meaning
errStr := strings.ToLower(err.Error())
for keyword, status := range map[string]int{
"not found": http.StatusNotFound,
"no such": http.StatusNotFound,
"bad parameter": http.StatusBadRequest,
"conflict": http.StatusConflict,
"impossible": http.StatusNotAcceptable,
"wrong login/password": http.StatusUnauthorized,
"hasn't been activated": http.StatusForbidden,
} {
if strings.Contains(errStr, keyword) {
statusCode = status
break
}
}
}
```
You can notice two things in that code:
1. We have to explain how errors work, because our implementation goes against how easy to use Go errors are.
2. At no moment we arrived to remove that `switch` statement that was the original reason to use our custom implementation.
This change removes all our status errors from the errors package and puts them back in their specific contexts.
IT puts the messages back with their contexts. That way, we know right away when errors used and how to generate their messages.
It uses custom interfaces to reason about errors. Errors that need to response with a custom status code MUST implementent this simple interface:
```go
type errorWithStatus interface {
HTTPErrorStatusCode() int
}
```
This interface is very straightforward to implement. It also preserves Go errors real behavior, getting the message is as simple as using the `Error()` method.
I included helper functions to generate errors that use custom status code in `errors/errors.go`.
By doing this, we remove the hard dependency we have eeverywhere to our custom errors package. Yes, you can use it as a helper to generate error, but it's still very easy to generate errors without it.
Please, read this fantastic blog post about errors in Go: http://dave.cheney.net/2014/12/24/inspecting-errors
Signed-off-by: David Calavera <david.calavera@gmail.com>
2016-02-25 10:53:35 -05:00
|
|
|
return fmt.Errorf("Please provide a source image with `from` prior to run")
|
2014-09-11 08:58:50 -04:00
|
|
|
}
|
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
if err := b.flags.Parse(); err != nil {
|
2015-05-05 17:27:42 -04:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2015-07-22 01:29:03 -04:00
|
|
|
args = handleJSONArgs(args, attributes)
|
2014-08-05 18:41:09 -04:00
|
|
|
|
2015-03-09 17:44:14 -04:00
|
|
|
if !attributes["json"] {
|
2015-05-05 11:39:37 -04:00
|
|
|
if runtime.GOOS != "windows" {
|
|
|
|
args = append([]string{"/bin/sh", "-c"}, args...)
|
|
|
|
} else {
|
2015-09-25 13:34:07 -04:00
|
|
|
args = append([]string{"cmd", "/S", "/C"}, args...)
|
2015-05-05 11:39:37 -04:00
|
|
|
}
|
2014-08-30 07:34:09 -04:00
|
|
|
}
|
|
|
|
|
2015-12-27 19:58:51 -05:00
|
|
|
config := &container.Config{
|
2016-02-29 06:28:37 -05:00
|
|
|
Cmd: strslice.StrSlice(args),
|
2015-12-27 19:58:51 -05:00
|
|
|
Image: b.image,
|
2014-08-05 18:41:09 -04:00
|
|
|
}
|
|
|
|
|
2014-11-14 13:59:14 -05:00
|
|
|
// stash the cmd
|
2015-09-06 13:26:40 -04:00
|
|
|
cmd := b.runConfig.Cmd
|
2016-02-29 06:28:37 -05:00
|
|
|
if len(b.runConfig.Entrypoint) == 0 && len(b.runConfig.Cmd) == 0 {
|
2016-01-05 11:48:09 -05:00
|
|
|
b.runConfig.Cmd = config.Cmd
|
|
|
|
}
|
|
|
|
|
2014-11-14 13:59:14 -05:00
|
|
|
// stash the config environment
|
2015-09-06 13:26:40 -04:00
|
|
|
env := b.runConfig.Env
|
2014-08-05 18:41:09 -04:00
|
|
|
|
2016-02-29 06:28:37 -05:00
|
|
|
defer func(cmd strslice.StrSlice) { b.runConfig.Cmd = cmd }(cmd)
|
2015-09-06 13:26:40 -04:00
|
|
|
defer func(env []string) { b.runConfig.Env = env }(env)
|
2014-11-14 13:59:14 -05:00
|
|
|
|
|
|
|
// derive the net build-time environment for this run. We let config
|
|
|
|
// environment override the build time environment.
|
|
|
|
// This means that we take the b.buildArgs list of env vars and remove
|
|
|
|
// any of those variables that are defined as part of the container. In other
|
|
|
|
// words, anything in b.Config.Env. What's left is the list of build-time env
|
|
|
|
// vars that we need to add to each RUN command - note the list could be empty.
|
|
|
|
//
|
|
|
|
// We don't persist the build time environment with container's config
|
|
|
|
// environment, but just sort and prepend it to the command string at time
|
|
|
|
// of commit.
|
|
|
|
// This helps with tracing back the image's actual environment at the time
|
|
|
|
// of RUN, without leaking it to the final image. It also aids cache
|
|
|
|
// lookup for same image built with same build time environment.
|
|
|
|
cmdBuildEnv := []string{}
|
2015-12-21 20:05:55 -05:00
|
|
|
configEnv := runconfigopts.ConvertKVStringsToMap(b.runConfig.Env)
|
2015-12-29 15:49:17 -05:00
|
|
|
for key, val := range b.options.BuildArgs {
|
2014-11-14 13:59:14 -05:00
|
|
|
if !b.isBuildArgAllowed(key) {
|
|
|
|
// skip build-args that are not in allowed list, meaning they have
|
|
|
|
// not been defined by an "ARG" Dockerfile command yet.
|
|
|
|
// This is an error condition but only if there is no "ARG" in the entire
|
|
|
|
// Dockerfile, so we'll generate any necessary errors after we parsed
|
|
|
|
// the entire file (see 'leftoverArgs' processing in evaluator.go )
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
if _, ok := configEnv[key]; !ok {
|
|
|
|
cmdBuildEnv = append(cmdBuildEnv, fmt.Sprintf("%s=%s", key, val))
|
|
|
|
}
|
|
|
|
}
|
2014-08-05 18:41:09 -04:00
|
|
|
|
2014-11-14 13:59:14 -05:00
|
|
|
// derive the command to use for probeCache() and to commit in this container.
|
|
|
|
// Note that we only do this if there are any build-time env vars. Also, we
|
|
|
|
// use the special argument "|#" at the start of the args array. This will
|
|
|
|
// avoid conflicts with any RUN command since commands can not
|
|
|
|
// start with | (vertical bar). The "#" (number of build envs) is there to
|
|
|
|
// help ensure proper cache matches. We don't want a RUN command
|
|
|
|
// that starts with "foo=abc" to be considered part of a build-time env var.
|
|
|
|
saveCmd := config.Cmd
|
|
|
|
if len(cmdBuildEnv) > 0 {
|
|
|
|
sort.Strings(cmdBuildEnv)
|
|
|
|
tmpEnv := append([]string{fmt.Sprintf("|%d", len(cmdBuildEnv))}, cmdBuildEnv...)
|
2016-02-29 06:28:37 -05:00
|
|
|
saveCmd = strslice.StrSlice(append(tmpEnv, saveCmd...))
|
2014-11-14 13:59:14 -05:00
|
|
|
}
|
2014-08-05 18:41:09 -04:00
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
b.runConfig.Cmd = saveCmd
|
2015-09-29 13:51:40 -04:00
|
|
|
hit, err := b.probeCache()
|
2014-08-05 18:41:09 -04:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
if hit {
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2014-11-14 13:59:14 -05:00
|
|
|
// set Cmd manually, this is special case only for Dockerfiles
|
2015-09-06 13:26:40 -04:00
|
|
|
b.runConfig.Cmd = config.Cmd
|
2014-11-14 13:59:14 -05:00
|
|
|
// set build-time environment for 'run'.
|
2015-09-06 13:26:40 -04:00
|
|
|
b.runConfig.Env = append(b.runConfig.Env, cmdBuildEnv...)
|
2015-11-09 14:49:16 -05:00
|
|
|
// set config as already being escaped, this prevents double escaping on windows
|
|
|
|
b.runConfig.ArgsEscaped = true
|
2014-11-14 13:59:14 -05:00
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
logrus.Debugf("[BUILDER] Command to be executed: %v", b.runConfig.Cmd)
|
2014-11-14 13:59:14 -05:00
|
|
|
|
2015-12-10 09:35:53 -05:00
|
|
|
cID, err := b.create()
|
2014-08-05 18:41:09 -04:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2014-08-13 06:07:41 -04:00
|
|
|
|
2015-12-10 09:35:53 -05:00
|
|
|
if err := b.run(cID); err != nil {
|
2014-08-05 18:41:09 -04:00
|
|
|
return err
|
|
|
|
}
|
2014-11-14 13:59:14 -05:00
|
|
|
|
|
|
|
// revert to original config environment and set the command string to
|
|
|
|
// have the build-time env vars in it (if any) so that future cache look-ups
|
|
|
|
// properly match it.
|
2015-09-06 13:26:40 -04:00
|
|
|
b.runConfig.Env = env
|
|
|
|
b.runConfig.Cmd = saveCmd
|
2015-12-10 09:35:53 -05:00
|
|
|
return b.commit(cID, cmd, "run")
|
2014-08-05 18:41:09 -04:00
|
|
|
}
|
|
|
|
|
2014-08-07 01:56:44 -04:00
|
|
|
// CMD foo
|
|
|
|
//
|
|
|
|
// Set the default command to run in the container (which may be empty).
|
|
|
|
// Argument handling is the same as RUN.
|
|
|
|
//
|
2015-09-06 13:26:40 -04:00
|
|
|
func cmd(b *Builder, args []string, attributes map[string]bool, original string) error {
|
|
|
|
if err := b.flags.Parse(); err != nil {
|
2015-05-05 17:27:42 -04:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2015-07-22 01:29:03 -04:00
|
|
|
cmdSlice := handleJSONArgs(args, attributes)
|
2014-08-05 18:41:09 -04:00
|
|
|
|
2014-10-27 17:15:28 -04:00
|
|
|
if !attributes["json"] {
|
2015-05-05 11:39:37 -04:00
|
|
|
if runtime.GOOS != "windows" {
|
|
|
|
cmdSlice = append([]string{"/bin/sh", "-c"}, cmdSlice...)
|
|
|
|
} else {
|
2015-09-25 13:34:07 -04:00
|
|
|
cmdSlice = append([]string{"cmd", "/S", "/C"}, cmdSlice...)
|
2015-05-05 11:39:37 -04:00
|
|
|
}
|
2014-08-30 07:34:09 -04:00
|
|
|
}
|
|
|
|
|
2016-02-29 06:28:37 -05:00
|
|
|
b.runConfig.Cmd = strslice.StrSlice(cmdSlice)
|
2015-04-10 20:05:21 -04:00
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
if err := b.commit("", b.runConfig.Cmd, fmt.Sprintf("CMD %q", cmdSlice)); err != nil {
|
2014-08-05 18:41:09 -04:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2014-08-30 07:34:09 -04:00
|
|
|
if len(args) != 0 {
|
|
|
|
b.cmdSet = true
|
|
|
|
}
|
|
|
|
|
2014-08-05 18:41:09 -04:00
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2014-08-07 01:56:44 -04:00
|
|
|
// ENTRYPOINT /usr/sbin/nginx
|
|
|
|
//
|
2015-05-05 11:39:37 -04:00
|
|
|
// Set the entrypoint (which defaults to sh -c on linux, or cmd /S /C on Windows) to
|
|
|
|
// /usr/sbin/nginx. Will accept the CMD as the arguments to /usr/sbin/nginx.
|
2014-08-07 01:56:44 -04:00
|
|
|
//
|
2015-09-06 13:26:40 -04:00
|
|
|
// Handles command processing similar to CMD and RUN, only b.runConfig.Entrypoint
|
2014-08-07 01:56:44 -04:00
|
|
|
// is initialized at NewBuilder time instead of through argument parsing.
|
|
|
|
//
|
2015-09-06 13:26:40 -04:00
|
|
|
func entrypoint(b *Builder, args []string, attributes map[string]bool, original string) error {
|
|
|
|
if err := b.flags.Parse(); err != nil {
|
2015-05-05 17:27:42 -04:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2015-07-22 01:29:03 -04:00
|
|
|
parsed := handleJSONArgs(args, attributes)
|
2014-10-07 18:39:50 -04:00
|
|
|
|
|
|
|
switch {
|
|
|
|
case attributes["json"]:
|
|
|
|
// ENTRYPOINT ["echo", "hi"]
|
2016-02-29 06:28:37 -05:00
|
|
|
b.runConfig.Entrypoint = strslice.StrSlice(parsed)
|
2014-10-23 20:23:25 -04:00
|
|
|
case len(parsed) == 0:
|
|
|
|
// ENTRYPOINT []
|
2015-09-06 13:26:40 -04:00
|
|
|
b.runConfig.Entrypoint = nil
|
2014-10-07 18:39:50 -04:00
|
|
|
default:
|
2014-10-23 20:23:25 -04:00
|
|
|
// ENTRYPOINT echo hi
|
2015-05-05 11:39:37 -04:00
|
|
|
if runtime.GOOS != "windows" {
|
2016-02-29 06:28:37 -05:00
|
|
|
b.runConfig.Entrypoint = strslice.StrSlice{"/bin/sh", "-c", parsed[0]}
|
2015-05-05 11:39:37 -04:00
|
|
|
} else {
|
2016-02-29 06:28:37 -05:00
|
|
|
b.runConfig.Entrypoint = strslice.StrSlice{"cmd", "/S", "/C", parsed[0]}
|
2015-05-05 11:39:37 -04:00
|
|
|
}
|
2014-10-07 18:39:50 -04:00
|
|
|
}
|
2014-08-05 18:41:09 -04:00
|
|
|
|
2014-10-07 18:39:50 -04:00
|
|
|
// when setting the entrypoint if a CMD was not explicitly set then
|
|
|
|
// set the command to nil
|
|
|
|
if !b.cmdSet {
|
2015-09-06 13:26:40 -04:00
|
|
|
b.runConfig.Cmd = nil
|
2014-08-05 18:41:09 -04:00
|
|
|
}
|
2014-08-13 06:07:41 -04:00
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
if err := b.commit("", b.runConfig.Cmd, fmt.Sprintf("ENTRYPOINT %q", b.runConfig.Entrypoint)); err != nil {
|
2014-08-05 18:41:09 -04:00
|
|
|
return err
|
|
|
|
}
|
2014-10-07 18:39:50 -04:00
|
|
|
|
2014-08-05 18:41:09 -04:00
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2014-08-07 01:56:44 -04:00
|
|
|
// EXPOSE 6667/tcp 7000/tcp
|
|
|
|
//
|
|
|
|
// Expose ports for links and port mappings. This all ends up in
|
2015-09-06 13:26:40 -04:00
|
|
|
// b.runConfig.ExposedPorts for runconfig.
|
2014-08-07 01:56:44 -04:00
|
|
|
//
|
2015-09-06 13:26:40 -04:00
|
|
|
func expose(b *Builder, args []string, attributes map[string]bool, original string) error {
|
2014-08-05 18:41:09 -04:00
|
|
|
portsTab := args
|
|
|
|
|
2015-02-04 12:34:25 -05:00
|
|
|
if len(args) == 0 {
|
Remove static errors from errors package.
Moving all strings to the errors package wasn't a good idea after all.
Our custom implementation of Go errors predates everything that's nice
and good about working with errors in Go. Take as an example what we
have to do to get an error message:
```go
func GetErrorMessage(err error) string {
switch err.(type) {
case errcode.Error:
e, _ := err.(errcode.Error)
return e.Message
case errcode.ErrorCode:
ec, _ := err.(errcode.ErrorCode)
return ec.Message()
default:
return err.Error()
}
}
```
This goes against every good practice for Go development. The language already provides a simple, intuitive and standard way to get error messages, that is calling the `Error()` method from an error. Reinventing the error interface is a mistake.
Our custom implementation also makes very hard to reason about errors, another nice thing about Go. I found several (>10) error declarations that we don't use anywhere. This is a clear sign about how little we know about the errors we return. I also found several error usages where the number of arguments was different than the parameters declared in the error, another clear example of how difficult is to reason about errors.
Moreover, our custom implementation didn't really make easier for people to return custom HTTP status code depending on the errors. Again, it's hard to reason about when to set custom codes and how. Take an example what we have to do to extract the message and status code from an error before returning a response from the API:
```go
switch err.(type) {
case errcode.ErrorCode:
daError, _ := err.(errcode.ErrorCode)
statusCode = daError.Descriptor().HTTPStatusCode
errMsg = daError.Message()
case errcode.Error:
// For reference, if you're looking for a particular error
// then you can do something like :
// import ( derr "github.com/docker/docker/errors" )
// if daError.ErrorCode() == derr.ErrorCodeNoSuchContainer { ... }
daError, _ := err.(errcode.Error)
statusCode = daError.ErrorCode().Descriptor().HTTPStatusCode
errMsg = daError.Message
default:
// This part of will be removed once we've
// converted everything over to use the errcode package
// FIXME: this is brittle and should not be necessary.
// If we need to differentiate between different possible error types,
// we should create appropriate error types with clearly defined meaning
errStr := strings.ToLower(err.Error())
for keyword, status := range map[string]int{
"not found": http.StatusNotFound,
"no such": http.StatusNotFound,
"bad parameter": http.StatusBadRequest,
"conflict": http.StatusConflict,
"impossible": http.StatusNotAcceptable,
"wrong login/password": http.StatusUnauthorized,
"hasn't been activated": http.StatusForbidden,
} {
if strings.Contains(errStr, keyword) {
statusCode = status
break
}
}
}
```
You can notice two things in that code:
1. We have to explain how errors work, because our implementation goes against how easy to use Go errors are.
2. At no moment we arrived to remove that `switch` statement that was the original reason to use our custom implementation.
This change removes all our status errors from the errors package and puts them back in their specific contexts.
IT puts the messages back with their contexts. That way, we know right away when errors used and how to generate their messages.
It uses custom interfaces to reason about errors. Errors that need to response with a custom status code MUST implementent this simple interface:
```go
type errorWithStatus interface {
HTTPErrorStatusCode() int
}
```
This interface is very straightforward to implement. It also preserves Go errors real behavior, getting the message is as simple as using the `Error()` method.
I included helper functions to generate errors that use custom status code in `errors/errors.go`.
By doing this, we remove the hard dependency we have eeverywhere to our custom errors package. Yes, you can use it as a helper to generate error, but it's still very easy to generate errors without it.
Please, read this fantastic blog post about errors in Go: http://dave.cheney.net/2014/12/24/inspecting-errors
Signed-off-by: David Calavera <david.calavera@gmail.com>
2016-02-25 10:53:35 -05:00
|
|
|
return errAtLeastOneArgument("EXPOSE")
|
2015-02-04 12:34:25 -05:00
|
|
|
}
|
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
if err := b.flags.Parse(); err != nil {
|
2015-05-05 17:27:42 -04:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
if b.runConfig.ExposedPorts == nil {
|
|
|
|
b.runConfig.ExposedPorts = make(nat.PortSet)
|
2014-08-05 18:41:09 -04:00
|
|
|
}
|
|
|
|
|
2015-05-24 09:17:29 -04:00
|
|
|
ports, _, err := nat.ParsePortSpecs(portsTab)
|
2014-08-05 18:41:09 -04:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2014-11-12 03:22:08 -05:00
|
|
|
// instead of using ports directly, we build a list of ports and sort it so
|
|
|
|
// the order is consistent. This prevents cache burst where map ordering
|
|
|
|
// changes between builds
|
|
|
|
portList := make([]string, len(ports))
|
|
|
|
var i int
|
2014-08-05 18:41:09 -04:00
|
|
|
for port := range ports {
|
2015-09-06 13:26:40 -04:00
|
|
|
if _, exists := b.runConfig.ExposedPorts[port]; !exists {
|
|
|
|
b.runConfig.ExposedPorts[port] = struct{}{}
|
2014-08-05 18:41:09 -04:00
|
|
|
}
|
2014-11-12 03:22:08 -05:00
|
|
|
portList[i] = string(port)
|
|
|
|
i++
|
2014-08-05 18:41:09 -04:00
|
|
|
}
|
2014-11-12 03:22:08 -05:00
|
|
|
sort.Strings(portList)
|
2015-09-06 13:26:40 -04:00
|
|
|
return b.commit("", b.runConfig.Cmd, fmt.Sprintf("EXPOSE %s", strings.Join(portList, " ")))
|
2014-08-05 18:41:09 -04:00
|
|
|
}
|
|
|
|
|
2014-08-07 01:56:44 -04:00
|
|
|
// USER foo
|
|
|
|
//
|
|
|
|
// Set the user to 'foo' for future commands and when running the
|
|
|
|
// ENTRYPOINT/CMD at container run time.
|
|
|
|
//
|
2015-09-06 13:26:40 -04:00
|
|
|
func user(b *Builder, args []string, attributes map[string]bool, original string) error {
|
2014-08-05 18:41:09 -04:00
|
|
|
if len(args) != 1 {
|
Remove static errors from errors package.
Moving all strings to the errors package wasn't a good idea after all.
Our custom implementation of Go errors predates everything that's nice
and good about working with errors in Go. Take as an example what we
have to do to get an error message:
```go
func GetErrorMessage(err error) string {
switch err.(type) {
case errcode.Error:
e, _ := err.(errcode.Error)
return e.Message
case errcode.ErrorCode:
ec, _ := err.(errcode.ErrorCode)
return ec.Message()
default:
return err.Error()
}
}
```
This goes against every good practice for Go development. The language already provides a simple, intuitive and standard way to get error messages, that is calling the `Error()` method from an error. Reinventing the error interface is a mistake.
Our custom implementation also makes very hard to reason about errors, another nice thing about Go. I found several (>10) error declarations that we don't use anywhere. This is a clear sign about how little we know about the errors we return. I also found several error usages where the number of arguments was different than the parameters declared in the error, another clear example of how difficult is to reason about errors.
Moreover, our custom implementation didn't really make easier for people to return custom HTTP status code depending on the errors. Again, it's hard to reason about when to set custom codes and how. Take an example what we have to do to extract the message and status code from an error before returning a response from the API:
```go
switch err.(type) {
case errcode.ErrorCode:
daError, _ := err.(errcode.ErrorCode)
statusCode = daError.Descriptor().HTTPStatusCode
errMsg = daError.Message()
case errcode.Error:
// For reference, if you're looking for a particular error
// then you can do something like :
// import ( derr "github.com/docker/docker/errors" )
// if daError.ErrorCode() == derr.ErrorCodeNoSuchContainer { ... }
daError, _ := err.(errcode.Error)
statusCode = daError.ErrorCode().Descriptor().HTTPStatusCode
errMsg = daError.Message
default:
// This part of will be removed once we've
// converted everything over to use the errcode package
// FIXME: this is brittle and should not be necessary.
// If we need to differentiate between different possible error types,
// we should create appropriate error types with clearly defined meaning
errStr := strings.ToLower(err.Error())
for keyword, status := range map[string]int{
"not found": http.StatusNotFound,
"no such": http.StatusNotFound,
"bad parameter": http.StatusBadRequest,
"conflict": http.StatusConflict,
"impossible": http.StatusNotAcceptable,
"wrong login/password": http.StatusUnauthorized,
"hasn't been activated": http.StatusForbidden,
} {
if strings.Contains(errStr, keyword) {
statusCode = status
break
}
}
}
```
You can notice two things in that code:
1. We have to explain how errors work, because our implementation goes against how easy to use Go errors are.
2. At no moment we arrived to remove that `switch` statement that was the original reason to use our custom implementation.
This change removes all our status errors from the errors package and puts them back in their specific contexts.
IT puts the messages back with their contexts. That way, we know right away when errors used and how to generate their messages.
It uses custom interfaces to reason about errors. Errors that need to response with a custom status code MUST implementent this simple interface:
```go
type errorWithStatus interface {
HTTPErrorStatusCode() int
}
```
This interface is very straightforward to implement. It also preserves Go errors real behavior, getting the message is as simple as using the `Error()` method.
I included helper functions to generate errors that use custom status code in `errors/errors.go`.
By doing this, we remove the hard dependency we have eeverywhere to our custom errors package. Yes, you can use it as a helper to generate error, but it's still very easy to generate errors without it.
Please, read this fantastic blog post about errors in Go: http://dave.cheney.net/2014/12/24/inspecting-errors
Signed-off-by: David Calavera <david.calavera@gmail.com>
2016-02-25 10:53:35 -05:00
|
|
|
return errExactlyOneArgument("USER")
|
2014-08-05 18:41:09 -04:00
|
|
|
}
|
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
if err := b.flags.Parse(); err != nil {
|
2015-05-05 17:27:42 -04:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
b.runConfig.User = args[0]
|
|
|
|
return b.commit("", b.runConfig.Cmd, fmt.Sprintf("USER %v", args))
|
2014-08-05 18:41:09 -04:00
|
|
|
}
|
|
|
|
|
2014-08-07 01:56:44 -04:00
|
|
|
// VOLUME /foo
|
|
|
|
//
|
2014-09-11 09:27:51 -04:00
|
|
|
// Expose the volume /foo for use. Will also accept the JSON array form.
|
2014-08-07 01:56:44 -04:00
|
|
|
//
|
2015-09-06 13:26:40 -04:00
|
|
|
func volume(b *Builder, args []string, attributes map[string]bool, original string) error {
|
2014-09-11 09:27:51 -04:00
|
|
|
if len(args) == 0 {
|
Remove static errors from errors package.
Moving all strings to the errors package wasn't a good idea after all.
Our custom implementation of Go errors predates everything that's nice
and good about working with errors in Go. Take as an example what we
have to do to get an error message:
```go
func GetErrorMessage(err error) string {
switch err.(type) {
case errcode.Error:
e, _ := err.(errcode.Error)
return e.Message
case errcode.ErrorCode:
ec, _ := err.(errcode.ErrorCode)
return ec.Message()
default:
return err.Error()
}
}
```
This goes against every good practice for Go development. The language already provides a simple, intuitive and standard way to get error messages, that is calling the `Error()` method from an error. Reinventing the error interface is a mistake.
Our custom implementation also makes very hard to reason about errors, another nice thing about Go. I found several (>10) error declarations that we don't use anywhere. This is a clear sign about how little we know about the errors we return. I also found several error usages where the number of arguments was different than the parameters declared in the error, another clear example of how difficult is to reason about errors.
Moreover, our custom implementation didn't really make easier for people to return custom HTTP status code depending on the errors. Again, it's hard to reason about when to set custom codes and how. Take an example what we have to do to extract the message and status code from an error before returning a response from the API:
```go
switch err.(type) {
case errcode.ErrorCode:
daError, _ := err.(errcode.ErrorCode)
statusCode = daError.Descriptor().HTTPStatusCode
errMsg = daError.Message()
case errcode.Error:
// For reference, if you're looking for a particular error
// then you can do something like :
// import ( derr "github.com/docker/docker/errors" )
// if daError.ErrorCode() == derr.ErrorCodeNoSuchContainer { ... }
daError, _ := err.(errcode.Error)
statusCode = daError.ErrorCode().Descriptor().HTTPStatusCode
errMsg = daError.Message
default:
// This part of will be removed once we've
// converted everything over to use the errcode package
// FIXME: this is brittle and should not be necessary.
// If we need to differentiate between different possible error types,
// we should create appropriate error types with clearly defined meaning
errStr := strings.ToLower(err.Error())
for keyword, status := range map[string]int{
"not found": http.StatusNotFound,
"no such": http.StatusNotFound,
"bad parameter": http.StatusBadRequest,
"conflict": http.StatusConflict,
"impossible": http.StatusNotAcceptable,
"wrong login/password": http.StatusUnauthorized,
"hasn't been activated": http.StatusForbidden,
} {
if strings.Contains(errStr, keyword) {
statusCode = status
break
}
}
}
```
You can notice two things in that code:
1. We have to explain how errors work, because our implementation goes against how easy to use Go errors are.
2. At no moment we arrived to remove that `switch` statement that was the original reason to use our custom implementation.
This change removes all our status errors from the errors package and puts them back in their specific contexts.
IT puts the messages back with their contexts. That way, we know right away when errors used and how to generate their messages.
It uses custom interfaces to reason about errors. Errors that need to response with a custom status code MUST implementent this simple interface:
```go
type errorWithStatus interface {
HTTPErrorStatusCode() int
}
```
This interface is very straightforward to implement. It also preserves Go errors real behavior, getting the message is as simple as using the `Error()` method.
I included helper functions to generate errors that use custom status code in `errors/errors.go`.
By doing this, we remove the hard dependency we have eeverywhere to our custom errors package. Yes, you can use it as a helper to generate error, but it's still very easy to generate errors without it.
Please, read this fantastic blog post about errors in Go: http://dave.cheney.net/2014/12/24/inspecting-errors
Signed-off-by: David Calavera <david.calavera@gmail.com>
2016-02-25 10:53:35 -05:00
|
|
|
return errAtLeastOneArgument("VOLUME")
|
2014-08-05 18:41:09 -04:00
|
|
|
}
|
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
if err := b.flags.Parse(); err != nil {
|
2015-05-05 17:27:42 -04:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
if b.runConfig.Volumes == nil {
|
|
|
|
b.runConfig.Volumes = map[string]struct{}{}
|
2014-08-05 18:41:09 -04:00
|
|
|
}
|
2014-09-11 09:27:51 -04:00
|
|
|
for _, v := range args {
|
2015-03-21 00:39:49 -04:00
|
|
|
v = strings.TrimSpace(v)
|
|
|
|
if v == "" {
|
Remove static errors from errors package.
Moving all strings to the errors package wasn't a good idea after all.
Our custom implementation of Go errors predates everything that's nice
and good about working with errors in Go. Take as an example what we
have to do to get an error message:
```go
func GetErrorMessage(err error) string {
switch err.(type) {
case errcode.Error:
e, _ := err.(errcode.Error)
return e.Message
case errcode.ErrorCode:
ec, _ := err.(errcode.ErrorCode)
return ec.Message()
default:
return err.Error()
}
}
```
This goes against every good practice for Go development. The language already provides a simple, intuitive and standard way to get error messages, that is calling the `Error()` method from an error. Reinventing the error interface is a mistake.
Our custom implementation also makes very hard to reason about errors, another nice thing about Go. I found several (>10) error declarations that we don't use anywhere. This is a clear sign about how little we know about the errors we return. I also found several error usages where the number of arguments was different than the parameters declared in the error, another clear example of how difficult is to reason about errors.
Moreover, our custom implementation didn't really make easier for people to return custom HTTP status code depending on the errors. Again, it's hard to reason about when to set custom codes and how. Take an example what we have to do to extract the message and status code from an error before returning a response from the API:
```go
switch err.(type) {
case errcode.ErrorCode:
daError, _ := err.(errcode.ErrorCode)
statusCode = daError.Descriptor().HTTPStatusCode
errMsg = daError.Message()
case errcode.Error:
// For reference, if you're looking for a particular error
// then you can do something like :
// import ( derr "github.com/docker/docker/errors" )
// if daError.ErrorCode() == derr.ErrorCodeNoSuchContainer { ... }
daError, _ := err.(errcode.Error)
statusCode = daError.ErrorCode().Descriptor().HTTPStatusCode
errMsg = daError.Message
default:
// This part of will be removed once we've
// converted everything over to use the errcode package
// FIXME: this is brittle and should not be necessary.
// If we need to differentiate between different possible error types,
// we should create appropriate error types with clearly defined meaning
errStr := strings.ToLower(err.Error())
for keyword, status := range map[string]int{
"not found": http.StatusNotFound,
"no such": http.StatusNotFound,
"bad parameter": http.StatusBadRequest,
"conflict": http.StatusConflict,
"impossible": http.StatusNotAcceptable,
"wrong login/password": http.StatusUnauthorized,
"hasn't been activated": http.StatusForbidden,
} {
if strings.Contains(errStr, keyword) {
statusCode = status
break
}
}
}
```
You can notice two things in that code:
1. We have to explain how errors work, because our implementation goes against how easy to use Go errors are.
2. At no moment we arrived to remove that `switch` statement that was the original reason to use our custom implementation.
This change removes all our status errors from the errors package and puts them back in their specific contexts.
IT puts the messages back with their contexts. That way, we know right away when errors used and how to generate their messages.
It uses custom interfaces to reason about errors. Errors that need to response with a custom status code MUST implementent this simple interface:
```go
type errorWithStatus interface {
HTTPErrorStatusCode() int
}
```
This interface is very straightforward to implement. It also preserves Go errors real behavior, getting the message is as simple as using the `Error()` method.
I included helper functions to generate errors that use custom status code in `errors/errors.go`.
By doing this, we remove the hard dependency we have eeverywhere to our custom errors package. Yes, you can use it as a helper to generate error, but it's still very easy to generate errors without it.
Please, read this fantastic blog post about errors in Go: http://dave.cheney.net/2014/12/24/inspecting-errors
Signed-off-by: David Calavera <david.calavera@gmail.com>
2016-02-25 10:53:35 -05:00
|
|
|
return fmt.Errorf("Volume specified can not be an empty string")
|
2015-03-21 00:39:49 -04:00
|
|
|
}
|
2015-09-06 13:26:40 -04:00
|
|
|
b.runConfig.Volumes[v] = struct{}{}
|
2014-08-05 18:41:09 -04:00
|
|
|
}
|
2015-09-06 13:26:40 -04:00
|
|
|
if err := b.commit("", b.runConfig.Cmd, fmt.Sprintf("VOLUME %v", args)); err != nil {
|
2014-08-05 18:41:09 -04:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
2015-08-18 13:30:44 -04:00
|
|
|
|
|
|
|
// STOPSIGNAL signal
|
|
|
|
//
|
|
|
|
// Set the signal that will be used to kill the container.
|
2015-09-06 13:26:40 -04:00
|
|
|
func stopSignal(b *Builder, args []string, attributes map[string]bool, original string) error {
|
2015-08-18 13:30:44 -04:00
|
|
|
if len(args) != 1 {
|
|
|
|
return fmt.Errorf("STOPSIGNAL requires exactly one argument")
|
|
|
|
}
|
|
|
|
|
|
|
|
sig := args[0]
|
|
|
|
_, err := signal.ParseSignal(sig)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
b.runConfig.StopSignal = sig
|
|
|
|
return b.commit("", b.runConfig.Cmd, fmt.Sprintf("STOPSIGNAL %v", args))
|
2015-08-18 13:30:44 -04:00
|
|
|
}
|
2014-11-14 13:59:14 -05:00
|
|
|
|
|
|
|
// ARG name[=value]
|
|
|
|
//
|
|
|
|
// Adds the variable foo to the trusted list of variables that can be passed
|
|
|
|
// to builder using the --build-arg flag for expansion/subsitution or passing to 'run'.
|
|
|
|
// Dockerfile author may optionally set a default value of this variable.
|
2015-09-06 13:26:40 -04:00
|
|
|
func arg(b *Builder, args []string, attributes map[string]bool, original string) error {
|
2014-11-14 13:59:14 -05:00
|
|
|
if len(args) != 1 {
|
|
|
|
return fmt.Errorf("ARG requires exactly one argument definition")
|
|
|
|
}
|
|
|
|
|
|
|
|
var (
|
|
|
|
name string
|
|
|
|
value string
|
|
|
|
hasDefault bool
|
|
|
|
)
|
|
|
|
|
|
|
|
arg := args[0]
|
|
|
|
// 'arg' can just be a name or name-value pair. Note that this is different
|
|
|
|
// from 'env' that handles the split of name and value at the parser level.
|
|
|
|
// The reason for doing it differently for 'arg' is that we support just
|
|
|
|
// defining an arg and not assign it a value (while 'env' always expects a
|
|
|
|
// name-value pair). If possible, it will be good to harmonize the two.
|
|
|
|
if strings.Contains(arg, "=") {
|
|
|
|
parts := strings.SplitN(arg, "=", 2)
|
|
|
|
name = parts[0]
|
|
|
|
value = parts[1]
|
|
|
|
hasDefault = true
|
|
|
|
} else {
|
|
|
|
name = arg
|
|
|
|
hasDefault = false
|
|
|
|
}
|
|
|
|
// add the arg to allowed list of build-time args from this step on.
|
|
|
|
b.allowedBuildArgs[name] = true
|
|
|
|
|
|
|
|
// If there is a default value associated with this arg then add it to the
|
|
|
|
// b.buildArgs if one is not already passed to the builder. The args passed
|
2015-12-13 11:00:39 -05:00
|
|
|
// to builder override the default value of 'arg'.
|
2015-12-29 15:49:17 -05:00
|
|
|
if _, ok := b.options.BuildArgs[name]; !ok && hasDefault {
|
|
|
|
b.options.BuildArgs[name] = value
|
2014-11-14 13:59:14 -05:00
|
|
|
}
|
|
|
|
|
2015-09-06 13:26:40 -04:00
|
|
|
return b.commit("", b.runConfig.Cmd, fmt.Sprintf("ARG %s", arg))
|
2014-11-14 13:59:14 -05:00
|
|
|
}
|
Remove static errors from errors package.
Moving all strings to the errors package wasn't a good idea after all.
Our custom implementation of Go errors predates everything that's nice
and good about working with errors in Go. Take as an example what we
have to do to get an error message:
```go
func GetErrorMessage(err error) string {
switch err.(type) {
case errcode.Error:
e, _ := err.(errcode.Error)
return e.Message
case errcode.ErrorCode:
ec, _ := err.(errcode.ErrorCode)
return ec.Message()
default:
return err.Error()
}
}
```
This goes against every good practice for Go development. The language already provides a simple, intuitive and standard way to get error messages, that is calling the `Error()` method from an error. Reinventing the error interface is a mistake.
Our custom implementation also makes very hard to reason about errors, another nice thing about Go. I found several (>10) error declarations that we don't use anywhere. This is a clear sign about how little we know about the errors we return. I also found several error usages where the number of arguments was different than the parameters declared in the error, another clear example of how difficult is to reason about errors.
Moreover, our custom implementation didn't really make easier for people to return custom HTTP status code depending on the errors. Again, it's hard to reason about when to set custom codes and how. Take an example what we have to do to extract the message and status code from an error before returning a response from the API:
```go
switch err.(type) {
case errcode.ErrorCode:
daError, _ := err.(errcode.ErrorCode)
statusCode = daError.Descriptor().HTTPStatusCode
errMsg = daError.Message()
case errcode.Error:
// For reference, if you're looking for a particular error
// then you can do something like :
// import ( derr "github.com/docker/docker/errors" )
// if daError.ErrorCode() == derr.ErrorCodeNoSuchContainer { ... }
daError, _ := err.(errcode.Error)
statusCode = daError.ErrorCode().Descriptor().HTTPStatusCode
errMsg = daError.Message
default:
// This part of will be removed once we've
// converted everything over to use the errcode package
// FIXME: this is brittle and should not be necessary.
// If we need to differentiate between different possible error types,
// we should create appropriate error types with clearly defined meaning
errStr := strings.ToLower(err.Error())
for keyword, status := range map[string]int{
"not found": http.StatusNotFound,
"no such": http.StatusNotFound,
"bad parameter": http.StatusBadRequest,
"conflict": http.StatusConflict,
"impossible": http.StatusNotAcceptable,
"wrong login/password": http.StatusUnauthorized,
"hasn't been activated": http.StatusForbidden,
} {
if strings.Contains(errStr, keyword) {
statusCode = status
break
}
}
}
```
You can notice two things in that code:
1. We have to explain how errors work, because our implementation goes against how easy to use Go errors are.
2. At no moment we arrived to remove that `switch` statement that was the original reason to use our custom implementation.
This change removes all our status errors from the errors package and puts them back in their specific contexts.
IT puts the messages back with their contexts. That way, we know right away when errors used and how to generate their messages.
It uses custom interfaces to reason about errors. Errors that need to response with a custom status code MUST implementent this simple interface:
```go
type errorWithStatus interface {
HTTPErrorStatusCode() int
}
```
This interface is very straightforward to implement. It also preserves Go errors real behavior, getting the message is as simple as using the `Error()` method.
I included helper functions to generate errors that use custom status code in `errors/errors.go`.
By doing this, we remove the hard dependency we have eeverywhere to our custom errors package. Yes, you can use it as a helper to generate error, but it's still very easy to generate errors without it.
Please, read this fantastic blog post about errors in Go: http://dave.cheney.net/2014/12/24/inspecting-errors
Signed-off-by: David Calavera <david.calavera@gmail.com>
2016-02-25 10:53:35 -05:00
|
|
|
|
|
|
|
func errAtLeastOneArgument(command string) error {
|
|
|
|
return fmt.Errorf("%s requires at least one argument", command)
|
|
|
|
}
|
|
|
|
|
|
|
|
func errExactlyOneArgument(command string) error {
|
|
|
|
return fmt.Errorf("%s requires exactly one argument", command)
|
|
|
|
}
|
|
|
|
|
|
|
|
func errTooManyArguments(command string) error {
|
|
|
|
return fmt.Errorf("Bad input to %s, too many arguments", command)
|
|
|
|
}
|