-
Notifications
You must be signed in to change notification settings - Fork 160
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
Improve build script of examples #214
Conversation
Since its name is build_image.sh, so I don't think it is good idea to intruduce push function. You can see push_image.sh, or add another script named |
OK, I have removed the |
EXAMPLE_REPO_PREFIX=${IMAGE_REPO}/sedna-example- | ||
|
||
dockerfiles=( | ||
dockerfiles_federated_learning=( |
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.
Actually it can be improved by:
- remove explict Dockerfiles here, using like
ls *.Dockerfile
, and then match by the subdirectories - Or move these Dockerfiles into their subdirectories
It can mitigate these explict Dockerfiles.
But because these dockerfiles are probably stable, it's optional, you can adopt if you want.
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.
We could maybe apply this change later. It depends on the example
folder structure and if we change it we might lose backward compatibility.
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.
@vcozzolino there are two examples of federated learning. If the user only want to use the one, the other shouldn't be mirrored.
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 think this is more of a problem with the folder structure rather than the script. As @llhuii suggested, we use the directories name to build the associated Dockerfiles. If we want to do more specific pattern matching, we have a few options:
- Create two different directories for the two examples of federated learning such as
federated_learning_mistnet
andfederated_learning_surface
. It's anyway something you do in the nested directories. It's just a matter of moving up the splitting in the directory tree. This probably requires extra work to check that all dependencies and Dockerfiles are correctly updated. - Move Dockerfiles into the subfolders. This breaks backward compatibility because the Dockerfiles use relative imports, so we will also have to change the content of each Dockerfile itself.
- Use Dockerfiles names to do the matching in the script rather than folder names. However, this might introduce ambiguity in the decision of which Dockerfiles to build.
Do you have suggestions?
Maybe option 3 is the least invasive.
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.
option 2 is higher cohesion, lower coupling. we can do it in future.
But for now the feature level is enough I think.
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.
Sounds good. So I guess we can go ahead with the current changes and plan for extra improvements in the future.
lgtm. |
7443521
to
12c18e5
Compare
All done. |
/lgtm |
/lgtm cancel |
Signed-off-by: Vittorio Cozzolino <vittorio.cozzolino@huawei.com>
0af6902
to
64f93a9
Compare
/lgtm |
/cc @JimmyYang20 take a look |
@llhuii: GitHub didn't allow me to request PR reviews from the following users: take, a, look. Note that only kubeedge members and repo collaborators can review this PR, and authors cannot review their own PRs. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: llhuii The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This new version of the example build script allows to selective build a type of example rather than all the Docker images. Moreover, it automatically pushes to a target repository.