* Make BINARY mutability explicit
* Default docker build output type is local so use this
Signed-off-by: Christopher Crone <christopher.crone@docker.com>
* Use mounts for RUN commands to avoid creating extra layers
* Use built-in platform support
Signed-off-by: Christopher Crone <christopher.crone@docker.com>
- less dependencies to init backend. (Will need to work more on this to make login command not need an existing subscription ID)
- backend does not get login token at init time. For a long running process (grace server) this would cause issues with token lifetime
- we benefit from the client config (polling options especially) set in aci.go, without duplicating stuff
Initially we stored the context data in the `Metadata` of the context
but in hindsight this data would be better of in the `Endpoints` because
that's what it is used for.
Before:
```json
{
"Name": "aci",
"Metadata": {
"Type": "aci",
"Data": {
"key": "value"
}
},
"Endpoints": {
"docker": {}
}
}
```
After:
```json
{
"Name": "aci",
"Type": "aci",
"Metadata": {},
"Endpoints": {
"aci": {
"key": "value"
},
"docker": {}
}
}
```
With this change the contexts that we create are more in line with the contexts the docker cli creates.
It also makes the code less complicated since we don't need to marsal twice any more. The API is nicer too:
```go
// Get a context:
c, err := store.Get(contextName)
// Get the stored endpoint:
var aciContext store.AciContext
if err := contextStore.GetEndpoint(currentContext, &aciContext); err != nil {
return nil, err
}
```
This approach allows better caching of results (so faster subsequent
lints). It also avoids bind mounts which are slow.
Benchmarks on my machine (2017 MacBook Pro 13"):
* bind mount lint: 2m 38s
* new lint (after docker builder prune): 1m 35s
* old lint (rerun no changes): 2m 38s
* new lint (rerun added println in random Go file): 9s
Signed-off-by: Christopher Crone <christopher.crone@docker.com>
It's possible that users will run commands more than once a second.
Thus, seeding the random number generator with the current time in
seconds could produce results like the same container name in subsequent
commands.
Seeding with the current time in nanoseconds reduces the probability of
this.
Signed-off-by: Christopher Crone <christopher.crone@docker.com>
Djordje Lukic
Guillaume Tardif
Chris Crone
Djordje Lukic