Skip to content
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

Merged
merged 11 commits into from
Sep 3, 2024
Merged

Add package push command #340

merged 11 commits into from
Sep 3, 2024

Conversation

moskyb
Copy link
Contributor

@moskyb moskyb commented Aug 23, 2024

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:

Push a new package to Buildkite Packages. The package can be passed as a path to a file in the second positional argument,
or via stdin. If passed via stdin, the filename must be provided with the --stdin-file-name flag, as Buildkite
Packages requires a filename for the package.

Usage:
  bk package push registry-name {path/to/file | --stdin-file-name filename -} [flags]

Examples:
$ bk package push my-registry my-package.tar.gz
$ cat my-package.tar.gz | bk package push my-registry --stdin-file-name my-package.tar.gz - # Pass package via stdin, note hyphen as the argument


Flags:
  -h, --help                     help for push
  -n, --stdin-file-name string   The filename to use for the package, if it's passed via stdin. Invalid otherwise.

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

Copy link
Contributor

@jradtilbrook jradtilbrook left a 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/package.go Outdated Show resolved Hide resolved
pkg/cmd/pkg/push.go Outdated Show resolved Hide resolved
pkg/cmd/pkg/push.go Outdated Show resolved Hide resolved
pkg/cmd/pkg/push.go Outdated Show resolved Hide resolved
pkg/cmd/pkg/push.go Outdated Show resolved Hide resolved

func NewCmdPackagePush(f *factory.Factory) *cobra.Command {
cmd := cobra.Command{
Use: "push --registry <registry> {--file <file> | --file-name <filename> -}",
Copy link
Contributor

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?

Copy link
Contributor Author

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

@moskyb moskyb force-pushed the package-create branch 5 times, most recently from 43091dd to 677efcc Compare August 26, 2024 03:51
@moskyb moskyb requested a review from jradtilbrook August 26, 2024 03:52
go.mod Outdated
@@ -24,6 +24,8 @@ require (
golang.org/x/sync v0.7.0
)

replace github.com/buildkite/go-buildkite/v3 => ../go-buildkite
Copy link
Contributor

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?

pkg/cmd/pkg/push.go Outdated Show resolved Hide resolved
jradtilbrook
jradtilbrook previously approved these changes Aug 27, 2024
@moskyb moskyb force-pushed the package-create branch 3 times, most recently from 330ee8b to 96312c1 Compare August 27, 2024 01:56
Comment on lines +61 to +69
pkg, _, err := f.RestAPIClient.PackagesService.Create(f.Config.OrganizationSlug(), cfg.RegistrySlug, buildkite.CreatePackageInput{
Filename: packageName,
Package: from,
})
Copy link
Contributor

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?

Copy link
Contributor Author

@moskyb moskyb Aug 27, 2024

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.

Copy link
Contributor

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()
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ooh yup, good call

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.

@@ -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
Copy link
Contributor

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!!

@jradtilbrook jradtilbrook enabled auto-merge (squash) September 3, 2024 03:14
@jradtilbrook jradtilbrook merged commit c01e962 into 3.x Sep 3, 2024
1 check passed
@jradtilbrook jradtilbrook deleted the package-create branch September 3, 2024 03:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants