shipwright-io / cli Goto Github PK

When running the shp build create or shp buildrun create commands, the supplied name is not passed on to the associated Build or BuildRun object.

shp command was built from main branch

$ _output/shp build create my-build --source-url https://github.com/shipwright-io/sample-php --output-image my-image
ERROR: Build.shipwright.io "" is invalid: metadata.name: Required value: name or generateName is required

$ _output/shp buildrun create my-buildrun --buildref-name my-build
ERROR: BuildRun.shipwright.io "" is invalid: metadata.name: Required value: name or generateName is required

Using the latest Shipwright Build Controller (v0.5.1) the CLI returns error when trying to create a new build:

$ _output/shp build create nodejs-ex \
	--source-url="https://github.com/otaviof/nodejs-ex.git" \
	--output-image="quay.io/otaviof/nodejs-ex:latest" \
	--output-credentials-secret="quayio-otaviof"
ERROR: Build.shipwright.io "" is invalid: metadata.name: Required value: name or generateName is required

Is there an existing feature request for this?

• I have searched the existing feature requests

Is your feature request related to a problem or use-case? Please describe.

Use Case

Describe the solution that you would like.

From @apoorvajagtap .Any plans on providing support for Strategies in the SHP CLI? It seems this was a gap, but it can initially be supported for listing and deleting operations. Main pain point is to require additional tools (e.g. kubectl) when working with shp cli.

Describe alternatives you have considered.

SHP CLI comes with support for Strategies, where List and Delete operations are supported.

Anything else?

No response

TestStartBuildRunFollowLog (pkg/shp/cmd/build)

for i in `seq 1 100` ; do 
	echo "# Attempt ${i}..."
	make test-unit \
		GO_FLAGS='' \
		GO_TEST_FLAGS='-race -failfast -timeout=45s' \
		CMD='' \
		PKG=./pkg/shp/cmd/build \
		ARGS='-run="^TestStartBuildRunFollowLog"' || break
done

Fails after a few attempts:

# Attempt 1...
go test  -race -failfast -timeout=45s  ./pkg/shp/cmd/build -run="^TestStartBuildRunFollowLog"
ok      github.com/shipwright-io/cli/pkg/shp/cmd/build  20.195s
# Attempt 2...
go test  -race -failfast -timeout=45s  ./pkg/shp/cmd/build -run="^TestStartBuildRunFollowLog"
ok      github.com/shipwright-io/cli/pkg/shp/cmd/build  21.195s
# Attempt 3...
go test  -race -failfast -timeout=45s  ./pkg/shp/cmd/build -run="^TestStartBuildRunFollowLog"
ok      github.com/shipwright-io/cli/pkg/shp/cmd/build  21.195s
# Attempt 4...
go test  -race -failfast -timeout=45s  ./pkg/shp/cmd/build -run="^TestStartBuildRunFollowLog"
[container] fake logs
panic: test timed out after 45s

Test_PodWatcherEvents (pkg/shp/reactor)

make test-unit \
	GO_TEST_FLAGS='-race -cover -failfast' \
	CMD='' \
	PKG=./pkg/shp/reactor \
	ARGS='-run="^Test_PodWatcherEvents"'

Running the same test a few times sequentially, ends up as the following:

go test -v -mod=vendor -race -cover -failfast  ./pkg/shp/reactor -run="^Test_PodWatcherEvents"
=== RUN   Test_PodWatcherEvents
=== RUN   Test_PodWatcherEvents/pod-is-added
=== RUN   Test_PodWatcherEvents/pod-is-modified
=== RUN   Test_PodWatcherEvents/pod-is-deleted
=== CONT  Test_PodWatcherEvents
    pod_watcher_test.go:234:
        Timed out after 10.001s.
        Expected
            <chan string | len:0, cap:5>: 0xc000444180
        to receive something.
--- FAIL: Test_PodWatcherEvents (10.00s)
    --- PASS: Test_PodWatcherEvents/pod-is-added (0.00s)
    --- PASS: Test_PodWatcherEvents/pod-is-modified (0.00s)
    --- PASS: Test_PodWatcherEvents/pod-is-deleted (0.00s)
FAIL
coverage: 59.1% of statements
FAIL    github.com/shipwright-io/cli/pkg/shp/reactor    10.038s
FAIL
make: *** [Makefile:60: test-unit] Error 1

See #106 (comment)

for common look and feel, employ the progress bar utility that @HeavyWombat employed for source bundle upload for the original local dir source upload that @otaviof crafted

shp build run --follow is my favorite command, but, it actually hangs if a pod never gets created. It should also watch the BuildRun status. If that completes with a failure, then it should also return.

