refactor and new features to support DMS space ACLs

cognitedata / inso-bootstrap-cli

CLI and GitHub-Action to configure and maintain CDF Projects (Groups, Data Sets, RAW DBs)

Apache License 2.0

4 stars 2 forks source link

refactor and new features to support DMS space ACLs #68

Closed spex66 closed 1 year ago

spex66 commented 1 year ago

Change to dependency-injector and latest Python SDK
bumped to py3.10
complete refactoring of code base and split into modules
config-classes reworked into pydantic
support for new dataModelsAcl and dataModelInstancesAcl for DMS v3
- to support this new ACLs and their new "space" based scoping, a SDK injection was made, as Python SDK has no official support for it
- testing and refactoring is going on
Check MIGRATION_NOTES_v2_to_v3.md for changes

spex66 commented 1 year ago

Does this change affect the existing Bootcamp?

I need to check how bootstrap-cli and configs are used. The MIGRATION_NOTES_v2_to_v3.md is listing the changes.

spex66 commented 1 year ago

make consistent strings. f-strings vs. format. Some places you use one, other another

I've found and fixed one case to switch from .format() to f-string. All others are using .format() because I use predefined f-string-templates (factories).

spex66 commented 1 year ago

double-check Dockerfile. I think you have many packages left and you are not installing pip packages in a safe manner into your production image

That I need to review. I've tried switching to buildpacks, but they are not natively supported by gh-actions. Maybe I consider the full conversion now:

using buildbacks
and publish images to dockerhub
Which then can be referenced in action.yaml (same change function-action-oidc did recently)

pavelzubarev commented 1 year ago

double-check Dockerfile. I think you have many packages left and you are not installing pip packages in a safe manner into your production image

That I need to review. I've tried switching to buildpacks, but they are not natively supported by gh-actions. Maybe I consider the full conversion now:

I'm not sure I understood what do you mean by natively. We are building plenty of images with buildpacks and GH Actions.

using buildbacks

and publish images to dockerhub

Which then can be referenced in action.yaml (same change function-action-oidc did recently)

It all depends what exactly do you want to achieve here. if your goal is minimal possible image size, then Dockerfile is easier. If your goal is simple-ich way to build the image, buildpacks might be the choice.

spex66 commented 1 year ago

what do you mean by natively

Hi @pavelzubarev I meant running the action.yaml with referencing a Dockerfile (as it is done, since this repo started). But I see the benefit in building and pushing it to dockerhub and then reference it from action.yaml.

As this requires additional effort, I've not prioritized it yet:

this repo uses semantic-versioning, which atm only updates pyproject,toml and __version__ in a file
which needs then to be integrated with the image building (buildpack), publishing to dockerhub and action.yaml

Nothing impossible, just need to find the time for it

spex66 commented 1 year ago

I'm about to close this branch, as work has continued in #75 (started with a full merge from this branch).

The other branch was created for implementing the changes to create images using buildpack and publish images to docker-hub. As this work is now finished and tested, the #75 branch will be merged as v3.0.0 release into main.

spex66 commented 1 year ago

resolved by #81 this branch is fully included into latest v3.0.0 release