Update GCS dependencies and fix GCS driver #3702

jmontleon · 2022-07-29T01:14:11Z

This change updates google cloud dependency as the current version dates back to a 2015 version and does not compile with the latest Go version.

jmontleon · 2022-07-29T04:04:47Z

registry/storage/driver/gcs/gcs.go

@@ -914,10 +921,6 @@ func putChunk(client *http.Client, sessionURI string, chunk []byte, from int64,
 	return bytesPut, err
 }

-func (d *driver) context(context context.Context) context.Context {


googleapis/google-cloud-go@a7a5fa8

The WithContext and NewContext functions were only needed for this legacy API pattern; the new Client pattern can use regular contexts from the golang.org/x/net/context package directly.

jmontleon · 2022-07-29T04:08:48Z

registry/storage/driver/gcs/gcs.go

 		}
-		for _, subpath := range objects.Prefixes {
-			subpath = d.keyToPath(subpath)
+		if object.Name == "" && object.Prefix != "" {


It looks lik the old version of the iterator kept prefixes separate. In the new version:
https://pkg.go.dev/cloud.google.com/go/storage#ObjectIterator.Next

If Query.Delimiter is non-empty, some of the ObjectAttrs returned by Next will have a non-empty Prefix field, and a zero value for all other fields. These represent prefixes.

codecov-commenter · 2022-07-29T07:34:19Z

Codecov Report

Patch and project coverage have no change.

Comparison is base (e5d5810) 56.58% compared to head (0a3d3ff) 56.58%.

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3702   +/-   ##
=======================================
  Coverage   56.58%   56.58%           
=======================================
  Files         105      105           
  Lines       10636    10636           
=======================================
  Hits         6018     6018           
  Misses       3946     3946           
  Partials      672      672

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

milosgajdos · 2022-07-29T07:40:32Z

Great effort @jmontleon ❤️

jmontleon · 2022-07-29T17:09:50Z

Thank you! When satisfied, I'm happy if you want to squash this, or merge #3676 (I think a go vendor will delete one more file if I'm not mistaken) then rebase this and merge on top of it. Please let me know how you want to handle it - I didn't want to steal anyone's thunder.

milosgajdos · 2022-07-29T17:22:29Z

Let's wait and see if we can merge #3676 . The author needs to reply :)

bshaaban · 2022-08-02T17:55:32Z

Let's wait and see if we can merge #3676 . The author needs to reply :)

my appologies for the delay, i had other urgent work to finalize which took my time out of this effort, we can definitely merge this PR, then i can rebase and update #3676 to complete the dep updates.

registry/storage/driver/s3-aws/s3_test.go

bshaaban · 2022-08-08T14:30:40Z

@milosgajdos @thaJeztah @Jamstah any maintainer who can approve & merge this pr? Or what is the process to get it merged? I know verifying and merging 457 files is not a simple task (this is why I'm so glad go.mod and go.sum files were introduced, it just avoids vendoring altogether, it would be awesome if we eventually can delete the vendor folder altogether).

It's blocking dep updates for many projects depending on this one.

Thanks.

kaovilai · 2022-08-08T15:14:02Z

@bshaaban meanwhile you can do what we did :D
https://github.com/openshift/openshift-velero-plugin/pull/151/files#diff-33ef32bf6c23acb95f5902d7097b7a1d5128ca061167ec0716715b0b9eeaa5f6R40
which uses commit from https://github.com/konveyor/distribution/tree/notv3

milosgajdos · 2022-08-08T15:31:30Z

@bshaaban I've allocated some time for a review on Friday -- I also want to give heads up that I'm not a GCP user so I'll be checking the API docs a lot and assuming @jmontleon's expertise on the topic :) Bear with me till then 🙇

jmontleon · 2022-08-08T15:34:43Z

I also want to give heads up that I'm not a GCP user so I'll be checking the API docs a lot and assuming @jmontleon's expertise on the topic

For the record, I am not an expert on GCP/GCS. I looked through the API docs and made an effort to restore functionality in order to help one of the teams that I work closely with. I would welcome any corrections from someone with more knowledge.

kaovilai · 2022-08-08T19:49:12Z

Other than the PR's content.. will this repository have any valid GCS credentials to supply to the CI for e2e testing?

Jamstah · 2022-08-08T20:59:07Z

Other than the PR's content.. will this repository have any valid GCS credentials to supply to the CI for e2e testing?

I expect not, wouldn't it be better to mock the gcp SDK instead?

Although... How is S3 tested?

corhere

As another reviewer unfamiliar with GCS, the changes generally look good to me. I have a few nits to pick about style and the like, though.

For posterity, could you please document in the PR description what was broken about the GCS driver that is being fixed?

corhere · 2023-04-27T14:04:14Z

registry/storage/driver/gcs/gcs.go

 }

