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

[DevEx] xpkg: add error contexts and print & fail on parse errors #342

Merged
merged 7 commits into from
Jul 13, 2023

Conversation

sttts
Copy link
Contributor

@sttts sttts commented Jul 10, 2023

This PR adds errors contexts (e.g. filenames) to errors returned in the xpkg commands. Moreover, it removes the TODO in the workspace loader of missing error handling.

@sttts sttts force-pushed the sttts-xpkg-error-contexts branch 2 times, most recently from 5d6608a to 5468781 Compare July 10, 2023 10:23
Copy link
Member

@tnthornton tnthornton left a comment

Choose a reason for hiding this comment

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

Thanks @sttts ! I love all of the improvements to the amount of context we're providing. I left a couple of questions below. Let me know if there's anything I can clarify 👍

@@ -115,6 +115,35 @@ type buildCmd struct {
Ignore []string `help:"Paths, specified relative to --package-root, to exclude from the package."`
}

func (c *buildCmd) Help() string {
Copy link
Member

Choose a reason for hiding this comment

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

nit - It seems like this output is more about the xpkg command and less about building the actual artifact, is that accurate? Would it make sense to move this up to that command and inside this subcommand add more details about the build operation?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

am actually calling this in the xpkg command. But let me reread and maybe rephrase one of them.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Please take a look at the new text for the build command. You will probably have more background of the command, so feel free to suggest another text, fix or add things.


If a package is specified, it will be added to the crossplane.yaml file
in the current directory.
`
Copy link
Member

Choose a reason for hiding this comment

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

Would it be worth adding interaction details in addition to the above? I'm thinking similar to what is in code comments like so

// New returns a new v1beta1.Dependency based on the given package name
// Expects names of the form source@version where @version can be
// left blank in order to indicate 'latest'.
.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

// TODO(hasheddan): we cannot make use of strict unmarshal to identify
// extraneous fields because we don't have the underlying Go types. In
// the future, we would like to provide warnings on fields that are
// extraneous, but we will likely need to augment the OpenAPI validation
// to do so.
if err := k8syaml.Unmarshal(b, &obj); err != nil {
return NodeIdentifier{}, err
if v.printer != nil {
v.printer.Printfln("WARNING: ignoring file %s: missing 'kind' field, not a Kubernetes object", v.relativePath(pCtx.path))
Copy link
Member

Choose a reason for hiding this comment

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

I believe this path is invoked both from xpkg build as well from xpls during document parsing. It's unclear how this error will be rendered in the later case, maybe it'll show up in the xpls logs. I wonder if it's still worth returning error instead of nil, although given

// TODO(hasheddan): errors should be aggregated and returned as
// diagnostics.
, maybe that's moot at this point in time 🤔.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added error aggregation here too now.

Copy link
Contributor Author

@sttts sttts Jul 11, 2023

Choose a reason for hiding this comment

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

To understand: for the language server we want to be more permissive with errors. When the user edits files, we should try to keep going in parsing. Thinking about adding a permissive flag that ignores errors, just warns.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

Signed-off-by: Dr. Stefan Schimanski <stefan.schimanski@upbound.com>
Signed-off-by: Dr. Stefan Schimanski <stefan.schimanski@upbound.com>
Signed-off-by: Dr. Stefan Schimanski <stefan.schimanski@upbound.com>
Signed-off-by: Dr. Stefan Schimanski <stefan.schimanski@upbound.com>
Signed-off-by: Dr. Stefan Schimanski <stefan.schimanski@upbound.com>
Signed-off-by: Dr. Stefan Schimanski <stefan.schimanski@upbound.com>
@sttts sttts force-pushed the sttts-xpkg-error-contexts branch from b564af8 to f26cf68 Compare July 11, 2023 13:32
@Upbound-CLA
Copy link

Upbound-CLA commented Jul 11, 2023

CLA assistant check
All committers have signed the CLA.

Copy link
Member

@tnthornton tnthornton left a comment

Choose a reason for hiding this comment

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

LGTM 👍. Thanks again @sttts!

Copy link
Contributor

@ulucinar ulucinar left a comment

Choose a reason for hiding this comment

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

Thanks @sttts, just gave this PR a try for:

  • upbound/provider-aws: up xpkg batch is producing provider families with the expected layers and metadata. Observed with: index.docker.io/ulucinar/provider-family-aws:v0.37.0-rc.0.56.g257bedd2, index.docker.io/ulucinar/provider-aws-ec2:v0.37.0-rc.0.56.g867782ef, index.docker.io/ulucinar/provider-aws:v0.37.0-rc.0.56.g867782ef
  • upbound/provider-azuread: up xpkg build and up xpkg push are producing provider packages with the expected layers and metadata. Observed with: index.docker.io/ulucinar/provider-azuread:v0.10.0-rc.0.6.gb7fc503

Thank you for the improvements.

@sttts
Copy link
Contributor Author

sttts commented Jul 13, 2023

Thanks @ulucinar. Let's 🚢 it.

@sttts sttts merged commit ed8226a into upbound:main Jul 13, 2023
6 checks passed
@sttts sttts deleted the sttts-xpkg-error-contexts branch July 13, 2023 06:53
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.

None yet

4 participants