make divest functions error aware #206

steadfasterX · 2023-04-14T09:27:28Z

this commit adds (the currently non-existing) error handling when using divest's functions and scripts.
all the magic here gets activated when source ../../Scripts/init.sh gets executed which is already a mandatory step before starting any of the divest functions.

when something fails during patching, resetting or building each error will be catched + printed including an error code now. last but not least the executed file and the line number causing that failure will be shown, too.

as all divest functions get source'd and so not a single build script gets executed all ERR's needs to be trapped to catch issues. I am not aware of another way to handle that properly as sourcing means we cannot track a script or smth while this approach here just works.

Example for an error thrown in a function call:

ERROR: $DOS_WORKSPACE_ROOT/Scripts/Common/Functions.sh -> verifyAllPlatformTags() ended with status >1< at line >49<

Final SUCCESS result message after using patchWorkspace:

[FINAL RESULT] No error detected (please check the above output nevertheless!)

Final ERROR result message after using patchWorkspace:

[FINAL RESULT] Serious error(s) found!!!
Summary error code was: 126. Check & fix all error lines above

Some notes:

when an error occurs the process continues until the end (like it is now) i.e. an error will not stop the current and following tasks
when multiple errors occur the exit codes will be summed
buildDevice: a (summed) end result gets printed (SUCCESS or ERROR) at the very end
the trap used to catch any error will also be active for any command executed on the cli. that means: type "false" -> ENTER and you will get an error, too same for any script exectued after source init.sh
when all goes well the trap will be resetted at the end but there are cases where this might not happen -> that is why resetEnv can be executed to reset the trap, i.e. all becomes as it was before sourcing init.sh
resetEnv gets called automatically:
- after a successful patchWorkspace run
- whenever CTRL+C is used (during a running task or just on the cli)
- a process get killed (SIGHUP, TERM)
the whole implementation might not catch all errors though - it highly depends on how the function or the script/program called actually handles errors or better said: if they return a proper exit code on failures. For example some tools (like some git cmds) might print an error but don't return a non-zero exit code. This cannot be tracked other then with your eyes or these must be replaced by other methods returning a non-zero exit code on failures.

SkewedZeppelin · 2023-04-14T18:46:30Z

I'll need to play around with this, but looks good!

steadfasterX · 2023-06-01T08:50:57Z

I'll need to play around with this, but looks good!

do you had some time playing with it ;) @SkewedZeppelin ?

this one will break the build when using Divested-Mobile#206 : > rename: /ssd/tmp/dos/hotdog/LineageOS-20.0/release_keys//incrementals/xxxx-20.0-20230713-dos-hotdog-incremental_*.zip*: not accessible: No such file or directory the next one is a cosmetic thing only. while the current implementation does not break the build I prefer skipping it if not needed at all instead of just the `|| true` workaround. "fixes" the message in build output when no delta is requested: > cp: cannot stat 'xxxx-20.0-20230713-dos-hotdog-incremental_*.zip*': No such file or directory Signed-off-by: steadfasterX <steadfasterX@users.noreply.github.com>

this one will break the build when using #206 : > rename: /ssd/tmp/dos/hotdog/LineageOS-20.0/release_keys//incrementals/xxxx-20.0-20230713-dos-hotdog-incremental_*.zip*: not accessible: No such file or directory the next one is a cosmetic thing only. while the current implementation does not break the build I prefer skipping it if not needed at all instead of just the `|| true` workaround. "fixes" the message in build output when no delta is requested: > cp: cannot stat 'xxxx-20.0-20230713-dos-hotdog-incremental_*.zip*': No such file or directory Signed-off-by: steadfasterX <steadfasterX@users.noreply.github.com>

this commit adds (the currently non-existing) error handling when using divest's functions and scripts. all the magic here gets activated when `source ../../Scripts/init.sh` gets executed which is already a mandatory step before starting any of the divest functions. when something fails during patching, resetting or building each error will be catched + printed including an error code now. last but not least the executed file and the line number causing that failure will be shown, too. as all divest functions get source'd and so not a single build script gets executed all ERR's needs to be trapped to catch issues. I am not aware of another way to handle that properly as sourcing means we cannot track a script or smth while this approach here just works. Example for an error thrown in a function call: > ERROR: $DOS_WORKSPACE_ROOT/Scripts/Common/Functions.sh -> verifyAllPlatformTags() ended with status >1< at line >49< Final SUCCESS result message after using `patchWorkspace`: > [FINAL RESULT] No error detected (please check the above output nevertheless!) Final ERROR result message after using `patchWorkspace`: > [FINAL RESULT] Serious error(s) found!!! > Summary error code was: 126. Check & fix all error lines above Some notes: - when an error occurs the process continues until the end (like it is now) i.e. an error will not stop the current and following tasks - when multiple errors occur the exit codes will be summed - buildDevice: a (summed) end result gets printed (SUCCESS or ERROR) at the very end - the trap used to catch any error will also be active for any command executed on the cli. that means: type "false" -> ENTER and you will get an error, too same for any script exectued after source init.sh - when all goes well the trap will be resetted at the end but there are cases where this might not happen -> that is why `resetEnv` can be executed to reset the trap, i.e. all becomes as it was before sourcing init.sh - `resetEnv` gets called automatically: - after a successful `patchWorkspace` run - whenever CTRL+C is used (during a running task or just on the cli) - a process get killed (SIGHUP, TERM) - the whole implementation might not catch all errors though - it highly depends on how the function or the script/program called actually handles errors or better said: if they return a proper exit code on failures. For example some tools (like some git cmds) might print an error but don't return a non-zero exit code. This cannot be tracked other then with your eyes or these must be replaced by other methods returning a non-zero exit code on failures. Signed-off-by: steadfasterX <steadfasterX@gmail.com>

when using strict (i.e set -e added by this PR) a build will fail on release when there is no recovery.img. this makes that non-fatal allowing to proceed Signed-off-by: steadfasterX <steadfasterX@users.noreply.github.com>

new (internal used) functions: - _exit - _exit_report - _exit_sigint these are used to fix several (wrong) error handlings. new environment variable: - UNATTENDED_PATCHING by default we assume unattended patching, i.e. if an error occurs during the patch, reset or any other process we will report the error and auto close the shell. this is needed as we source functions and code and so cannot simply terminate a master process. instead the whole shell will be terminated so if an error occurs nothing else will be executed (and you should notice easily that something is wrong). without that a (serious) error can still continue the rest of a function and you likely not even noticing the error itself. you can use: export UNATTENDED_PATCHING=0 before or after sourcing init.sh and it will *NOT* auto-close the shell. that way you can check the output and fix any issues. Signed-off-by: steadfasterX <steadfasterX@gmail.com>

steadfasterX · 2024-04-22T08:25:23Z

re-based on latest master

steadfasterX force-pushed the feature-become-error-aware branch from a313114 to 59d8f35 Compare April 14, 2023 12:46

SkewedZeppelin added the enhancement New feature or request label Apr 18, 2023

steadfasterX mentioned this pull request Jul 10, 2023

Unable to patch Lineage 20.0 android_packages_apps_Updater #222

Closed

steadfasterX mentioned this pull request Jul 13, 2023

fix an issue when no delta requested #223

Merged

josegees291614 approved these changes Oct 20, 2023

View reviewed changes

steadfasterX marked this pull request as draft April 12, 2024 11:14

steadfasterX and others added 3 commits April 22, 2024 10:24

common: do not abort when recovery-in-boot

fcec1c8

when using strict (i.e set -e added by this PR) a build will fail on release when there is no recovery.img. this makes that non-fatal allowing to proceed Signed-off-by: steadfasterX <steadfasterX@users.noreply.github.com>

steadfasterX force-pushed the feature-become-error-aware branch from d812305 to 30859d2 Compare April 22, 2024 08:24

steadfasterX marked this pull request as ready for review April 22, 2024 08:25

steadfasterX requested a review from josegees291614 April 22, 2024 11:44

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

make divest functions error aware #206

make divest functions error aware #206

steadfasterX commented Apr 14, 2023 •

edited

SkewedZeppelin commented Apr 14, 2023

steadfasterX commented Jun 1, 2023 •

edited

steadfasterX commented Apr 22, 2024

make divest functions error aware #206

Are you sure you want to change the base?

make divest functions error aware #206

Conversation

steadfasterX commented Apr 14, 2023 • edited

SkewedZeppelin commented Apr 14, 2023

steadfasterX commented Jun 1, 2023 • edited

steadfasterX commented Apr 22, 2024

steadfasterX commented Apr 14, 2023 •

edited

steadfasterX commented Jun 1, 2023 •

edited