The management of the container is currently not optimized due the fact that the logic is part of the sub-functions.
For instance start_container() calls create_container() when it should only start the container.
|
start_container() { |
|
secbox_container_exists || { |
|
# If the container does not exist, create it |
|
print_logo |
|
msg "${orange}[*]${no_format} ${container} container not found" |
|
create_container || { |
|
msg "${red}[!]${no_format} Cannot create the ${container} container" |
|
return 1 |
|
} |
|
msg "${green}[.] ${no_format}${container} container created\n" |
|
} |
This generates confusion when other functions calls start_container() and then create_container(), like in update_image():
|
update_image() { |
|
local _upstream=$(upstream_image_version) |
|
read -ep "[.] An update is available, do you want to update the container now? [Y/n] " -n 1 -r |
|
msg "Changelog: https://gitlab.suse.de/security/secbox-image/-/tags/v${_upstream}" |
|
if [[ ! $REPLY =~ ^[Nn]$ ]]; then |
|
if pull_image; then |
|
if secbox_container_exists; then |
|
if secbox_destroy -f -i; then |
|
if create_container; then |
|
start_container |
|
return 0 |
Functions need to be rewritten following the UNIX philosophy (or a KISS approach).
The management of the container is currently not optimized due the fact that the logic is part of the sub-functions.
For instance
start_container()callscreate_container()when it should only start the container.secbox/secbox
Lines 534 to 544 in eeb5124
This generates confusion when other functions calls
start_container()and thencreate_container(), like inupdate_image():secbox/secbox
Lines 586 to 596 in eeb5124
Functions need to be rewritten following the UNIX philosophy (or a KISS approach).