Highlight recent git tags (e.g. "8.0-preview-2" and "v0.5.5.9") in /usr/bin/iiab-summary, iiab-diagnostics etc [and remote URLs, branch names, PR count / commit count since tag...]

[holta]

Uses git describe --tags --abbrev=0 to record "most recent" Git tag(s) like "8.0-preview-2" and "v0.5.5.9" to various places — e.g. /etc/iiab/iiab.ini and iiab-diagnostics pastebin.

Ref:

• Enhancement: Adopt better tagging procedures #3266

[tim-moody]

is repo anywhere? repo, branch, tag, commit is a pretty strong identifier. git remote -v | grep '(fetch)' (extra marks for awking off the (fetch) part)

[holta]

is repo anywhere?

Yes. Both remotes are near the top of iiab-diagnostics output, and also /usr/bin/iiab-summary output, e.g. here is sample RPi output:

root@box:~# iiab-summary
install_date = 2022-05-19T17:08:39Z   Current TZ: EDT

iiab: ceea8fb3, 10 PR's / 31 commits since tag 8.0-preview-1
    "Merge pull request #3223 from holta/ubuntu-2210"
    https://github.com/iiab/iiab   branch: master

iiab-admin-console: 611c8c7, 28 PR's / 84 commits since tag v0.5.5.9
    "Merge pull request #488 from tim-moody/0.5.9.0-misc"
    https://github.com/iiab/iiab-admin-console   branch: master

Raspberry Pi reference 2022-04-04
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 27a8050c3c06e567c794620394a8c2d74262a516, stage2
/etc/debian-version: 11.3
display-manager? inactive   Arch1: arm64   Arch2: armhf
5.15.32-v8+ #1538 SMP PREEMPT Thu Mar 31 19:40:39 BST 2022 unknown
Cortex-A72   CPU(s): 4   Mem: 1849 Swap: 1023
Raspberry Pi 4 Model B Rev 1.4
Temperature(s): 52582

Filesystem      Size  Used Avail Use% Mounted on
/dev/root        59G  3.6G   54G   7% /      ZIMs: 0 OER2Go: 0 Apps2B: 0

lo eth0 wlan0 ap0 br0 tun0
openvpn_enabled: True
openvpn_handle: 181-raspios64-lite-UNITTEST-country
192.168.0.181 172.18.96.1 10.8.0.46

[holta]

Here is sample /usr/bin/iiab-summary output on Ubuntu:

install_date = 2022-06-23T14:37:35Z   Current TZ: EDT

iiab: 93709b75, 9 PR's / 40 commits since tag 8.0-preview-2
    "iiab-diagnostics: Include iiab-apps-to-be-installed output"
    https://github.com/holta/iiab   branch: recent-git-tag

iiab-admin-console: c6c6b9d, 43 PR's / 123 commits since tag v0.5.5.9
    "Merge pull request #505 from tim-moody/0.6.0.4-enh2"
    https://github.com/iiab/iiab-admin-console   branch: master

Ubuntu 22.04 LTS   bookworm/sid
display-manager? inactive   Arch1: amd64   Arch2:
5.15.0-40-generic #43-Ubuntu SMP Wed Jun 15 12:54:21 UTC 2022 x86_64
Intel(R) Core(TM) i5-8279U CPU @ 2.40GHz   CPU(s): 2   Mem: 1972 Swap: 0

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        25G  5.8G   19G  24% /      ZIMs: 1 OER2Go: 0 Apps2B: 2

lo enp5s0 enp6s0 tun0
openvpn_enabled: True
openvpn_handle: 160-u22-srv-MEDIUM-PR3262
10.88.67.121 192.168.0.160 10.8.0.34 fd42:1b85:d309:64f4:5054:ff:fe1b:78a1

[holta]

iiab-diagnostics (and other community tools) should benefit from — and co-evolve with — several aspects of the very concise /usr/bin/iiab-summary going forward.

[jvonau]

Given iiab-apps-to-be-installed is now a subset of iiab-diagnostics would it be better to install these new files at the same time as iiab-diagnostics? Plays nicer with a git pull without needing to repeat 1-prep given the future code churn going forward.

[holta]

Given iiab-apps-to-be-installed is now a subset of iiab-diagnostics would it be better to install these new files at the same time as iiab-diagnostics? Plays nicer with a git pull without needing to repeat 1-prep given the future code churn going forward.

I thought about that. Definitely a good idea to ponder but also needs some thinking, as we strive to make Stage 0 (roles/0-init) as lightweight + quick as possible.

Using var first_run and things like 0-init/tasks/create_iiab_ini.yml is one option, but those create other nasty problems. Definitely needs some thought.

[jvonau]

Do I really have to file a bug about git pull updating iiab-diagnostics then recording the below after an ansible run?

=IIAB==========================================================================
COMMAND: /usr/bin/grep "^openvpn_" /etc/iiab/local_vars.yml

openvpn_install: True
openvpn_enabled: True
openvpn_handle: jv-libraryimg

=IIAB==========================================================================
COMMAND:     # IIAB Apps to be installed

COMMAND NOT FOUND: iiab-apps-to-be-installed

1. FILES SPECIALLY REQUESTED (FROM "iiab-diagnostics PATH/FILE1 PATH/FILE2")

I thought about that. Definitely a good idea to ponder but also needs some thinking, as we strive to make Stage 0 (roles/0-init) as lightweight + quick as possible.

Should of thought about that harder when 21f0857 was pushed. I'd rather see a symlink used as /usr/bin/filename pointing to /opt/iiab/iiab/scripts/filename. Still would need a pass though ansible once to put the symlinks in place but a pass though ansible would not be required when the scripts are updated later with a git pull as the symlink are always pointing at the git's current code.

Could just use the full path /opt/iiab/iiab/scripts/iiab-apps-to-be-installed within iiab-diagnostics as an in between compromise.

[holta]

COMMAND NOT FOUND: iiab-apps-to-be-installed

Yes, this is fully expected: iiab-diagnostics is designed to be resilient — when calling fragile commands that fail in all sorts of ways (within cat_cmd).

Could just use the full path /opt/iiab/iiab/scripts/iiab-apps-to-be-installed within iiab-diagnostics as an in between compromise.

It's an option.

In the end I'm hoping roles/0-init can be sped up this year, very dramatically if possible.

To speed up common testing paths and make them much more understandable.

No doubt there are different ways to make these things happen — so long as it happens, this year hopefully (even if none of our short-term options are beautiful, no doubt ;)

[jvonau]

Could just use the full path /opt/iiab/iiab/scripts/iiab-apps-to-be-installed within iiab-diagnostics as an in between compromise.

It's an option.

In the end I'm hoping roles/0-init can be sped up this year, very dramatically if possible.

Perhaps some elements of #2961 might be useful

To speed up common testing paths and make them much more understandable.

note check-vars utility, with iiab-from-console.yml falling out of favor think a move to a 'pre-check' within iiab-install away from 0-init would cut the runtime within admin-console. Given admin-console wrote out any changes if needed I'd be comfortable with assuming they are correct and not waste the time to validate.

No doubt there are different ways to make these things happen — so long as it happens, this year hopefully (even if none of our short-term options are beautiful, no doubt ;)

Food for thought.

[holta]

Good ideas.

My quick profiling of roles/0-init earlier today showed validate_vars.yml generally completes in under 5 seconds, and is very much worth it — but as you suggest such things can be outsourced to bash/Python/C/whatever for further speed-ups in future if people find that necessary.

[jvonau]

Those same 5 seconds are wasted given runrole deals with a single role as the validation is covering every role, that is one of the gains with moving validate to it's own role in 2961