-func storageStatObject(context context.Context, bucket string, name string) (*storage.Object, error) {
-	var obj *storage.Object
+func storageStatObject(ctx context.Context, bucket string, name string, gcs *storage.Client) (*storage.ObjectAttrs, error) {


OPTIONAL: Looking at how this function is used, all call sites pass the same arguments. The bucket and gcs arguments could be dropped entirely and the d.pathToKey boilerplate around the name arg could be elided by refactoring this function to a method on *driver.

Suggested change

func storageStatObject(ctx context.Context, bucket string, name string, gcs *storage.Client) (*storage.ObjectAttrs, error) {

func (d *driver) storageStatObject(ctx context.Context, name string) (*storage.ObjectAttrs, error) {

corhere · 2023-04-27T14:10:37Z

registry/storage/driver/gcs/gcs.go

@@ -68,6 +69,7 @@ type driverParameters struct {
 	client        *http.Client
 	rootDirectory string
 	chunkSize     int
+	GCS           *storage.Client


The new field should be private. There are ways in which concrete-typed values of unexported types could escape a package.

Suggested change

GCS *storage.Client

gcs *storage.Client

corhere · 2023-04-27T14:10:51Z

registry/storage/driver/gcs/gcs.go

@@ -97,6 +99,7 @@ type driver struct {
 	privateKey    []byte
 	rootDirectory string
 	chunkSize     int
+	GCS           *storage.Client


Suggested change

GCS *storage.Client

gcs *storage.Client

corhere · 2023-04-27T14:11:09Z

registry/storage/driver/gcs/gcs.go

@@ -369,17 +380,16 @@ type writer struct {
 	sessionURI string
 	buffer     []byte
 	buffSize   int
+	GCS        *storage.Client


Suggested change

GCS *storage.Client

gcs *storage.Client

corhere · 2023-04-27T14:18:46Z

registry/storage/driver/gcs/gcs.go

-	// try to get as file
-	gcsContext := d.context(context)
-	obj, err := storageStatObject(gcsContext, d.bucket, d.pathToKey(path))
+	//try to get as file


Comments without a leading space are reserved for directives.

Suggested change

//try to get as file

// try to get as file

corhere · 2023-04-27T15:06:07Z

registry/storage/driver/gcs/gcs.go

-	return objs, err
+func storageListObjects(ctx context.Context, bucket string, q *storage.Query, gcs *storage.Client) ([]*storage.ObjectAttrs, error) {
+	bkt := gcs.Bucket(bucket)
+	objs := []*storage.ObjectAttrs{}


https://github.com/golang/go/wiki/CodeReviewComments#declaring-empty-slices

Suggested change

objs := []*storage.ObjectAttrs{}

var objs []*storage.ObjectAttrs

corhere · 2023-04-27T15:12:02Z

registry/storage/driver/gcs/gcs.go

+	dst := gcs.Bucket(destBucket).Object(destName)
+	attrs, err := dst.CopierFrom(src).Run(ctx)
+	if err != nil {
+		if status, ok := err.(*googleapi.Error); ok {


errors.As is generally preferable to type-asserting an error value directly.

Suggested change

if status, ok := err.(*googleapi.Error); ok {

var status *googleapi.Error

if errors.As(err, &status) {

corhere · 2023-04-27T15:12:40Z

registry/storage/driver/gcs/gcs.go

+				return nil, storagedriver.PathNotFoundError{Path: srcName}
+			}
+		}
+		return nil, fmt.Errorf("Object(%q).CopierFrom(%q).Run: %v", destName, srcName, err)


Any reason not to wrap the error?

Suggested change

return nil, fmt.Errorf("Object(%q).CopierFrom(%q).Run: %v", destName, srcName, err)

return nil, fmt.Errorf("Object(%q).CopierFrom(%q).Run: %w", destName, srcName, err)

corhere · 2023-04-27T15:14:39Z

registry/storage/driver/gcs/gcs_test.go

@@ -42,6 +44,11 @@ func init() {
 		return
 	}

+	jsonKey, err := ioutil.ReadFile(credentials)


The io/ioutil package is deprecated.

Suggested change

jsonKey, err := ioutil.ReadFile(credentials)

jsonKey, err := os.ReadFile(credentials)

corhere · 2023-04-27T15:18:24Z

registry/storage/driver/gcs/gcs_test.go

+			client:         oauth2.NewClient(dcontext.Background(), ts),
+			chunkSize:      defaultChunkSize,
+			GCS:            gcs,
+			maxConcurrency: uint64(8),


FYI: literal numbers in Go don't have a type.

Suggested change

maxConcurrency: uint64(8),

maxConcurrency: 8,

milosgajdos · 2023-04-27T16:09:03Z

For posterity, could you please document in the PR description what was broken about the GCS driver that is being fixed?

The main reason was, the original GCS Go module was outdated so there was a legitimate worry should there be a need for a future fix or adding a new feature that would be hard or impossible with the ancient library.

jmontleon · 2023-04-27T16:17:46Z

Thank you @corhere, I made the suggested changes.

It's been a long time now @milosgajdos , but my understanding was also that the GCS driver would no longer even build. This PR replaced #3676 which makes a similar claim.

corhere

LGTM! Thanks for the quick turnaround

corhere · 2023-04-27T16:19:15Z

@thaJeztah PTAL

milosgajdos · 2023-04-27T16:19:52Z

Ping @thaJeztah -- your review is blocking the merge 😄

kaovilai · 2023-04-27T16:55:16Z

To fix this long term probably wanna add GCS driver back to CI..

kaovilai · 2023-04-27T16:55:52Z

by adding gcs buildtag to ci and having real creds

milosgajdos · 2023-04-27T17:01:13Z

by adding gcs buildtag to ci and having real creds

we need to do a proper review of the existing storage drivers; azure is also missing build tags. It's also a good question how we do the testing of all the storage drivers.

I'd like these to be ripped out to their dedicated repositories and added as go mod dependencies to the main repo -- that was we can delegate ownership of each driver to folks who work with them; for example I've very little knowledge of the GCS driver so my review is a bit of guessing and reading docs, etc.

There is work to be done, indeed.

thaJeztah

Thanks! I left some comments / questions (not all blockers, but some of them may be good to look into before merging)

thaJeztah · 2023-04-29T14:16:12Z

go.mod

-	google.golang.org/grpc v1.31.0 // indirect
-	google.golang.org/protobuf v1.26.0 // indirect
+	go.opencensus.io v0.24.0 // indirect
+	golang.org/x/net v0.8.0 // indirect; updated for CVE-2022-27664, CVE-2022-41717


Looks like this comment is no longer relevant; it was added in 345be95, but dependabot updated it in 9594fbc, and looks like it's now automatically bumped as minimum version

(we can fix that in a follow-up)

thaJeztah · 2023-04-29T15:20:36Z

registry/storage/driver/gcs/gcs.go

 func FromParameters(parameters map[string]interface{}) (storagedriver.StorageDriver, error) {
+	ctx := context.Background()


Are these all intentionally context.Background() or should we ultimately pass a context here (and should this be a context.TODO()?

Are all intended to share the same context? (previously jwtConf.TokenSource() and oauth2.NewClient() each got their own context.Background(), which is now shared. Just asking because in some cases it's deliberate that a new context is created.

As to "passing the context" (not a new issue, but went looking if there's a context to be passed);

FromParameters is used by the driverfactory.Create(), which is what's used by NewApp()

distribution/registry/handlers/app.go

Line 124 in 29b5e79

app.driver, err = factory.Create(config.Storage.Type(), storageParams)

And it looks like NewApp() takes a context (which is now not based on);

distribution/registry/handlers/app.go

Line 97 in 29b5e79

func NewApp(ctx context.Context, config *configuration.Configuration) *App {

This would have been a way bigger change than what this PR ships. Currently, no storage driver passes context to FromParameters. IMHO, should we decide to do this it should go into a separate PR.

Yes, not as part of this PR; the only change here could be to change context.Background() to a context.TODO() to more clearly indicate "this should still be punched through".

As to whether or not they should share the same context, I started reviewing before I noticed @corhere already reviewed; he's all familiar with the ins-and-outs of contexts, so I expect sharing the context is ok (otherwise he'd very likely would've called it out 😂)

Honestly I just skimmed that part of the code. I should have given it more scrutiny.

The returned [http] client is not valid beyond the lifetime of the context.

It looks like golang.org/x/oauth2 captures contexts in struct fields all over the place. oauth2.NewClient and jwtConf.TokenSource not having an error-return should have tipped me off that the passed contexts weren't just being used as cancelation signals for the constructor function calls themselves. I don't see any reasonable alternative to sharing a context, but it does mean that the constructed StorageDriver is not valid beyond the lifetime of the context. That's outside of the norm, so should be documented so as not to trip up people like me who expect the context lifetime to only bound the lifetime of the function call, not the validity of its return values.

thaJeztah · 2023-04-29T15:49:50Z

registry/storage/driver/gcs/gcs.go

-		rc, err = storage.NewReader(gcsContext, d.bucket, name)
-		return err
-	})
+	rc, err := d.gcs.Bucket(d.bucket).Object(name).NewReader(ctx)


Was it previously using a new client for each request? (storage.NewReader()) or did that also reuse the same client?

Answering myself; looks like they are designed to be reused. https://github.com/googleapis/google-cloud-go/blob/storage/v1.30.1/storage/storage.go#L126-L134

// Clients should be reused instead of created as needed. The methods of Client // are safe for concurrent use by multiple goroutines.

The only part I was wondering is if they need a specific scope assigned (but it looks like the old code already requested FullControl);

The default scope is ScopeFullControl. To use a different scope, like ScopeReadOnly, use option.WithScopes.

Would ScopeReadWrite be enough? Would there be benefits to having a separate client for read-operations?
https://github.com/googleapis/google-cloud-go/blob/storage/v1.30.1/storage/storage.go#L77-L87

thaJeztah · 2023-04-29T16:06:38Z

registry/storage/driver/gcs/gcs.go

-	for {
-		objects, err := storageListObjects(d.context(context), d.bucket, query)
-		if err != nil {
-			return nil, err
-		}
-		for _, obj := range objects.Results {
-			// GCS does not guarantee strong consistency between
-			// DELETE and LIST operations. Check that the object is not deleted,
-			// and filter out any objects with a non-zero time-deleted
-			if obj.Deleted.IsZero() {
-				list = append(list, obj.Name)
-			}
-		}
-		query = objects.Next
-		if query == nil {
-			break


I see this loop moved into storageListObjects() ..

thaJeztah · 2023-04-29T16:18:41Z

registry/storage/driver/gcs/gcs.go

+	it := bkt.Objects(ctx, q)
+	for {
+		objAttrs, err := it.Next()
+		if err == iterator.Done {
+			break
+		}
+		if err != nil {
+			return nil, err
+		}
+		objs = append(objs, objAttrs)
+	}


.. before this PR, it looks like listAll() and List() would use the .next to iterate. But now all results are appended to objs;

Both check for obj.Deleted.IsZero(), and other properties to check if the object must be included

Both append the result to another slice

... but storageCopyObject() unconditionally iterates over all objects (which may even involve multiple API calls), and append all of them to objs[]

I'm not sure how many objects will be returned, but from the above, perhaps it would be better to keep the logic (calling it.Next() as part of those functions)?

thaJeztah · 2023-04-29T16:26:52Z

registry/storage/driver/gcs/gcs.go

+	var objs []*storage.ObjectAttrs
+	it := bkt.Objects(ctx, q)


If we do need to keep a single slice (but see my other comment), would it be possible to initialise objs with an initial capacity based on that (to reduce allocations)?

objs := make([]*storage.ObjectAttrs, 0, `<some expected size>`)

Not sure what information we have available about the expected number of results though; I see the iterator has a PageInfo, but that only has the number of items remaining before a new API call has to be made;
https://pkg.go.dev/google.golang.org/api/iterator#PageInfo.Remaining

thaJeztah · 2023-04-29T16:28:59Z

registry/storage/driver/gcs/gcs.go

+		if object.Deleted.IsZero() && object.ContentType != uploadSessionContentType && object.Name != "" {
+
+			list = append(list, d.keyToPath(object.Name))
 		}


If we expect a lot of objects, perhaps it's worth trying to continue as early as possible, and handle the more lightweight checks first;

Suggested change

if object.Deleted.IsZero() && object.ContentType != uploadSessionContentType && object.Name != "" {

list = append(list, d.keyToPath(object.Name))

}

if object.Name == "" || object.ContentType == uploadSessionContentType || !object.Deleted.IsZero() {

continue

}

list = append(list, d.keyToPath(object.Name))

thaJeztah · 2023-04-29T16:34:22Z

registry/storage/driver/gcs/gcs.go

-		for _, subpath := range objects.Prefixes {
-			subpath = d.keyToPath(subpath)
+		if object.Name == "" && object.Prefix != "" {
+			subpath := d.keyToPath(object.Prefix)


From a quick glance, it looks like in most cases we only need a limited set of the Object's attributes, but a lot more attributes are (potentially) available; https://pkg.go.dev/cloud.google.com/go/storage#ObjectAttrs

The documentation calls out that retrieving all attributes may have a performance impact;
https://pkg.go.dev/cloud.google.com/go/storage#hdr-Listing_objects

If only a subset of object attributes is needed when listing, specifying this subset using Query.SetAttrSelection may speed up the listing process:

Perhaps worth looking into if we can limit the attributes that we retrieve.

thaJeztah · 2023-04-29T16:35:54Z

registry/storage/driver/gcs/gcs.go

@@ -640,33 +652,29 @@ func (d *driver) Stat(context context.Context, path string) (storagedriver.FileI

 // List returns a list of the objects that are direct descendants of the
 // given path.
-func (d *driver) List(context context.Context, path string) ([]string, error) {
+func (d *driver) List(ctx context.Context, path string) ([]string, error) {
 	var query *storage.Query
 	query = &storage.Query{}
 	query.Delimiter = "/"
 	query.Prefix = d.pathToDirKey(path)
 	list := make([]string, 0, 64)


Not new, but (also see my other comment); do we know where the initial 64 capacity comes from? Is that just a randomly picked value, and should this be based on actual (expected number of) results instead?

I vaguely remember this was a bit of a mystery to me in past and now you've revived the memories. It's hard to think of an "expected number of results other than an educated guess here - List lists the storage keys which can be arbitrarily long (or short). 64 is a slice capacity parameter not the length so I see this as a pre-allocated buffer guesstimate that might help us reap some benefits should the number of listed storage keys is >64 (no need to reallocate the slice until we exceed the count of 64); we could discuss performance implications of this for sure, but I don't see this as a major problem at the moment.

milosgajdos · 2023-05-19T15:51:37Z

This needs a rebase again @jmontleon 😬

kaovilai · 2023-05-19T15:52:49Z

Don't maintainers also have push access? that may help push this PR forward IMO.

milosgajdos · 2023-05-19T18:50:49Z

@kaovilai this needs rebasing - I dont think I can force push to @jmontleon fork. IIRC it used to be possible in past.

$ git push origin -f update-fix-gcs
ERROR: Permission to jmontleon/distribution.git denied to milosgajdos.
fatal: Could not read from remote repository.

kaovilai · 2023-05-19T18:54:46Z

Rebasing can also be done by maintainer.
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork

You can force push to a fork that is not your own. I had just did this one hour ago to a fork PR.

milosgajdos · 2023-05-19T19:00:09Z

Yeah, it's not my first rodeo 😄 but as you can see in that output for whatever reason I am unable to push to that fork.

kaovilai · 2023-05-19T19:07:26Z

I have better luck with ssh remote-url generally. have you tried that? or try github cli gh pr checkout 3702

Signed-off-by: Jason Montleon <jmontleo@redhat.com>

jmontleon · 2023-05-22T14:01:28Z

Rebased. Are there any concrete changes required to get this merged?

milosgajdos · 2023-05-22T14:08:24Z

Rebased. Are there any concrete changes required to get this merged?

There are some questions by @thaJeztah -- he blocked this PR so chase him, please.

kaovilai · 2023-05-22T14:49:55Z

Someone please feel free to take this work and open a new PR as what's in main right now does not build at all.

It's been almost a year of chasing perfection and rebasing so we are abandoning ship at this point.

flavianmissi · 2023-05-23T13:07:26Z

I've moved the work to a new PR, could y'all help with review?
Tests are passing 💯

@jmontleon

Fix gcs storage driver Thanks to @jmontleon who laid the first bricks in #3702

jmontleon force-pushed the update-fix-gcs branch 2 times, most recently from 7f04198 to 9d41ebb Compare July 29, 2022 01:16

jmontleon mentioned this pull request Jul 29, 2022

update google.golang.org/cloud #3668

Closed

kaovilai mentioned this pull request Jul 29, 2022

chore: bump google cloud storage #3676

Closed

jmontleon force-pushed the update-fix-gcs branch 6 times, most recently from ca64a79 to 2ea2d29 Compare July 29, 2022 03:59

jmontleon commented Jul 29, 2022

View reviewed changes

jmontleon marked this pull request as ready for review July 29, 2022 04:09

jmontleon force-pushed the update-fix-gcs branch 2 times, most recently from 984e877 to a47e556 Compare July 29, 2022 17:02

This was referenced Jul 29, 2022

Dockerfile: pass BUILDTAGS to go build #3703

Closed

OADP-602: Include GCS storage driver when building plugin openshift/openshift-velero-plugin#151

Merged

bshaaban reviewed Aug 3, 2022

View reviewed changes

registry/storage/driver/s3-aws/s3_test.go Outdated Show resolved Hide resolved

bshaaban approved these changes Aug 3, 2022

View reviewed changes

corhere reviewed Apr 27, 2023

View reviewed changes

jmontleon force-pushed the update-fix-gcs branch from fd50ceb to f4c5148 Compare April 27, 2023 16:15

corhere approved these changes Apr 27, 2023

View reviewed changes

jmontleon force-pushed the update-fix-gcs branch from f4c5148 to b1a0604 Compare April 27, 2023 16:23

thaJeztah reviewed Apr 29, 2023

View reviewed changes

dkulchinsky mentioned this pull request May 1, 2023

Harbor Registry does not support AssumeRoleWithWebIdentity goharbor/harbor#12888

Open

This was referenced May 19, 2023

StorageDriver gcs not registered when updating 2.8.1 -> 2.8.2 #3919

Closed

[release/2.8] Enable build tags in 2.8 #3927

Closed

Update GCS dependencies and fix GCS driver

97b8624

Signed-off-by: Jason Montleon <jmontleo@redhat.com>

jmontleon force-pushed the update-fix-gcs branch from b1a0604 to 97b8624 Compare May 22, 2023 13:58

jmontleon closed this May 22, 2023

flavianmissi mentioned this pull request May 23, 2023

Fix gcs storage driver #3929

Merged

milosgajdos added a commit that referenced this pull request Jun 1, 2023

Merge pull request #3929 from flavianmissi/fix-gcs-oss-file-writer

5902a24

Fix gcs storage driver Thanks to @jmontleon who laid the first bricks in #3702

	func storageStatObject(ctx context.Context, bucket string, name string, gcs storage.Client) (storage.ObjectAttrs, error) {
	func (d driver) storageStatObject(ctx context.Context, name string) (storage.ObjectAttrs, error) {

	objs := []*storage.ObjectAttrs{}
	var objs []*storage.ObjectAttrs

	if status, ok := err.(*googleapi.Error); ok {
	var status *googleapi.Error
	if errors.As(err, &status) {

	return nil, fmt.Errorf("Object(%q).CopierFrom(%q).Run: %v", destName, srcName, err)
	return nil, fmt.Errorf("Object(%q).CopierFrom(%q).Run: %w", destName, srcName, err)

	jsonKey, err := ioutil.ReadFile(credentials)
	jsonKey, err := os.ReadFile(credentials)

		func FromParameters(parameters map[string]interface{}) (storagedriver.StorageDriver, error) {
		ctx := context.Background()

Update GCS dependencies and fix GCS driver #3702

Update GCS dependencies and fix GCS driver #3702

Conversation

jmontleon commented Jul 29, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov-commenter commented Jul 29, 2022 • edited Loading

Codecov Report

milosgajdos commented Jul 29, 2022

jmontleon commented Jul 29, 2022

milosgajdos commented Jul 29, 2022

bshaaban commented Aug 2, 2022

bshaaban commented Aug 8, 2022

kaovilai commented Aug 8, 2022

milosgajdos commented Aug 8, 2022

jmontleon commented Aug 8, 2022 • edited Loading

kaovilai commented Aug 8, 2022 • edited Loading

Jamstah commented Aug 8, 2022

corhere left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

corhere Apr 27, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

milosgajdos commented Apr 27, 2023

jmontleon commented Apr 27, 2023

corhere left a comment

Choose a reason for hiding this comment

corhere commented Apr 27, 2023

milosgajdos commented Apr 27, 2023

kaovilai commented Apr 27, 2023

kaovilai commented Apr 27, 2023

milosgajdos commented Apr 27, 2023

thaJeztah left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

milosgajdos commented May 19, 2023

kaovilai commented May 19, 2023

milosgajdos commented May 19, 2023 • edited Loading

kaovilai commented May 19, 2023

milosgajdos commented May 19, 2023

kaovilai commented May 19, 2023

jmontleon commented May 22, 2023

milosgajdos commented May 22, 2023

kaovilai commented May 22, 2023

flavianmissi commented May 23, 2023

jmontleon commented Jul 29, 2022 •

edited

Loading

codecov-commenter commented Jul 29, 2022 •

edited

Loading

jmontleon commented Aug 8, 2022 •

edited

Loading

kaovilai commented Aug 8, 2022 •

edited

Loading

corhere Apr 27, 2023 •

edited

Loading

milosgajdos commented May 19, 2023 •

edited

Loading