2017-06-26 23:46:34 +02:00
|
|
|
// Copyright 2016-2017, Pulumi Corporation. All rights reserved.
|
Introduce assets
This change introduces the basic concept of assets. It is far from
fully featured, however, it is enough to start adding support for various
storage kinds that require access to I/O-backed data (files, etc).
The challenge is that Coconut is deterministic by design, and so you
cannot simply read a file in an ad-hoc manner and present the bytes to
a resource provider. Instead, we will model "assets" as first class
entities whose data source is described to the system in a more declarative
manner, so that the system and resource providers can manage them.
There are three ways to create an asset at the moment:
1. A constant, in-memory string.
2. A path to a file on the local filesystem.
3. A URI, whose scheme is extensible.
Eventually, we want to support byte blobs, but due to our use of a
"JSON-like" type system, this isn't easily expressible just yet.
The URI scheme is extensible in that file://, http://, and https://
are supported "out of the box", but individual providers are free to
recognize their own schemes and support them. For instance, copying
one S3 object to another will be supported simply by passing a URI
with the s3:// protocol in the usual way.
Many utility functions are yet to be written, but this is a start.
2017-04-17 22:00:26 +02:00
|
|
|
|
|
|
|
package resource
|
|
|
|
|
2017-04-17 22:34:19 +02:00
|
|
|
import (
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
"archive/tar"
|
|
|
|
"archive/zip"
|
2017-04-17 22:34:19 +02:00
|
|
|
"bytes"
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
"compress/gzip"
|
2017-04-17 22:34:19 +02:00
|
|
|
"io"
|
|
|
|
"io/ioutil"
|
|
|
|
"net/http"
|
|
|
|
"net/url"
|
|
|
|
"os"
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
"path/filepath"
|
|
|
|
"sort"
|
|
|
|
"strings"
|
2017-04-17 22:34:19 +02:00
|
|
|
|
2017-04-19 23:46:50 +02:00
|
|
|
"github.com/pkg/errors"
|
|
|
|
|
2017-07-14 21:28:43 +02:00
|
|
|
"github.com/pulumi/lumi/pkg/compiler/types/predef"
|
|
|
|
"github.com/pulumi/lumi/pkg/eval/rt"
|
2017-05-18 20:38:28 +02:00
|
|
|
"github.com/pulumi/lumi/pkg/util/contract"
|
2017-04-17 22:34:19 +02:00
|
|
|
)
|
|
|
|
|
|
|
|
// Asset is a serialized asset reference. It is a union: thus, only one of its fields will be non-nil. Several helper
|
|
|
|
// routines exist as members in order to easily interact with the assets referenced by an instance of this type.
|
Introduce assets
This change introduces the basic concept of assets. It is far from
fully featured, however, it is enough to start adding support for various
storage kinds that require access to I/O-backed data (files, etc).
The challenge is that Coconut is deterministic by design, and so you
cannot simply read a file in an ad-hoc manner and present the bytes to
a resource provider. Instead, we will model "assets" as first class
entities whose data source is described to the system in a more declarative
manner, so that the system and resource providers can manage them.
There are three ways to create an asset at the moment:
1. A constant, in-memory string.
2. A path to a file on the local filesystem.
3. A URI, whose scheme is extensible.
Eventually, we want to support byte blobs, but due to our use of a
"JSON-like" type system, this isn't easily expressible just yet.
The URI scheme is extensible in that file://, http://, and https://
are supported "out of the box", but individual providers are free to
recognize their own schemes and support them. For instance, copying
one S3 object to another will be supported simply by passing a URI
with the s3:// protocol in the usual way.
Many utility functions are yet to be written, but this is a start.
2017-04-17 22:00:26 +02:00
|
|
|
type Asset struct {
|
2017-07-14 21:28:43 +02:00
|
|
|
Text *string `lumi:"text,optional"` // a textual asset.
|
|
|
|
Path *string `lumi:"path,optional"` // a file on the current filesystem.
|
|
|
|
URI *string `lumi:"uri,optional"` // a URI to a reference fetched (file://, http://, https://, or custom).
|
Introduce assets
This change introduces the basic concept of assets. It is far from
fully featured, however, it is enough to start adding support for various
storage kinds that require access to I/O-backed data (files, etc).
The challenge is that Coconut is deterministic by design, and so you
cannot simply read a file in an ad-hoc manner and present the bytes to
a resource provider. Instead, we will model "assets" as first class
entities whose data source is described to the system in a more declarative
manner, so that the system and resource providers can manage them.
There are three ways to create an asset at the moment:
1. A constant, in-memory string.
2. A path to a file on the local filesystem.
3. A URI, whose scheme is extensible.
Eventually, we want to support byte blobs, but due to our use of a
"JSON-like" type system, this isn't easily expressible just yet.
The URI scheme is extensible in that file://, http://, and https://
are supported "out of the box", but individual providers are free to
recognize their own schemes and support them. For instance, copying
one S3 object to another will be supported simply by passing a URI
with the s3:// protocol in the usual way.
Many utility functions are yet to be written, but this is a start.
2017-04-17 22:00:26 +02:00
|
|
|
}
|
|
|
|
|
2017-07-14 21:28:43 +02:00
|
|
|
const (
|
|
|
|
AssetTextProperty = "text" // the dynamic property for an asset's text.
|
|
|
|
AssetPathProperty = "path" // the dynamic property for an asset's path.
|
|
|
|
AssetURIProperty = "uri" // the dynamic property for an asset's URI.
|
|
|
|
)
|
|
|
|
|
2017-05-29 22:08:30 +02:00
|
|
|
func NewTextAsset(text string) Asset { return Asset{Text: &text} }
|
|
|
|
func NewPathAsset(path string) Asset { return Asset{Path: &path} }
|
|
|
|
func NewURIAsset(uri string) Asset { return Asset{URI: &uri} }
|
|
|
|
|
2017-07-14 21:28:43 +02:00
|
|
|
func NewAssetFromObject(obj *rt.Object) Asset {
|
|
|
|
contract.Assert(predef.IsResourceAssetType(obj.Type()))
|
|
|
|
var text string
|
|
|
|
var path string
|
|
|
|
var uri string
|
|
|
|
props := obj.Properties()
|
|
|
|
if prop, has := props.TryGet(AssetTextProperty); has {
|
|
|
|
text = prop.StringValue()
|
|
|
|
}
|
|
|
|
if prop, has := props.TryGet(AssetPathProperty); has {
|
|
|
|
path = prop.StringValue()
|
|
|
|
}
|
|
|
|
if prop, has := props.TryGet(AssetURIProperty); has {
|
|
|
|
uri = prop.StringValue()
|
|
|
|
}
|
|
|
|
return Asset{Text: &text, Path: &path, URI: &uri}
|
|
|
|
}
|
|
|
|
|
Introduce assets
This change introduces the basic concept of assets. It is far from
fully featured, however, it is enough to start adding support for various
storage kinds that require access to I/O-backed data (files, etc).
The challenge is that Coconut is deterministic by design, and so you
cannot simply read a file in an ad-hoc manner and present the bytes to
a resource provider. Instead, we will model "assets" as first class
entities whose data source is described to the system in a more declarative
manner, so that the system and resource providers can manage them.
There are three ways to create an asset at the moment:
1. A constant, in-memory string.
2. A path to a file on the local filesystem.
3. A URI, whose scheme is extensible.
Eventually, we want to support byte blobs, but due to our use of a
"JSON-like" type system, this isn't easily expressible just yet.
The URI scheme is extensible in that file://, http://, and https://
are supported "out of the box", but individual providers are free to
recognize their own schemes and support them. For instance, copying
one S3 object to another will be supported simply by passing a URI
with the s3:// protocol in the usual way.
Many utility functions are yet to be written, but this is a start.
2017-04-17 22:00:26 +02:00
|
|
|
func (a Asset) IsText() bool { return a.Text != nil }
|
|
|
|
func (a Asset) IsPath() bool { return a.Path != nil }
|
|
|
|
func (a Asset) IsURI() bool { return a.URI != nil }
|
|
|
|
|
2017-04-17 22:34:19 +02:00
|
|
|
func (a Asset) GetText() (string, bool) {
|
Introduce assets
This change introduces the basic concept of assets. It is far from
fully featured, however, it is enough to start adding support for various
storage kinds that require access to I/O-backed data (files, etc).
The challenge is that Coconut is deterministic by design, and so you
cannot simply read a file in an ad-hoc manner and present the bytes to
a resource provider. Instead, we will model "assets" as first class
entities whose data source is described to the system in a more declarative
manner, so that the system and resource providers can manage them.
There are three ways to create an asset at the moment:
1. A constant, in-memory string.
2. A path to a file on the local filesystem.
3. A URI, whose scheme is extensible.
Eventually, we want to support byte blobs, but due to our use of a
"JSON-like" type system, this isn't easily expressible just yet.
The URI scheme is extensible in that file://, http://, and https://
are supported "out of the box", but individual providers are free to
recognize their own schemes and support them. For instance, copying
one S3 object to another will be supported simply by passing a URI
with the s3:// protocol in the usual way.
Many utility functions are yet to be written, but this is a start.
2017-04-17 22:00:26 +02:00
|
|
|
if a.IsText() {
|
|
|
|
return *a.Text, true
|
|
|
|
}
|
|
|
|
return "", false
|
|
|
|
}
|
|
|
|
|
2017-04-17 22:34:19 +02:00
|
|
|
func (a Asset) GetPath() (string, bool) {
|
Introduce assets
This change introduces the basic concept of assets. It is far from
fully featured, however, it is enough to start adding support for various
storage kinds that require access to I/O-backed data (files, etc).
The challenge is that Coconut is deterministic by design, and so you
cannot simply read a file in an ad-hoc manner and present the bytes to
a resource provider. Instead, we will model "assets" as first class
entities whose data source is described to the system in a more declarative
manner, so that the system and resource providers can manage them.
There are three ways to create an asset at the moment:
1. A constant, in-memory string.
2. A path to a file on the local filesystem.
3. A URI, whose scheme is extensible.
Eventually, we want to support byte blobs, but due to our use of a
"JSON-like" type system, this isn't easily expressible just yet.
The URI scheme is extensible in that file://, http://, and https://
are supported "out of the box", but individual providers are free to
recognize their own schemes and support them. For instance, copying
one S3 object to another will be supported simply by passing a URI
with the s3:// protocol in the usual way.
Many utility functions are yet to be written, but this is a start.
2017-04-17 22:00:26 +02:00
|
|
|
if a.IsPath() {
|
|
|
|
return *a.Path, true
|
|
|
|
}
|
|
|
|
return "", false
|
|
|
|
}
|
|
|
|
|
2017-04-17 22:34:19 +02:00
|
|
|
func (a Asset) GetURI() (string, bool) {
|
Introduce assets
This change introduces the basic concept of assets. It is far from
fully featured, however, it is enough to start adding support for various
storage kinds that require access to I/O-backed data (files, etc).
The challenge is that Coconut is deterministic by design, and so you
cannot simply read a file in an ad-hoc manner and present the bytes to
a resource provider. Instead, we will model "assets" as first class
entities whose data source is described to the system in a more declarative
manner, so that the system and resource providers can manage them.
There are three ways to create an asset at the moment:
1. A constant, in-memory string.
2. A path to a file on the local filesystem.
3. A URI, whose scheme is extensible.
Eventually, we want to support byte blobs, but due to our use of a
"JSON-like" type system, this isn't easily expressible just yet.
The URI scheme is extensible in that file://, http://, and https://
are supported "out of the box", but individual providers are free to
recognize their own schemes and support them. For instance, copying
one S3 object to another will be supported simply by passing a URI
with the s3:// protocol in the usual way.
Many utility functions are yet to be written, but this is a start.
2017-04-17 22:00:26 +02:00
|
|
|
if a.IsURI() {
|
|
|
|
return *a.URI, true
|
|
|
|
}
|
|
|
|
return "", false
|
|
|
|
}
|
2017-04-17 22:34:19 +02:00
|
|
|
|
2017-04-18 20:02:04 +02:00
|
|
|
// GetURIURL returns the underlying URI as a parsed URL, provided it is one. If there was an error parsing the URI, it
|
|
|
|
// will be returned as a non-nil error object.
|
|
|
|
func (a Asset) GetURIURL() (*url.URL, bool, error) {
|
|
|
|
if uri, isuri := a.GetURI(); isuri {
|
|
|
|
url, err := url.Parse(uri)
|
|
|
|
if err != nil {
|
|
|
|
return nil, true, err
|
|
|
|
}
|
|
|
|
return url, true, nil
|
|
|
|
}
|
|
|
|
return nil, false, nil
|
|
|
|
}
|
|
|
|
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
func (a Asset) Read() (*Blob, error) {
|
|
|
|
if a.IsText() {
|
|
|
|
return a.readText()
|
|
|
|
} else if a.IsPath() {
|
|
|
|
return a.readPath()
|
|
|
|
} else if a.IsURI() {
|
|
|
|
return a.readURI()
|
|
|
|
}
|
|
|
|
contract.Failf("Invalid asset; one of Text, Path, or URI must be non-nil")
|
|
|
|
return nil, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func (a Asset) readText() (*Blob, error) {
|
|
|
|
text, istext := a.GetText()
|
|
|
|
contract.Assertf(istext, "Expected a text-based asset")
|
|
|
|
return NewByteBlob([]byte(text)), nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func (a Asset) readPath() (*Blob, error) {
|
|
|
|
path, ispath := a.GetPath()
|
|
|
|
contract.Assertf(ispath, "Expected a path-based asset")
|
|
|
|
f, err := os.Open(path)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
return NewFileBlob(f)
|
|
|
|
}
|
|
|
|
|
|
|
|
func (a Asset) readURI() (*Blob, error) {
|
|
|
|
url, isurl, err := a.GetURIURL()
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
contract.Assertf(isurl, "Expected a URI-based asset")
|
|
|
|
switch s := url.Scheme; s {
|
|
|
|
case "http", "https":
|
2017-05-14 02:04:35 +02:00
|
|
|
resp, err := http.Get(url.String())
|
|
|
|
if err != nil {
|
2017-04-17 22:34:19 +02:00
|
|
|
return nil, err
|
|
|
|
}
|
2017-05-14 02:04:35 +02:00
|
|
|
return NewReadCloserBlob(resp.Body)
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
case "file":
|
|
|
|
contract.Assert(url.Host == "")
|
|
|
|
contract.Assert(url.User == nil)
|
|
|
|
contract.Assert(url.RawQuery == "")
|
|
|
|
contract.Assert(url.Fragment == "")
|
|
|
|
f, err := os.Open(url.Path)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
2017-04-17 22:34:19 +02:00
|
|
|
}
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
return NewFileBlob(f)
|
|
|
|
default:
|
|
|
|
return nil, errors.Errorf("Unrecognized or unsupported URI scheme: %v", s)
|
2017-04-17 22:34:19 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
// SeekableReadCloser combines Read, Close, and Seek functionality into one interface.
|
|
|
|
type SeekableReadCloser interface {
|
2017-04-17 22:34:19 +02:00
|
|
|
io.Seeker
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
io.ReadCloser
|
2017-04-17 22:34:19 +02:00
|
|
|
}
|
|
|
|
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
// Blob is a blob that implements ReadCloser, Seek, and offers Len functionality.
|
|
|
|
type Blob struct {
|
|
|
|
rd SeekableReadCloser // an underlying reader.
|
|
|
|
sz int64 // the size of the blob.
|
|
|
|
}
|
|
|
|
|
2017-05-22 06:45:28 +02:00
|
|
|
func (blob *Blob) Close() error { return blob.rd.Close() }
|
2017-05-04 18:53:52 +02:00
|
|
|
func (blob *Blob) Read(p []byte) (int, error) { return blob.rd.Read(p) }
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
func (blob *Blob) Reader() SeekableReadCloser { return blob.rd }
|
2017-05-04 18:53:52 +02:00
|
|
|
func (blob *Blob) Seek(offset int64, whence int) (int64, error) { return blob.rd.Seek(offset, whence) }
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
func (blob *Blob) Size() int64 { return blob.sz }
|
|
|
|
|
|
|
|
// NewByteBlob creates a new byte blob.
|
|
|
|
func NewByteBlob(data []byte) *Blob {
|
|
|
|
return &Blob{
|
|
|
|
rd: newBytesReader(data),
|
|
|
|
sz: int64(len(data)),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// NewFileBlob creates a new asset blob whose size is known thanks to stat.
|
|
|
|
func NewFileBlob(f *os.File) (*Blob, error) {
|
2017-05-14 02:04:35 +02:00
|
|
|
stat, err := f.Stat()
|
|
|
|
if err != nil {
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
return nil, err
|
|
|
|
}
|
2017-05-14 02:04:35 +02:00
|
|
|
return &Blob{
|
|
|
|
rd: f,
|
|
|
|
sz: stat.Size(),
|
|
|
|
}, nil
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
// NewReadCloserBlob turn any old ReadCloser into an Blob, usually by making a copy.
|
|
|
|
func NewReadCloserBlob(r io.ReadCloser) (*Blob, error) {
|
|
|
|
if f, isf := r.(*os.File); isf {
|
|
|
|
// If it's a file, we can "fast path" the asset creation without making a copy.
|
|
|
|
return NewFileBlob(f)
|
|
|
|
}
|
|
|
|
// Otherwise, read it all in, and create a blob out of that.
|
Tidy up more lint
This change fixes a few things:
* Most importantly, we need to place a leading "." in the paths
to Gometalinter, otherwise some sub-linters just silently skip
the directory altogether. errcheck is one such linter, which
is a very important one!
* Use an explicit Gometalinter.json file to configure the various
settings. This flips on a few additional linters that aren't
on by default (line line length checking). Sadly, a few that
I'd like to enable take waaaay too much time, so in the future
we may consider a nightly job (this includes code similarity,
unused parameters, unused functions, and others that generally
require global analysis).
* Now that we're running more, however, linting takes a while!
The core Lumi project now takes 26 seconds to lint on my laptop.
That's not terrible, but it's long enough that we don't want to
do the silly "run them twice" thing our Makefiles were previously
doing. Instead, we shall deploy some $$($${PIPESTATUS[1]}-1))-fu
to rely on the fact that grep returns 1 on "zero lines".
* Finally, fix the many issues that this turned up.
I think(?) we are done, except, of course, for needing to drive
down some of the cyclomatic complexity issues (which I'm possibly
going to punt on; see pulumi/lumi#259 for more details).
2017-06-22 21:09:46 +02:00
|
|
|
defer contract.IgnoreClose(r)
|
2017-05-14 02:04:35 +02:00
|
|
|
data, err := ioutil.ReadAll(r)
|
|
|
|
if err != nil {
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
return nil, err
|
|
|
|
}
|
2017-05-14 02:04:35 +02:00
|
|
|
return NewByteBlob(data), nil
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
// bytesReader turns a *bytes.Reader into a SeekableReadCloser by adding an empty Close method.
|
2017-04-17 22:34:19 +02:00
|
|
|
type bytesReader struct {
|
|
|
|
*bytes.Reader
|
|
|
|
}
|
|
|
|
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
func newBytesReader(b []byte) SeekableReadCloser {
|
2017-04-17 22:34:19 +02:00
|
|
|
return bytesReader{
|
|
|
|
Reader: bytes.NewReader(b),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func (b bytesReader) Close() error {
|
|
|
|
return nil // intentionally blank
|
|
|
|
}
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
|
|
|
|
// Archive is a serialized archive reference. It is a union: thus, only one of its fields will be non-nil. Several
|
|
|
|
// helper routines exist as members in order to easily interact with archives of different kinds.
|
|
|
|
type Archive struct {
|
2017-07-14 21:28:43 +02:00
|
|
|
Assets *map[string]Asset `lumi:"assets,optional"` // a collection of other assets.
|
|
|
|
Path *string `lumi:"path,optional"` // a file on the current filesystem.
|
|
|
|
URI *string `lumi:"uri,optional"` // a URI to a remote archive (file://, http://, https://, etc).
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
}
|
|
|
|
|
2017-07-14 21:28:43 +02:00
|
|
|
const (
|
|
|
|
ArchiveAssetsProperty = "assets" // the dynamic property for an archive's assets.
|
|
|
|
ArchivePathProperty = "path" // the dynamic property for an archive's path.
|
|
|
|
ArchiveURIProperty = "uri" // the dynamic property for an archive's URI.
|
|
|
|
)
|
|
|
|
|
|
|
|
func NewAssetArchive(assets map[string]Asset) Archive { return Archive{Assets: &assets} }
|
|
|
|
func NewPathArchive(path string) Archive { return Archive{Path: &path} }
|
|
|
|
func NewURIArchive(uri string) Archive { return Archive{URI: &uri} }
|
|
|
|
|
|
|
|
func NewArchiveFromObject(obj *rt.Object) Archive {
|
|
|
|
contract.Assert(predef.IsResourceArchiveType(obj.Type()))
|
|
|
|
var assets map[string]Asset
|
|
|
|
var path string
|
|
|
|
var uri string
|
|
|
|
props := obj.Properties()
|
|
|
|
if prop, has := props.TryGet(ArchiveAssetsProperty); has {
|
|
|
|
assets = make(map[string]Asset)
|
|
|
|
mapprops := prop.Properties()
|
|
|
|
for _, k := range mapprops.Stable() {
|
|
|
|
assets[string(k)] = NewAssetFromObject(mapprops.Get(k))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if prop, has := props.TryGet(ArchivePathProperty); has {
|
|
|
|
path = prop.StringValue()
|
|
|
|
}
|
|
|
|
if prop, has := props.TryGet(ArchiveURIProperty); has {
|
|
|
|
uri = prop.StringValue()
|
|
|
|
}
|
|
|
|
return Archive{Assets: &assets, Path: &path, URI: &uri}
|
|
|
|
}
|
2017-05-29 22:08:30 +02:00
|
|
|
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
func (a Archive) IsMap() bool { return a.Assets != nil }
|
|
|
|
func (a Archive) IsPath() bool { return a.Path != nil }
|
|
|
|
func (a Archive) IsURI() bool { return a.URI != nil }
|
|
|
|
|
2017-07-14 21:28:43 +02:00
|
|
|
func (a Archive) GetMap() (map[string]Asset, bool) {
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
if a.IsMap() {
|
|
|
|
return *a.Assets, true
|
|
|
|
}
|
|
|
|
return nil, false
|
|
|
|
}
|
|
|
|
|
|
|
|
func (a Archive) GetPath() (string, bool) {
|
|
|
|
if a.IsPath() {
|
|
|
|
return *a.Path, true
|
|
|
|
}
|
|
|
|
return "", false
|
|
|
|
}
|
|
|
|
|
|
|
|
func (a Archive) GetURI() (string, bool) {
|
|
|
|
if a.IsURI() {
|
|
|
|
return *a.URI, true
|
|
|
|
}
|
|
|
|
return "", false
|
|
|
|
}
|
|
|
|
|
|
|
|
// GetURIURL returns the underlying URI as a parsed URL, provided it is one. If there was an error parsing the URI, it
|
|
|
|
// will be returned as a non-nil error object.
|
|
|
|
func (a Archive) GetURIURL() (*url.URL, bool, error) {
|
|
|
|
if uri, isuri := a.GetURI(); isuri {
|
|
|
|
url, err := url.Parse(uri)
|
|
|
|
if err != nil {
|
|
|
|
return nil, true, err
|
|
|
|
}
|
|
|
|
return url, true, nil
|
|
|
|
}
|
|
|
|
return nil, false, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// Read returns a map of asset name to its associated reader object (which can be used to perform reads/IO).
|
|
|
|
func (a Archive) Read() (map[string]*Blob, error) {
|
|
|
|
if a.IsMap() {
|
|
|
|
return a.readMap()
|
|
|
|
} else if a.IsPath() {
|
|
|
|
return a.readPath()
|
|
|
|
} else if a.IsURI() {
|
|
|
|
return a.readURI()
|
|
|
|
}
|
|
|
|
contract.Failf("Invalid archive; one of Assets, Path, or URI must be non-nil")
|
|
|
|
return nil, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func (a Archive) readMap() (map[string]*Blob, error) {
|
|
|
|
// To read a map-based archive, just produce a map from each asset to its associated reader.
|
|
|
|
m, ismap := a.GetMap()
|
|
|
|
contract.Assertf(ismap, "Expected a map-based archive")
|
2017-05-23 07:57:55 +02:00
|
|
|
result := map[string]*Blob{}
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
for name, asset := range m {
|
2017-06-12 19:15:20 +02:00
|
|
|
// TODO[pulumi/lumi#240]: It would be better to treat folders as a first class concept intead
|
|
|
|
// of reusing a path Asset for this purpose.
|
|
|
|
path, isPath := asset.GetPath()
|
|
|
|
if isPath {
|
|
|
|
if fi, err := os.Stat(path); err == nil && fi.IsDir() {
|
|
|
|
// Asset is a folder, expand it
|
2017-06-21 22:24:35 +02:00
|
|
|
if walkerr := filepath.Walk(path, func(filePath string, f os.FileInfo, fileerr error) error {
|
|
|
|
if fileerr != nil || f.IsDir() || f.Mode()&os.ModeSymlink != 0 {
|
|
|
|
return fileerr
|
2017-06-12 19:15:20 +02:00
|
|
|
}
|
2017-06-21 22:24:35 +02:00
|
|
|
|
|
|
|
var err error
|
|
|
|
result[filePath], err = NewPathAsset(filePath).Read()
|
|
|
|
return err
|
|
|
|
}); walkerr != nil {
|
|
|
|
return nil, walkerr
|
2017-06-12 19:15:20 +02:00
|
|
|
}
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
}
|
2017-06-21 22:24:35 +02:00
|
|
|
var err error
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
if result[name], err = asset.Read(); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return result, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func (a Archive) readPath() (map[string]*Blob, error) {
|
|
|
|
// To read a path-based archive, read that file and use its extension to ascertain what format to use.
|
|
|
|
path, ispath := a.GetPath()
|
|
|
|
contract.Assertf(ispath, "Expected a path-based asset")
|
|
|
|
|
|
|
|
format, err := detectArchiveFormat(path)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
file, err := os.Open(path)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
return readArchive(file, format)
|
|
|
|
}
|
|
|
|
|
|
|
|
func (a Archive) readURI() (map[string]*Blob, error) {
|
|
|
|
// To read a URI-based archive, fetch the contents remotely and use the extension to pick the format to use.
|
|
|
|
url, isurl, err := a.GetURIURL()
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
contract.Assertf(isurl, "Expected a URI-based asset")
|
|
|
|
|
|
|
|
format, err := detectArchiveFormat(url.Path)
|
|
|
|
if err != nil {
|
2017-06-06 03:11:51 +02:00
|
|
|
// IDEA: support (a) hints and (b) custom providers that default to certain formats.
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
ar, err := a.openURLStream(url)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
return readArchive(ar, format)
|
|
|
|
}
|
|
|
|
|
|
|
|
func (a Archive) openURLStream(url *url.URL) (io.ReadCloser, error) {
|
|
|
|
switch s := url.Scheme; s {
|
|
|
|
case "http", "https":
|
2017-05-14 02:04:35 +02:00
|
|
|
resp, err := http.Get(url.String())
|
|
|
|
if err != nil {
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
return nil, err
|
|
|
|
}
|
2017-05-14 02:04:35 +02:00
|
|
|
return resp.Body, nil
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
case "file":
|
|
|
|
contract.Assert(url.Host == "")
|
|
|
|
contract.Assert(url.User == nil)
|
|
|
|
contract.Assert(url.RawQuery == "")
|
|
|
|
contract.Assert(url.Fragment == "")
|
|
|
|
return os.Open(url.Path)
|
|
|
|
default:
|
|
|
|
return nil, errors.Errorf("Unrecognized or unsupported URI scheme: %v", s)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-05-01 18:38:23 +02:00
|
|
|
// Bytes fetches the archive contents as a byte slices. This is almost certainly the least efficient way to deal with
|
|
|
|
// the underlying streaming capabilities offered by assets and archives, but can be used in a pinch to interact with
|
|
|
|
// APIs that demand []bytes.
|
2017-06-13 20:01:23 +02:00
|
|
|
func (a Archive) Bytes(format ArchiveFormat) ([]byte, error) {
|
2017-05-01 18:38:23 +02:00
|
|
|
var data bytes.Buffer
|
2017-06-12 19:15:20 +02:00
|
|
|
if err := a.Archive(format, &data); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
return data.Bytes(), nil
|
2017-05-01 18:38:23 +02:00
|
|
|
}
|
|
|
|
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
// Archive produces a single archive stream in the desired format. It prefers to return the archive with as little
|
|
|
|
// copying as is feasible, however if the desired format is different from the source, it will need to translate.
|
|
|
|
func (a Archive) Archive(format ArchiveFormat, w io.Writer) error {
|
|
|
|
// If the source format is the same, just return that.
|
|
|
|
if sf, ss, err := a.ReadSourceArchive(); sf != NotArchive && sf == format {
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
_, err := io.Copy(w, ss)
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
switch format {
|
|
|
|
case TarArchive:
|
|
|
|
return a.archiveTar(w)
|
|
|
|
case TarGZIPArchive:
|
|
|
|
return a.archiveTarGZIP(w)
|
|
|
|
case ZIPArchive:
|
|
|
|
return a.archiveZIP(w)
|
|
|
|
default:
|
|
|
|
contract.Failf("Illegal archive type: %v", format)
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func (a Archive) archiveTar(w io.Writer) error {
|
|
|
|
// Read the archive.
|
|
|
|
arch, err := a.Read()
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
// Sort the file names so we emit in a deterministic order.
|
|
|
|
var files []string
|
|
|
|
for file := range arch {
|
|
|
|
files = append(files, file)
|
|
|
|
}
|
|
|
|
sort.Strings(files)
|
|
|
|
|
|
|
|
// Now actually emit the contents, file by file.
|
|
|
|
tw := tar.NewWriter(w)
|
|
|
|
for _, file := range files {
|
|
|
|
data := arch[file]
|
|
|
|
sz := data.Size()
|
|
|
|
if err := tw.WriteHeader(&tar.Header{
|
|
|
|
Name: file,
|
|
|
|
Mode: 0600,
|
|
|
|
Size: sz,
|
|
|
|
}); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2017-05-14 02:04:35 +02:00
|
|
|
n, err := io.Copy(tw, data)
|
|
|
|
if err != nil {
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
return err
|
|
|
|
}
|
Tidy up more lint
This change fixes a few things:
* Most importantly, we need to place a leading "." in the paths
to Gometalinter, otherwise some sub-linters just silently skip
the directory altogether. errcheck is one such linter, which
is a very important one!
* Use an explicit Gometalinter.json file to configure the various
settings. This flips on a few additional linters that aren't
on by default (line line length checking). Sadly, a few that
I'd like to enable take waaaay too much time, so in the future
we may consider a nightly job (this includes code similarity,
unused parameters, unused functions, and others that generally
require global analysis).
* Now that we're running more, however, linting takes a while!
The core Lumi project now takes 26 seconds to lint on my laptop.
That's not terrible, but it's long enough that we don't want to
do the silly "run them twice" thing our Makefiles were previously
doing. Instead, we shall deploy some $$($${PIPESTATUS[1]}-1))-fu
to rely on the fact that grep returns 1 on "zero lines".
* Finally, fix the many issues that this turned up.
I think(?) we are done, except, of course, for needing to drive
down some of the cyclomatic complexity issues (which I'm possibly
going to punt on; see pulumi/lumi#259 for more details).
2017-06-22 21:09:46 +02:00
|
|
|
contract.Assert(n == sz)
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return tw.Close()
|
|
|
|
}
|
|
|
|
|
|
|
|
func (a Archive) archiveTarGZIP(w io.Writer) error {
|
|
|
|
z := gzip.NewWriter(w)
|
|
|
|
return a.archiveTar(z)
|
|
|
|
}
|
|
|
|
|
|
|
|
func (a Archive) archiveZIP(w io.Writer) error {
|
|
|
|
// Read the archive.
|
|
|
|
arch, err := a.Read()
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
// Sort the file names so we emit in a deterministic order.
|
|
|
|
var files []string
|
|
|
|
for file := range arch {
|
|
|
|
files = append(files, file)
|
|
|
|
}
|
|
|
|
sort.Strings(files)
|
|
|
|
|
|
|
|
// Now actually emit the contents, file by file.
|
|
|
|
zw := zip.NewWriter(w)
|
|
|
|
for _, file := range files {
|
|
|
|
fw, err := zw.Create(file)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
if _, err = io.Copy(fw, arch[file]); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return zw.Close()
|
|
|
|
}
|
|
|
|
|
|
|
|
// ReadSourceArchive returns a stream to the underlying archive, if there eis one.
|
|
|
|
func (a Archive) ReadSourceArchive() (ArchiveFormat, io.ReadCloser, error) {
|
|
|
|
if path, ispath := a.GetPath(); ispath {
|
2017-06-14 01:47:55 +02:00
|
|
|
if format, archerr := detectArchiveFormat(path); archerr != nil && format != NotArchive {
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
f, err := os.Open(path)
|
|
|
|
return format, f, err
|
|
|
|
}
|
2017-06-14 01:47:55 +02:00
|
|
|
} else if url, isurl, urlerr := a.GetURIURL(); urlerr == nil && isurl {
|
|
|
|
if format, archerr := detectArchiveFormat(url.Path); archerr == nil && format != NotArchive {
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
s, err := a.openURLStream(url)
|
|
|
|
return format, s, err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return NotArchive, nil, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// ArchiveFormat indicates what archive and/or compression format an archive uses.
|
|
|
|
type ArchiveFormat int
|
|
|
|
|
|
|
|
const (
|
|
|
|
NotArchive = iota // not an archive.
|
|
|
|
TarArchive // a POSIX tar archive.
|
|
|
|
TarGZIPArchive // a POSIX tar archive that has been subsequently compressed using GZip.
|
|
|
|
ZIPArchive // a multi-file ZIP archive.
|
|
|
|
)
|
|
|
|
|
|
|
|
// ArchiveExts maps from a file extension and its associated archive and/or compression format.
|
|
|
|
var ArchiveExts = map[string]ArchiveFormat{
|
|
|
|
".tar": TarArchive,
|
|
|
|
".tgz": TarGZIPArchive,
|
|
|
|
".tar.gz": TarGZIPArchive,
|
|
|
|
".zip": ZIPArchive,
|
|
|
|
}
|
|
|
|
|
|
|
|
// detectArchiveFormat takes a path and infers its archive format based on the file extension.
|
|
|
|
func detectArchiveFormat(path string) (ArchiveFormat, error) {
|
|
|
|
ext := filepath.Ext(path)
|
|
|
|
if moreext := filepath.Ext(strings.TrimRight(path, ext)); moreext != "" {
|
|
|
|
ext = moreext + ext // this ensures we detect ".tar.gz" correctly.
|
|
|
|
}
|
|
|
|
format, has := ArchiveExts[ext]
|
|
|
|
if !has {
|
|
|
|
return NotArchive, errors.Errorf("unrecognized archive format '%v'", ext)
|
|
|
|
}
|
|
|
|
return format, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// readArchive takes a stream to an existing archive and returns a map of names to readers for the inner assets.
|
|
|
|
// The routine returns an error if something goes wrong and, no matter what, closes the stream before returning.
|
|
|
|
func readArchive(ar io.ReadCloser, format ArchiveFormat) (map[string]*Blob, error) {
|
Tidy up more lint
This change fixes a few things:
* Most importantly, we need to place a leading "." in the paths
to Gometalinter, otherwise some sub-linters just silently skip
the directory altogether. errcheck is one such linter, which
is a very important one!
* Use an explicit Gometalinter.json file to configure the various
settings. This flips on a few additional linters that aren't
on by default (line line length checking). Sadly, a few that
I'd like to enable take waaaay too much time, so in the future
we may consider a nightly job (this includes code similarity,
unused parameters, unused functions, and others that generally
require global analysis).
* Now that we're running more, however, linting takes a while!
The core Lumi project now takes 26 seconds to lint on my laptop.
That's not terrible, but it's long enough that we don't want to
do the silly "run them twice" thing our Makefiles were previously
doing. Instead, we shall deploy some $$($${PIPESTATUS[1]}-1))-fu
to rely on the fact that grep returns 1 on "zero lines".
* Finally, fix the many issues that this turned up.
I think(?) we are done, except, of course, for needing to drive
down some of the cyclomatic complexity issues (which I'm possibly
going to punt on; see pulumi/lumi#259 for more details).
2017-06-22 21:09:46 +02:00
|
|
|
defer contract.IgnoreClose(ar) // consume the input stream
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
|
|
|
|
switch format {
|
|
|
|
case TarArchive:
|
|
|
|
return readTarArchive(ar)
|
|
|
|
case TarGZIPArchive:
|
|
|
|
return readTarGZIPArchive(ar)
|
|
|
|
case ZIPArchive:
|
|
|
|
// Unfortunately, the ZIP archive reader requires ReaderAt functionality. If it's a file, we can recovera this
|
|
|
|
// with a simple stat. Otherwise, we will need to go ahead and make a copy in memory.
|
|
|
|
var ra io.ReaderAt
|
|
|
|
var sz int64
|
|
|
|
if f, isf := ar.(*os.File); isf {
|
2017-05-14 02:04:35 +02:00
|
|
|
stat, err := f.Stat()
|
|
|
|
if err != nil {
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
return nil, err
|
|
|
|
}
|
2017-05-14 02:04:35 +02:00
|
|
|
ra = f
|
|
|
|
sz = stat.Size()
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
} else if data, err := ioutil.ReadAll(ar); err != nil {
|
|
|
|
return nil, err
|
|
|
|
} else {
|
|
|
|
ra = bytes.NewReader(data)
|
|
|
|
sz = int64(len(data))
|
|
|
|
}
|
|
|
|
return readZIPArchive(ra, sz)
|
|
|
|
default:
|
|
|
|
contract.Failf("Illegal archive type: %v", format)
|
|
|
|
return nil, nil
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func readTarArchive(ar io.ReadCloser) (map[string]*Blob, error) {
|
Tidy up more lint
This change fixes a few things:
* Most importantly, we need to place a leading "." in the paths
to Gometalinter, otherwise some sub-linters just silently skip
the directory altogether. errcheck is one such linter, which
is a very important one!
* Use an explicit Gometalinter.json file to configure the various
settings. This flips on a few additional linters that aren't
on by default (line line length checking). Sadly, a few that
I'd like to enable take waaaay too much time, so in the future
we may consider a nightly job (this includes code similarity,
unused parameters, unused functions, and others that generally
require global analysis).
* Now that we're running more, however, linting takes a while!
The core Lumi project now takes 26 seconds to lint on my laptop.
That's not terrible, but it's long enough that we don't want to
do the silly "run them twice" thing our Makefiles were previously
doing. Instead, we shall deploy some $$($${PIPESTATUS[1]}-1))-fu
to rely on the fact that grep returns 1 on "zero lines".
* Finally, fix the many issues that this turned up.
I think(?) we are done, except, of course, for needing to drive
down some of the cyclomatic complexity issues (which I'm possibly
going to punt on; see pulumi/lumi#259 for more details).
2017-06-22 21:09:46 +02:00
|
|
|
defer contract.IgnoreClose(ar) // consume the input stream
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
|
|
|
|
// Create a tar reader and walk through each file, adding each one to the map.
|
|
|
|
assets := make(map[string]*Blob)
|
|
|
|
tr := tar.NewReader(ar)
|
|
|
|
for {
|
|
|
|
file, err := tr.Next()
|
|
|
|
if err == io.EOF {
|
|
|
|
break
|
|
|
|
} else if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
switch file.Typeflag {
|
|
|
|
case tar.TypeDir:
|
|
|
|
continue // skip directories
|
|
|
|
case tar.TypeReg:
|
|
|
|
data := make([]byte, file.Size)
|
2017-05-14 02:04:35 +02:00
|
|
|
n, err := tr.Read(data)
|
|
|
|
if err != nil {
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
return nil, err
|
|
|
|
}
|
2017-05-14 02:04:35 +02:00
|
|
|
contract.Assert(int64(n) == file.Size)
|
|
|
|
assets[file.Name] = NewByteBlob(data)
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
default:
|
|
|
|
contract.Failf("Unrecognized tar header typeflag: %v", file.Typeflag)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return assets, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func readTarGZIPArchive(ar io.ReadCloser) (map[string]*Blob, error) {
|
Tidy up more lint
This change fixes a few things:
* Most importantly, we need to place a leading "." in the paths
to Gometalinter, otherwise some sub-linters just silently skip
the directory altogether. errcheck is one such linter, which
is a very important one!
* Use an explicit Gometalinter.json file to configure the various
settings. This flips on a few additional linters that aren't
on by default (line line length checking). Sadly, a few that
I'd like to enable take waaaay too much time, so in the future
we may consider a nightly job (this includes code similarity,
unused parameters, unused functions, and others that generally
require global analysis).
* Now that we're running more, however, linting takes a while!
The core Lumi project now takes 26 seconds to lint on my laptop.
That's not terrible, but it's long enough that we don't want to
do the silly "run them twice" thing our Makefiles were previously
doing. Instead, we shall deploy some $$($${PIPESTATUS[1]}-1))-fu
to rely on the fact that grep returns 1 on "zero lines".
* Finally, fix the many issues that this turned up.
I think(?) we are done, except, of course, for needing to drive
down some of the cyclomatic complexity issues (which I'm possibly
going to punt on; see pulumi/lumi#259 for more details).
2017-06-22 21:09:46 +02:00
|
|
|
defer contract.IgnoreClose(ar) // consume the input stream
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
|
|
|
|
// First decompress the GZIP stream.
|
|
|
|
gz, err := gzip.NewReader(ar)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
// Now read the tarfile.
|
|
|
|
return readTarArchive(gz)
|
|
|
|
}
|
|
|
|
|
|
|
|
func readZIPArchive(ar io.ReaderAt, size int64) (map[string]*Blob, error) {
|
|
|
|
// Create a ZIP reader and iterate over the files inside of it, adding each one.
|
|
|
|
assets := make(map[string]*Blob)
|
|
|
|
z, err := zip.NewReader(ar, size)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
for _, file := range z.File {
|
|
|
|
body, err := file.Open()
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
size := file.UncompressedSize64
|
|
|
|
data := make([]byte, size)
|
2017-05-14 02:04:35 +02:00
|
|
|
n, err := body.Read(data)
|
|
|
|
if err != nil {
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
return nil, err
|
|
|
|
}
|
2017-05-14 02:04:35 +02:00
|
|
|
contract.Assert(uint64(n) == size)
|
|
|
|
assets[file.Name] = NewByteBlob(data)
|
Implement archives
Our initial implementation of assets was intentionally naive, because
they were limited to single-file assets. However, it turns out that for
real scenarios (like lambdas), we want to support multi-file assets.
In this change, we introduce the concept of an Archive. An archive is
what the term classically means: a collection of files, addressed as one.
For now, we support three kinds: tarfile archives (*.tar), gzip-compressed
tarfile archives (*.tgz, *.tar), and normal zipfile archives (*.zip).
There is a fair bit of library support for manipulating Archives as a
logical collection of Assets. I've gone to great length to avoid making
copies, however, sometimes it is unavoidable (for example, when sizes
are required in order to emit offsets). This is also complicated by the
fact that the AWS libraries often want seekable streams, if not actual
raw contiguous []byte slices.
2017-04-30 21:37:24 +02:00
|
|
|
}
|
|
|
|
return assets, nil
|
|
|
|
}
|