As a developer, I would like to use a different container registry to run Bats based end-to-end tests. For instance, on this test case we define the output image as:

--output-image=registry.registry.svc.cluster.local:32222/shipwright-io/build-e2e

However, during the development workflow, it's common to use a different container registry and if not properly configured the Bats tests will fail.

Ideally, we should have a single function to define the output image, and thus create the opportunity to modify the output-image accordingly.

To improve the user experience when shp build upload for a big repository, we should support incremental uploads.

In high level, that means having a PVC mounted on /workspace/source instead of the emptyDir: {} currently employed. On the CLI side, using the incremental rsync protocol.

For the persistent volume under /workspace/source, we have SHIP-0022 covering volumes for a BuildStrategy and the issue-478 to consider.

See shipwright-io/build#1044 , on how it was enable for Build. This issue looks to mirror that work into this repo.

At the moment, many files in this repository do not have a copyright header. This needs to be fixed. Ideally, we also have an action that verifies the presence of those headers through an action during pull request validation.

Some infrastructure from the build repo to copy: https://github.com/shipwright-io/build/blob/main/hack/generate-copyright.sh

In the backend, we recently added support to specify image labels and annotations. This support is still missing in the CLI.

Here is the backend change: Specify annotations and labels to be set on output images #854

And the corresponding documentation: builds

Depending on the outcome of Cleanup usage of Image struct in Build and BuildRun #922, these settings might also get support for BuildRuns.

A Build resource may have .spec.sources[] with LocalCopy defined, in this case we should allow shp build create without requiring --source-url.

Perhaps we should have a toggle flag for this behavior.

/cc @qu1queee

The prefix name of release archive files is cli today, and i believe that it should be shp.

Prefix with kubectl-shp if we release a kubectl plugin of shp.

Other project cli name for release :

Command of tkn:
https://github.com/tektoncd/cli/releases/tag/v0.30.1

project name is cli and release file name with prefix tkn

command of gh:
https://github.com/cli/cli/releases/tag/v2.27.0

Project name is cli and release file name with prefix gh

Remind me if i missed something,Thanks.

Is there an existing feature request for this?

• I have searched the existing feature requests

Is your feature request related to a problem or use-case? Please describe.

The shp build sub-commands have flags that are closely tied to the underlying v1alpha1 API. These should be generalized or reconsidered so they are supported by the v1beta1 API, or potential future API versions.

Describe the solution that you would like.

Flag names should be "feature-oriented" so they are independent of the underlying API. For example, flags that explicitly reference apiVersion should be deprecated and removed.

Recommended changes (based on feedback below):

• [ ]

Describe alternatives you have considered.

Keep the existing flags - this will not prove tenable long term.

Anything else?

Use comments on this issue to suggest flag deprecations or renames. These will be added to the "solution" section once adopted.

Proposed during shipwright-io/community#183 discussion.

Is there an existing feature request for this?

• I have searched the existing feature requests

Is your feature request related to a problem or use-case? Please describe.

The CLI docs co-mingle reference docs (generated) with feature-related content (ex: local source upload).

Describe the solution that you would like.

Auto-generated content should be moved to a sub-directory under docs, such as reference

Describe alternatives you have considered.

Keep current state.

Anything else?

Related to shipwright-io/website#110 - a separate sub-directory will make it simpler for the website to present reference materials separately from tutorial/concept driven content.

Idea:

As a developer I would like to have an initial CLI that have a well defined root and initial subcommands, and the proper documentation on how to use them.

The root command should:

• have a short and long ad hoc description
• should be able to invoke a build subcommand and a buildrun subcommand.
• should be able to catch errors happening from the subcommands and return them to the user (e.g. exitCode 1)

The subcommands should:

• have a build subcommand that can perform CRUD operations on Shipwright Build CRDs
• have a build run subcommand that can perform CRUD operations on Shipwright BuildRun CRDs
• be able to propagate errors to the parent root cmd

The documentation should:

• Provide examples of usage
• Enhance the README

Acceptance_Criteria:

Provide the above via a PR.

Note: Additionally would be nice to have a well define Makefile target that can build a binary for different platforms

In the community meeting on May 9th, we decided that we can move to Go 1.18.

Updates are part of what was done in the update to 1.17, where also other dependencies were updated.

As a consequence, Tekton sets the Pod's spec.activeDeadlineSeconds to 0 which is not allowed. Imo we should not specify any timeout in the BuildRun if a user does not specify one.

Since we are cross-compiling the shp binary, we should ensure that all tests work on a macOS client.

GitHub actions now support macOS based runners - it is not clear if all of our dependent actions also support these runners (ex - install Docker, KinD, etc.)

See https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners

Per grooming, no objections on moving from go v1.18 to v1.19(latest stable). This requires two changes:

• go.mod
• CI(any Github action using a go runtime)

Is there an existing feature request for this?

• I have searched the existing feature requests

Is your feature request related to a problem or use-case? Please describe.

Per SHIP-0038, we are changing our release process to ship official releases from a release branch, rather than from main.

Describe the solution that you would like.

• CI and release scripts can be run on a release branch (with release-v* pattern)
• Release workflows must use an appropriate release branch and/or git reference (cannot blindly use latest commit from main)
• Tagging should be part of the release script process (currently must be done manually by a maintainer).

Describe alternatives you have considered.

See SHIP-0038 for discussion

Anything else?

Part of shipwright-io/community#85

I might be unclear on proper usage of the CLI, but I have been creating my builds like so...

shp buildrun create -n build --buildref-name foo \
  --output-image gcr.io/foo/bar:${{ steps.date.outputs.date }}-${GITHUB_SHA::4} \
  foo-${{ steps.date.outputs.date }}-${GITHUB_SHA::4}-${{github.run_attempt }}

and then trying to tail logs.

Some searching led me to find that I can follow w/ shp build run -F which is a little un-intuative.

Would love to be able to follow logs with shp buildrun logs or shp buildrun create similar to how you can with shp build run

Is there an existing feature request for this?

• I have searched the existing feature requests

Is your feature request related to a problem or use-case? Please describe.

Go 1.20 is end of support already.

Describe the solution that you would like.

We should update go.mod and CI to use Go 1.21. PR should be similar to the last one, though we also updated other stuff there.

Describe alternatives you have considered.

No response

Anything else?

No response

/kind bug

still seeing some intermittent panics with the multi-threaded TestStartBuildRunFollowLog unit test I recently added

=== RUN   TestStartBuildRunFollowLog
    run_test.go:173: Run initialization did not complete in time
--- FAIL: TestStartBuildRunFollowLog (3.00s)
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
	panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1b9e6cd]

goroutine 9 [running]:
testing.tRunner.func1.2({0x1c9cdc0, 0x2c0bd70})
	/opt/hostedtoolcache/go/1.17.1/x64/src/testing/testing.go:1209 +0x36c
testing.tRunner.func1()
	/opt/hostedtoolcache/go/1.17.1/x64/src/testing/testing.go:1212 +0x3b6
panic({0x1c9cdc0, 0x2c0bd70})
	/opt/hostedtoolcache/go/1.17.1/x64/src/runtime/panic.go:1047 +0x266
github.com/shipwright-io/cli/pkg/shp/cmd/build.(*RunCommand).onEvent(0xc0001901c0, 0xc000346400)
	/home/runner/work/cli/cli/pkg/shp/cmd/build/run.go:128 +0xe8d
github.com/shipwright-io/cli/pkg/shp/cmd/build.TestStartBuildRunFollowLog(0xc0003e6b60)
	/home/runner/work/cli/cli/pkg/shp/cmd/build/run_test.go:178 +0x1508
testing.tRunner(0xc0003e6b60, 0x1ed3f18)
	/opt/hostedtoolcache/go/1.17.1/x64/src/testing/testing.go:1259 +0x230
created by testing.(*T).Run
	/opt/hostedtoolcache/go/1.17.1/x64/src/testing/testing.go:1306 +0x727
FAIL	github.com/shipwright-io/cli/pkg/shp/cmd/build	3.211s

On the recent intereactions we've enabled end-to-end tests, with a KinD instance and Shipwright Build Controller running.

However, all Shipwright activity depends on having a output image set, the output configures the actual container registry image name and tag. And Shipwright will then dependent upon the container registry to complete a BuildRun.

We need a container registry for CI jobs, and documentation on how to use it. As an initial pointer, I would like to share KinD's Local Registry.

Just like the operator and build repos, we should require release notes to be added in pull requests.
This ensures quality contributions and ease in generating content for users.

Related: openshift/release#17632

This is a usability discussion:
Should the name argument for shp buildrun create be optional ?

e.g:

$ shp buildrun create --buildref-name=my-build
buildrun my-build-3214545124 has been created

If the name is not passed as a parameter, we could pass the shipwright-client a generatedName value which is based on --buildref-name . This way we can have a more consistent behaviour with the old oc start-build command but also with kubernetes dependent object creation style.

For compatibility reason we can keep the name as a possible parameter or we can even think at removing it.
What do you think?

It seems that specifying any of the command line options for shp build or shp build run (there may be more affected) are not propagated to the underlying objects.

I suggested this to @alicerum during some of her recently merged PRs

I then learned that based on prior planning, that was declared out of scope for her recently completed set of work.

Per conversation with @adambkaplan I'm opening an issue to track this.

Feels to me like a good way for me to tinker with some code, get familiar.

FYI, we have something very analogous to this with openshift builds, namely oc start-build -F

In verify.yaml, we today run a set of different tools. As decided in the community meeting from 2021/11/22, we should start to use golangci-lint and get rid of many of them.

Sibling issues:

• shipwright-io/build#948
• shipwright-io/operator#35

As the project evolves, we should work towards having a project logo, as we have for the Build Operator currently.

/kind documentation

We need to have publicly facing documents for shp's commands, sub-commands, and available options.
A lot of this already exists in code - ideally we should be able to generate this documentation and render it in Markdown so it can be consumed by GitHub and the website.

This issue should be focused on having auto-generated reference documentation. A make target should be used to make it easy to generate the docs in CI. A separate make target should verify that any generated doc changes are committed to git on pull requests.

Feature Request

Krew provides a management system for Kubernetes plugins.
Kubernetes plugins have a fairly simple API contract:

• Binary must be named kubectl-xxx, where xxx is the plugin name.
• Binary is placed in a specified path known to kubectl

This would allow the shp commands to be invoked indirectly with kubectl:

$ kubectl shp build run ...

There are a few advantages to creating a kubectl plugin:

• Shipwright's binary can inherit context/configuration from kubectl.
• Package managers like krew make it easier for developers to adopt Shipwright.

See the developer documentation for best practices on how we could distribute shp as a plugin.

/kind feature

Started seeing some overlap in validation individual PRs are doing in this repo with what is already done is spots like https://github.com/shipwright-io/build/blob/main/pkg/validate/

Do we just halt / remove doing analogous validations in the CLI?

Or do we create a common shared package of validations that can be used in both repos?

See a5a8cd8#r703641375 for a specific discussion thread / example.

As discussed in #6 , cli should output via klog and support multiple levels of verbosity.

Like @otaviof brought it up in a PR comment, I can highly recommend introducing GoReleaser. It covers the whole Go build nicely (including build parameters, reproducible builds), supports cross platform builds, and most importantly automation for release changelogs and releasing itself into for example Homebrew (for the macOS users) and Snap.

I have done it for dyff and it is really great. The configuration is pretty straight forward and I can certainly help with this issue having it done for other projects already. Works pretty well in GitHub Actions, too.

Now that we are using golang 1.17, the verify check fails because package io/ioutil is deprecated.

/kind bug

The command-line needs to print out information and errors for all sub-commands and we would benefit to have a single component responsible for this task. Right now we have a mixture of log and fmt.Printf going on, so we should come up with a new component which will be employed by all others that need to interact with the user.

Please share here your thoughts, and your ideas of what a logging component like this would have to have.

As decided in the community meeting from 2021/11/22, we want to scan for problematic dependencies. Candidate tool is go-licenses. Maybe there is also something in golangci-lint.

We should define the criteria for what is problematic and make sure we get red pull requests if those criteria are violated.

Sibling issues:

• shipwright-io/build#949
• shipwright-io/operator#36

Idea:

Currently PRs are failing on the E2E, this issue should serve as an investigation item on that.

See https://github.com/shipwright-io/cli/pull/56/files#diff-b3735b69bbdffbd0057392faad2520a70a01255bea7da053f2675836845d8869R28-R34

     [build-and-push] ERROR: No buildpack groups passed detection.
     [build-and-push] ERROR: Please check that you are running against the correct path.
     [build-and-push] ERROR: failed to detect: no buildpacks participating

Use the new tooling added in #70, we should generate release notes from pull request comments.

Goreleaser has support for this, the challenge is that we need to create the release tag and have goreleaser build the artifacts in a single workflow.

/kind cleanup

As is the case with the build controller, the command line should also have an automated release process driven by GitHub Actions.

The release should include the following:

• Cross compiled binaries
• Checksums for binaries
• Generated release notes
• Long term: Signed binaries for respective platforms (macOS and Windows in particular).

The cli crashes when listing all BuildRuns and one of them doesn't have a status.startTime. This could be reproduced when creating a BuildRun and linking a non-existing strategy.

Tested with Shipwright operator 0.9.0 and cli 0.9.0.

Example (with the status you get when running it):

apiVersion: shipwright.io/v1alpha1
kind: BuildRun
metadata:
  name: missing-strategy
spec:
  buildSpec:
    output:
      image: 'foo/bar:latest'
    source:
      contextDir: source-build
      url: 'https://github.com/shipwright-io/sample-go.git'
    strategy:
      kind: ClusterBuildStrategy
      name: missing-strategy
status:
  completionTime: '2022-05-04T07:49:11Z'
  conditions:
    - lastTransitionTime: '2022-05-04T07:49:11Z'
      message: clusterBuildStrategy missing-strategy does not exist
      reason: BuildRegistrationFailed
      status: 'False'
      type: Succeeded

➜  ~ shp buildrun -n christoph list 
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1789e33]

goroutine 1 [running]:
github.com/shipwright-io/cli/pkg/shp/cmd/buildrun.(*ListCommand).Run(0xc0002cbab0, 0xc0006bfd40, 0xc0006bfd68)
	github.com/shipwright-io/cli/pkg/shp/cmd/buildrun/list.go:88 +0x2d3
github.com/shipwright-io/cli/pkg/shp/cmd/runner.(*Runner).RunE(0xc0000ab080, 0xc0006bfd50, {0xc0000ab3e0, 0x0, 0x0})
	github.com/shipwright-io/cli/pkg/shp/cmd/runner/runner.go:35 +0x89
github.com/spf13/cobra.(*Command).execute(0xc0001a6f00, {0xc0000ab3c0, 0x2, 0x2})
	github.com/spf13/[email protected]/command.go:856 +0x60e
github.com/spf13/cobra.(*Command).ExecuteC(0x2dad1e0)
	github.com/spf13/[email protected]/command.go:974 +0x3bc
github.com/spf13/cobra.(*Command).Execute(...)
	github.com/spf13/[email protected]/command.go:902
main.main()
	./main.go:43 +0xe5

Expect a null check is missing here:

During the bootstrap of this project we thought the dynamic-client would be useful at some point, so this CLI project would not have to import all Kubernetes typed clients. However, in practice we do import Shipwright types (in go.mod), and we only rely on core/v1, so in other words, all types we need are already present.

Later on #19, we notice a change in the test behavior, which implies more effort on testing and making sure the results are adequate.

With that said, should we retire the dynamic-client, make sure we refactor this in an early project phase?

Is there an existing feature request for this?

• I have searched the existing feature requests

Is your feature request related to a problem or use-case? Please describe.

Build strategies support custom parameters for a long time already. In the meantime = in the Beta API, even the Dockerfile name has become a parameter.

We should finally add support for parameters in the CLI.

As a first step, let's start with single-values.

Describe the solution that you would like.

Here is my suggestion:

shp build create <NAME> --param-value <PARAMETER_NAME>:<PARAMETER_VALUE>

shp build run <NAME> --param-value <PARAMETER_NAME>:<PARAMETER_VALUE>

shp buildrun create <NAME> --param-value <PARAMETER_NAME>:<PARAMETER_VALUE>

NOTE: we do not have a shp build update command. We therefore do not need to think about how to remove a parameter.

TBD: Is the colon (:) a good separator, or should we use the equal sign (=) instead ?

Describe alternatives you have considered.

No response

Anything else?

Once this is done, we should open an issue with part 2 with array support.

The sub-command buildrun list should show more information about the resource, as in the output-image, elapsed build time, creation date, and more. The current output is as follows:

$ shp buildrun list
NAME                    STATUS                          AGE
nodejs-ex-srqsc         BuildRegistrationFailed         0s

And we would like to add the following new columns:

• ELAPSED-TIME: how long the build took, in case the build still running it should show how long has elapsed
• OUTPUT-IMAGE: fully qualified image produced

What other columns should we add?

/cc @SaschaSchwarze0

Idea

I'm currently playing with cli and one of the things that make I tedious to use, it is the amount of global flags.

Rational

I feel obliged to read the flags usage before triggering a subcommand, and the > 25 global flags just put me at the edge of not using it.

Goal

I would like to understand the reason behind this. I would favor an approach where they are brought to a minimum and I'm happy to contribute this.

Since we are cross-compiling the shp binary, we should ensure that all tests work on a Windows client.

GitHub actions now support Windows based runners - it is not clear if all of our dependent actions also support these runners (ex - install Docker, KinD, etc.)

See https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners

I´m wondering if it would be a nice sub command to allow users to list all the images they build. Something like:

shp images list

that gives you a list of:

<image name> <sha>

the above list will be generated by all the existing buildruns in a particular k8s namespace.

Looking for feedback.