How to overwrite git_source configuration in Asset Bundles
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-26-2024 01:49 AM
I'm using DAB to deploy a "jobs" resource into Databeicks and into two environments: "dev" and "prod". I pull the notebooks from a remote git repository using "git_resource", and defined the default job to use a tag to find which version to pull. However, in deploying to "dev" I would like to use a branch instead of tag. This could be done in the target configuration for "dev" but the problem is that it will also keep the tag along with the branch, which fails the deployment. So, the question is how to ignore the tag where a branch is defined?
Here are a snippet of my config files:
default_job.yml:
resources:
jobs:
job_name:
name: "name"
...
git_source:
git_url: "<git_url>"
git_provider: "<provider>"
git_tag: "<tag>"
...
dev.yml:
targets:
dev:
mode: development
...
resources:
jobs:
job_name:
git_source:
git_branch: "<branch>"
This will end up into the following config:
git_source": {
""git_branch": "<branch>",
"git_provider": "<provider>",
"git_tag": "<tag>",
"git_url": "<git_url>"
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-28-2024 06:04 AM
Hi @Retired_mod and thanks for replying. How does your solution differ from mine? Unless I'm missing some points here the only difference is with indentation, which actually makes "resources" a new target!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-17-2024 01:18 AM
I use target overrides to switch between branch and tags on different environments:
resources:
jobs:
my_job:
git_source:
git_url: <REPO-URL>
git_provider: gitHub
targets:
staging:
resources:
jobs:
my_job:
git_source:
# Use Git branch for staging deploys
git_branch: ${var.git_branch}
prod:
resources:
jobs:
my_job:
git_source:
# Use Git tag for prod deploys
git_tag: ${var.git_tag}
Discussion about that can be found here: https://github.com/databricks/cli/issues/1255
You need to repeat that for every job you define, which can be a pain if you have many jobs.

