-
Notifications
You must be signed in to change notification settings - Fork 71
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
Added support for artifacts building for bundles #583
Conversation
Nice! For your example, there doesn't seem to be a whl library referenced in the job? |
@lennartkats-db you're right, we do not need to explicitly reference the library in the same manner it is now in DBX. What happens underneath is that CLI check which package is being used in a job, finds corresponding artefact and attaches it as a library |
That seems like it's a bit too magical to me... It would become really hard to find out what is used in which jobs if you have a DAB with several (>1) jobs. I'd rather have an explicit reference to the library just like we always have in job definitions for libraries. To me it would be ideal if the job had an explicit reference to a whl file, just like it does today, without even using variables. That way we could even support visual editing of such a job. |
@lennartkats-db It's not unexpected though. If I specify a package |
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.
Please add an integration test with a minimal setup.py
just to check that performing the build works if the parameters are set correctly. I suspect it would have caught an issue with python.FindFileWithSuffixInPath("dist", ".whl")
.
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.
Last couple of comments that I didn't catch in the previous round.
Everything else LGTM.
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.
I'm really not comfortable with this amount of magic ... we should discuss what we want to do here. So far we have designed DABs to be explicit and have directly followed the API specs for the format. Automagically inserting a library dependency into one of the jobs seems contrary to that design and is contrary to the Python mantra of Explicit is better than Implicit. cc @pietern
artifactPath := b.Config.Workspace.ArtifactsPath | ||
b.WorkspaceClient().Workspace.Delete(ctx, workspace.Delete{ | ||
Path: artifactPath, | ||
Recursive: true, |
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.
Not too keen on a recursive delete without validation. If someone configures artifact_path
to ~
then this would remove everything underneath. Could we do some kind of validation prior to a recursive delete, or better yet, do some kind of tracking which files we have uploaded and only remove those?
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.
I'm not a big fan of tracking the uploaded files as it can be a complex and error prone in the end.
Instead I suggest to upload artifacts to subfolder of artifact_path
and then we can safely delete it each time
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.
That works. Agree file tracking would add a lot of complexity.
return fmt.Errorf("artifacts.whl.Build(%s): cannot find built wheel in %s", m.name, dir) | ||
} | ||
artifact.File = filepath.Join(dir, wheel) | ||
for _, wheel := range wheels { |
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.
When can we expect multiple wheels?
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.
For Python project I can imagine we might have some setup for monorepo and custom builds which yields multiple Python wheels.
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.
In that case I'd expect multiple artifacts be defined, one for each wheel. But it's fine for symmetry with the Java case you describe below.
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.
Case 3 is unexpected. Could we figure out a way to display a warning?
Addressed in the followup commits
Breaking Change: * Require include glob patterns to be explicitly defined ([#602](#602)). Bundles: * Add support for more SDK config options ([#587](#587)). * Add template renderer for Databricks templates ([#589](#589)). * Fix formatting in renderer.go ([#593](#593)). * Fixed python wheel test ([#608](#608)). * Auto detect Python wheel packages and infer build command ([#603](#603)). * Added support for artifacts building for bundles ([#583](#583)). * Add support for cloning repositories ([#544](#544)). * Add regexp compile helper function for templates ([#601](#601)). * Add unit test that raw strings are printed as is ([#599](#599)). Internal: * Fix tests under ./cmd/configure if DATABRICKS_TOKEN is set ([#605](#605)). * Remove dependency on global state in generated commands ([#595](#595)). * Remove dependency on global state for the root command ([#606](#606)). * Add merge_group trigger for build ([#612](#612)). * Added support for build command chaining and error on missing wheel ([#607](#607)). * Add TestAcc prefix to filer test and fix any failing tests ([#611](#611)). * Add url parse helper function for templates ([#600](#600)). * Remove dependency on global state for remaining commands ([#613](#613)). * Update CHANGELOG template ([#588](#588)).
Changes
Added support for artifacts building for bundles.
Now it allows to specify
artifacts
block in bundle.yml and define a resource (at the moment Python wheel) to be build and uploaded duringbundle deploy
Built artifact will be automatically attached to corresponding job task or pipeline where it's used as a library
Follow-ups:
Tests
Case 1. Explicitly defined libraries block
bundle.yml
Python wheel was successfully built and uploaded and attached to matching job.
Case 2. Explicitly defined libraries block but with non matching path
Case 3. No libraries block, artifact is not used
Integration test