-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add package push command #340
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is very cool to see packages making its way into the CLI 💪
I will defer to you with more go experience, but have noted below lots of different ways than what we currently have for other commands if you can comment on those
pkg/cmd/pkg/push.go
Outdated
|
||
func NewCmdPackagePush(f *factory.Factory) *cobra.Command { | ||
cmd := cobra.Command{ | ||
Use: "push --registry <registry> {--file <file> | --file-name <filename> -}", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One other thing we've tried to do is allow each command to do "something" useful by default without any flags. And so all flags are optional to modify the default behaviour.
If there is something that is required, I think it should be an argument instead? Ie. should registry (or maybe both flags) be positional arguments instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, i think that the right approach here is probably:
--registry
becomes the first positional arg--file
becomes an optional second positional arg--file-name
gets renamed to--stdin-file-name
, and allows the second positional arg to be omitted
43091dd
to
677efcc
Compare
go.mod
Outdated
@@ -24,6 +24,8 @@ require ( | |||
golang.org/x/sync v0.7.0 | |||
) | |||
|
|||
replace github.com/buildkite/go-buildkite/v3 => ../go-buildkite |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
probably need to do another release and reverse this?
330ee8b
to
96312c1
Compare
pkg, _, err := f.RestAPIClient.PackagesService.Create(f.Config.OrganizationSlug(), cfg.RegistrySlug, buildkite.CreatePackageInput{ | ||
Filename: packageName, | ||
Package: from, | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add a check to ensure this isn't a nil pointer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, i was wondering about that earlier... theoretically loadAndValidateConfig
should ensure that one or the other of the two sources is selected, but it can't hurt to double check.
given that neither stdin nor a file being available is likely an error in programming, i might add a
default:
panic("oh no!")
to the switch block above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this upload where the bulk of the time will be spent? Ie if its uploading a few MB or many more, it could take a while. We have a spinner package we use to give the user some feedback at least. I made a patch you can apply if you like: https://gist.github.com/jradtilbrook/a3af75bab23d26edb6f2bb2291bf17d1
I'm assuming simply opening the file won't take long and not worth including in the spinner
return fmt.Errorf("couldn't open file %s: %w", cfg.FilePath, err) | ||
} | ||
|
||
defer file.Close() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this come before the error check to ensure the file is closed even in the result of an error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ooh yup, good call
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If os.Open
returns an error, then file
is (probably) nil, so defer file.Close()
before checking err
would probably cause a nil dereference panic.
TODO: Update to an actual version of go-buildkite
@@ -30,7 +30,7 @@ func mainRun() int { | |||
} | |||
|
|||
if err := rootCmd.ExecuteContext(ctx); err != nil { | |||
fmt.Fprintf(os.Stderr, "failed to execute command: %s\n", err) | |||
// Errors already get printed by the cobra command runner |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh my god. That has been bugging me but I keep forgetting to create a ticket/look into it. Thank you!!
This PR: Adds a new command to the buildkite cli,
package push
. This command allows users to publish packages to buildkite packages using the CLI.Attached is the help text for the new command:
A usage example:
$ bkcli package push bennos-gemmos ./test-1.0.0.gem Created package: test View it on the web at: http://buildkite.localhost/organizations/buildkite/packages/registries/bennos-gemmos/packages/01918cd0-2568-73aa-8ea3-3d4ec8c0e615