-
Notifications
You must be signed in to change notification settings - Fork 31
fix Link 'label:assets' field type as list #183
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
Conversation
@vincentsarago |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #183 +/- ##
==========================================
- Coverage 96.59% 95.52% -1.07%
==========================================
Files 25 25
Lines 587 671 +84
==========================================
+ Hits 567 641 +74
- Misses 20 30 +10
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
min_length=1, | ||
alias="label:assets", | ||
validation_alias=AliasChoices("label:assets", "label_assets", "label"), | ||
) |
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.
🤔 well to be honest I believe we should just remove the label attribute and let extension
be handled with validate_extensions
https://github.com/stac-utils/stac-pydantic?tab=readme-ov-file#extensions
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.
Yes. That makes the most sense IMO as well.
Are all extensions validated automatically by STAC-FastAPI when POSTing a STAC Item?
I don't see explicit calls to validate_extensions
in the code.
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 don't think they are validated but we could add an option. Can you open an issue in stac-fastapi?
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.
Yes. I can look into adding that.
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.
Feature ready: stac-utils/stac-fastapi-pgstac#269
Replacement for this PR: #184
## Overview Add more flexibility to `birdhouse backup` operations. Depends on #534 for modified `stac-db` image. ## Changes **Non-breaking changes** - Backup: Allow `BIRDHOUSE_BACKUP_VOLUME` to be employed directly as directory. This feature _**requires**_ using the `--no-restic` option to avoid it being involved by ``--snapshot`` override. Combining a directory path and omitting `--no-restic` can lead to undesired side effects. However, it allows using backup/restore operations for quick data manipulations on alternate locations than a volume to offer flexibility or to bypass `restic` operations. This can be employed for fixing problematic service data migrations or file system limitations with volumes. The directory structure must match exactly with `BIRDHOUSE_BACKUP_VOLUME` when used as volume (e.g.: `/tmp/backup/{component}-{backup_type}/...`). This feature also disables the automatic cleanup of the volume (since the directory is used directly). Therefore, users have to manage the contents of `BIRDHOUSE_BACKUP_VOLUME` on their own and consistently. - Backup: Avoid `birdhouse backup restore` operation to complain about missing `-s|--snapshot` when not required. For example, `BIRDHOUSE_BACKUP_VOLUME=/tmp/backup birdhouse backup restore --no-restic -r stac` only operates on local data contents to be restored into the server instance. No remote `restic` snapshot is required to run the operation. - Backup: Unification of script shebangs, variables names and function names with invoked operations. - Renames related to `backup [create|restore|restic]` when they apply to many operations simultaneously. This helps highlight that a variable with explicitly `CREATE`, `RESTORE` or `RESTIC` only applies to that specific operation, whereas others are shared. - `parse_backup_restore_common_args` => `parse_backup_common_args` - `BIRDHOUSE_BACKUP_RESTORE_NO_RESTIC` => `BIRDHOUSE_BACKUP_NO_RESTIC` - `BIRDHOUSE_BACKUP_RESTORE_COMMAND` => `BIRDHOUSE_BACKUP_COMMAND` - Renames to match the common `BIRDHOUSE_BACKUP_[...]` prefix employed by other "backup" variables: - `BIRDHOUSE_RESTORE_SNAPSHOT` => `BIRDHOUSE_BACKUP_RESTORE_SNAPSHOT` - Backup: Add `stac-migration` image to the list of containers to stop on `birdhouse backup restore -r stac`. Because the service was not stopped, and that it links to `stac-db` and its corresponding volume, the following `docker volume rm stac-db` step would fail as the volume was still in use. This would lead to a restore operation dealing with dirty database contents and potentially conflicting restore data that would not be applied. Relates to added service `stac-migration` in [#534](#534). **Breaking changes** - n/a ## Related Issue / Discussion - fixes #558 - relates to #534 - #562 (comment) - stac-utils/stac-pydantic#183 >[!NOTE] > Will wait for above fixes to be available and applied in `stac-app` to validate the full backup procedure with `-r stac`. ## CI Operations birdhouse_daccs_configs_branch: master birdhouse_skip_ci: false
Posting a STAC Item that contains
label:assets
as defined below results in a validation error since thestr
doesn't match the expected list (https://github.com/stac-extensions/label?tab=readme-ov-file#links-source-imagery).I've tested that the fix works as expected by running our https://github.com/crim-ca/stac-app (STAC-FastAPI) with this
stac-pydantic
patch applied.