Skip to content
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

FEATURE: add tool functions for logging to bump.sh #67

Merged
merged 8 commits into from
Mar 8, 2023

Conversation

amtoine
Copy link
Member

@amtoine amtoine commented Dec 23, 2022

This PR

  • adds the log_* tool functions to wrap the echo "[.] ..." in an easier to modify framework
  • replaces all the previous hardcoded echo "[.] ..." by their appropriate log_* "..." counterpart

things to pay attention to

given the content of the various [.] in the script, i've come up with the following transition table

token tool function color code color
! log_error 31 red
i log_ok 32 green
~ log_warning 33 yellow
? log_hint 34 blue
+ log_info 35 magenta
- log_normal 36 cyan

👉 i'm not sure about the exact names and the colors...

🙏 please tell me if any of them should change!!

The following `nushell` little script have been used to replace them
automatically
```bash
let file = "scripts/bump.sh"
[
  [token tool];
  ["\\+" info]
  [~     warning]
  [!     error]
  [i     ok]
  [-     normal]
  ["\\?" hint]
]
| each {|it|
  # replace "echo '[.] " or 'echo "[.] ' by the right log function
  sd $"echo \('|\"\)\\[($it.token)\\] " $"log_($it.tool) $1" $file
}
```

One can see that all the `echo`s have been replaced by looking at
```bash
> rg "echo .\\[.\\]" scripts/bump.sh
```
before and after the replacement above.
@amtoine amtoine requested review from atxr and ctmbl December 23, 2022 14:48
@ctmbl ctmbl added the Priority: Low The Issue will be address only if other tasks are done label Jan 6, 2023
Copy link
Contributor

@ctmbl ctmbl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

two slight issues to solve 😋

About the names/colors I would suggest:
log_ok --> log_info
log_info --> log_ok
[-] is the real error I think 🤔 I just wrongly use [!] once or twice, could you replace every [!] (currently log_error) by [-] and rename log_normal --> log_error (using red then)

don't think it's crystal clear sorry about that!

scripts/bump.sh Outdated Show resolved Hide resolved
This commits helps mitigate the following error
```bash
> ./scripts/bump.sh
./scripts/bump.sh: line 159: syntax error: unexpected end of file
```

The `bash` interpreter needs a ";" at the end of the lines inside
a oneline `{ ... }` block, just as in the `log_*` functions.

Otherwise, the parser does not know where the line ends, throwing
the error above.
This commit helps mitigate the following error
```bash
> DRY_RUN="yes" ./scripts/bump.sh
[i] Current
[-] Exactly
[?] Example:
[?] see
```
i.e. the `log_*` functions only print the first word they are being
given...
This is because of the `log_any ... $1`, as `log_any` takes the `$3` only
and not everything after the fourth argument.

Writing `log_any ... "$1"` makes sure the `$3` argument is made of all the
message and not the first word only!!

With this commit, the output of the same command as above is now
```bash
> DRY_RUN="yes" ./scripts/bump.sh
[i] Current directory is repo's root OK
[-] Exactly one argument is needed, got 0.
[?] Example: `./bump.sh 0.2.6`
[?] see https://github.com/iScsc/iscsc.fr/wiki/Version-bump-procedure#automatic-version-bump for full documentation
```
@amtoine
Copy link
Member Author

amtoine commented Jan 7, 2023

About the names/colors I would suggest: log_ok --> log_info log_info --> log_ok [-] is the real error I think thinking I just wrongly use [!] once or twice, could you replace every [!] (currently log_error) by [-] and rename log_normal --> log_error (using red then)

don't think it's crystal clear sorry about that!

i'm not 100% sure, but tell me if what i've tried below is fine 😋

see cc054bb^..2d337af
composed of cc054bb and 2d337af

if that's what you meant, i'll push these two commits on the PR branch 😉

@ctmbl
Copy link
Contributor

ctmbl commented Jan 16, 2023

if that's what you meant, i'll push these two commits on the PR branch

Actually almost!
I'd just invert the colors of log_info and log_ok (to have [i]==info in purple and [+]==ok in green) but yours seems fine too.

This change comes from the comment of @ctmbl in iScsc#67.
@amtoine
Copy link
Member Author

amtoine commented Jan 19, 2023

Actually almost! I'd just invert the colors of log_info and log_ok (to have [i]==info in purple and [+]==ok in green) but yours seems fine too.

like this? 😏

see 83f045d

@ctmbl
Copy link
Contributor

ctmbl commented Feb 23, 2023

@amtoine looks perfect!
I understand your workflow of pushing these changes on a test/* branch until you know they are validated but it can be a little confusing while testing (fetching the PR branch isn't enough I have to remember to fetch the amtoine test/* branch).
A PR branch is a already a construction branch, no worries if you sometime have to revert commits or override some previous changes (like in this case), could you avoid doing this for the future review? 😕

Apart from this I think your PR is ready to be merged 😉

@amtoine
Copy link
Member Author

amtoine commented Feb 23, 2023

I understand your workflow of pushing these changes on a test/* branch until you know they are validated but it can be a little confusing while testing (fetching the PR branch isn't enough I have to remember to fetch the amtoine test/* branch). A PR branch is a already a construction branch, no worries if you sometime have to revert commits or override some previous changes (like in this case), could you avoid doing this for the future review? confused

got it 👌
i sometimes branch early and often, feel free to not fetch these branches and ask me to push on the PR branch directly 😉

Apart from this I think your PR is ready to be merged wink

great 💪
@atxr? 😋

@atxr
Copy link
Contributor

atxr commented Feb 25, 2023

I understand your workflow of pushing these changes on a test/* branch until you know they are validated but it can be a little confusing while testing (fetching the PR branch isn't enough I have to remember to fetch the amtoine test/* branch). A PR branch is a already a construction branch, no worries if you sometime have to revert commits or override some previous changes (like in this case), could you avoid doing this for the future review? confused

got it 👌
i sometimes branch early and often, feel free to not fetch these branches and ask me to push on the PR branch directly 😉

Apart from this I think your PR is ready to be merged wink

great 💪
@atxr? 😋

I'll check within the week!

atxr
atxr previously approved these changes Mar 3, 2023
Copy link
Contributor

@atxr atxr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay!
I totally approve this update!

@ctmbl
Copy link
Contributor

ctmbl commented Mar 3, 2023

@amtoine I think the chnages we discussed are still on your test/* branch, could you rebase them onto this PR branch? 😋

@amtoine
Copy link
Member Author

amtoine commented Mar 3, 2023

@amtoine I think the chnages we discussed are still on your test/* branch, could you rebase them onto this PR branch? yum

woooopsie, yep 👀

@amtoine
Copy link
Member Author

amtoine commented Mar 3, 2023

@ctmbl @atxr
that should do it, sorry for the back-and-forth 😬

Copy link
Contributor

@ctmbl ctmbl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great improvement tks a lot!

@ctmbl ctmbl merged commit 014ee56 into iScsc:main Mar 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority: Low The Issue will be address only if other tasks are done
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

3 participants