Improve build script of examples

[vcozzolino]

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.

[llhuii]

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.

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 build_push_image.sh

[vcozzolino]

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.

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 build_push_image.sh

OK, I have removed the docker push command.

[llhuii]

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.

[vcozzolino]

We could maybe apply this change later. It depends on the example folder structure and if we change it we might lose backward compatibility.

[JimmyYang20]

@vcozzolino there are two examples of federated learning. If the user only want to use the one, the other shouldn't be mirrored.

[vcozzolino]

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:

1. Create two different directories for the two examples of federated learning such as federated_learning_mistnet and federated_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.
2. 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.
3. 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.

[llhuii]

option 2 is higher cohesion, lower coupling. we can do it in future.

But for now the feature level is enough I think.

[vcozzolino]

Sounds good. So I guess we can go ahead with the current changes and plan for extra improvements in the future.

[llhuii]

lgtm.
Some nits comment left. And I think you can squash these commits into one or two commits

[vcozzolino]

lgtm. Some nits comment left. And I think you can squash these commits into one or two commits

All done.

[llhuii]

/lgtm

[llhuii]

/lgtm cancel
a typo is need to be fixed

[llhuii]

/lgtm

[llhuii]

/cc @JimmyYang20 take a look

[kubeedge-bot]

@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:

/cc @JimmyYang20 take a look

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.

[llhuii]

/approve

[kubeedge-bot]

[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:

• examples/OWNERS [llhuii]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment