GitHub Actions .github/workflows/30min-iiab-test-install-debian12.yml for CI/CD & QA

[neomatrixcode]

• add .github/workflows/30min-iiab-test-install-debian12.yml
• add a virtual machine for testing Raspberry Pi 3B Arm Cortex-A7 with Debian 12 Testing (Bookworm) from https://raspi.debian.net/daily-images/

[holta]

@neomatrixcode please explain quick why these lines are being commented out?

[neomatrixcode]

I copied the test command from the example, but I don't consider it important. I consider removing that line but I just put it in a comment

[holta]

Would output sometimes be test aarch64 = aarch64 and sometimes (something like!) test x86_64 = x86_64 ?

(If so obvious to gurus — but can we try to make our work more approachable & maintainable for newcomers/others?)

[neomatrixcode]

Would output sometimes be test aarch64 = aarch64 and sometimes (something like!) test x86_64 = x86_64 ?
yes, that's correct, uname -m returns the name of the platform the operating system is running on

[tim-moody]

I agree with @neomatrixcode that test does not serve any purpose here. It is meant to be a conditional, but there is no result of the condition. If you only want to run the remaining commands if the assertion is true wouldn't you use

if [  `uname -m` = ${{ matrix.arch }} ]; then
... rest of commands
fi

[tim-moody]

Also, during these test builds would it be possible to capture the size of the various roles installed and store them back into the repo? This would build a catalog of role sizes to be used by sizing code. Perhaps the size should be rounded up to allow an approximate single value to serve multiple targets.

[holta]

The point is that some of us can benefit (and make our community more approachable) by seeing aarch64 or x86_64 or similar clearly, near the top of the output.

Any command (test or otherwise) can be used to make output clear. Microsoft's docs used the test command traditionally to accomplish this, but there are other ways that work equally well.

[holta]

Also, during these test builds would it be possible to capture the size of the various roles installed and store them back into the repo? This would build a catalog of role sizes to be used by sizing code. Perhaps the size should be rounded up to allow an approximate single value to serve multiple targets.

Just FYI this is already being recorded into /etc/iiab/iiab.ini :

• PR Record approx disk usage for 45 apps / roles (to /etc/iiab/iiab.ini) #3592

[holta]

Just FYI this is already being recorded into /etc/iiab/iiab.ini :

• PR Record approx disk usage for 45 apps / roles (to /etc/iiab/iiab.ini) #3592

If /etc/iiab/iiab.ini and similar critical files should be recorded more visibly at the end of each GitHub Actions build — possibly that's a good idea?

[holta]

Any command (test or otherwise) can be used to make output clear. Microsoft's docs used the test command traditionally to accomplish this, but there are other ways that work equally well.

My guess is that certain people started using the test COMMAND approach as it's shorter and more succinct than things like:

echo $(COMMAND)

(But any such approach accomplishes the job...)

[holta]

My guess is that certain people started using the test COMMAND approach as it's shorter and more succinct than things like:

echo $(COMMAND)

(But any such approach accomplishes the job...)

In this specific case, outputting both:

• `uname -m`
• ${{ matrix.arch }}

Again I understand this is boring to experienced GitHub Actions gurus. But it's useful to others (including me!) However it's done. Whether using the test command to force a failure of the GHA job — or any other/similar way.

[holta]

• add a virtual machine for testing Raspberry Pi 3B Arm Cortex-A7 with Debian 12 Testing (Bookworm) from https://raspi.debian.net/daily-images/

Just FYI IIAB doesn't support "Pure Debian" on Raspberry Pi, as this has been extremely fragile and unpopular to date.

(But for testing purposes, perhaps this adds useful coverage for now? e.g. until more real Raspberry Pi emulation [or actual automated Raspberry Pi testing] hopefully appears some day in future!)

[tim-moody]

using the test command to force a failure of the GHA job

how does that force failure?

[holta]

using the test command to force a failure of the GHA job

how does that force failure?

A red cross appears (instead of a green checkmark) in GitHub Actions output, i.e. when exit code is non-zero.

[tim-moody]

Just FYI this is already being recorded into /etc/iiab/iiab.ini :

and thrown away immediately after the test build GHA

I suggested committing to a file in the repo during the test build, so that it is available to real installs before a role is installed

[tim-moody]

A red cross appears (instead of a green checkmark) in GitHub Actions output, i.e. when exit code is non-zero.

and that halts the remaining commands? If so, then test serves a purpose.

[holta]

and that halts the remaining commands? If so, then test serves a purpose.

Exactly.

And many people also use the test $(COMMAND) syntax as well, which works fine, but some find this confusing and unpretty.

[holta]

A red cross appears (instead of a green checkmark) in GitHub Actions output, i.e. when exit code is non-zero.

and that halts the remaining commands? If so, then test serves a purpose.

On the one hand this sounds useful, so I'm sympathetic.

On the other what value does it really add with local_vars_none.yml which isn't really installing any major apps?

[tim-moody]

agree that it has no value for none

[holta]

agree that it has no value for none

Your idea is excellent in my opinion, to publish estimated app sizes routinely, e.g. if we later run LARGE-sized (or MAX-sized probably better) via GitHub Actions.

As these sizes will evolve over time — and keeping these records can be useful even if just for diagnostic purposes initially.

[neomatrixcode]

I think that capturing the size of the various installed roles could be done in a dedicated github actions, if that calculation is useful for it to be automatic.

Regarding uname -m, I think that since it is for informational purposes, the echo $(COMMAND) could be used to show the platform used in the output of the github action

[holta]

I think that capturing the size of the various installed roles could be done in a dedicated github actions, if that calculation is useful for it to be automatic.

👍

Regarding uname -m, I think that since it is for informational purposes, the echo $(COMMAND) could be used to show the platform used in the output of the github action

Personally I'd favor auto-documenting both with something like...

echo $(uname -m) ${{ matrix.arch }}

...so that we have diagnostic info next time Microsoft (or we) changes architectures etc.

[holta]

Regarding ${{ matrix.arch }} Microsoft's documentation lists values that are no longer accurate:

https://docs.github.com/en/actions/learn-github-actions/contexts#runner-context

Given that even Microsoft can't keep up with its own changing decisions, it definitely wouldn't hurt to output all ~5 of these "runner context" values going forward, e.g. the example they give is:

{
  "os": "Linux",
  "arch": "X64",
  "name": "GitHub Actions 2",
  "tool_cache": "/opt/hostedtoolcache",
  "temp": "/home/runner/work/_temp"
}

[holta]

output all ~5 of these "runner context" values

Certainly if "runner context" can be made a bit more visible in the output?

(Understanding that some workflows hard-code "runner context" in places like...)

https://github.com/neomatrixcode/iiab/blob/03531dfdecf4025304ba6241e354799756b19727/.github/workflows/30min-iiab-test-install-debian12.yml#L23-L30

[neomatrixcode]

In this specific case "arch" refers to the value of the variable - arch: debian12, which is provided by the user.
https://github.com/neomatrixcode/iiab/blob/03531dfdecf4025304ba6241e354799756b19727/.github/workflows/30min-iiab-test-install-debian12.yml#LL26C9-L26C25

[holta]

hostnamectl output is really great! Example:

ubuntu@box:~$ hostnamectl
 Static hostname: box
       Icon name: computer-vm
         Chassis: vm 🖴
      Machine ID: ebf4eac43e1446b6bb428bc4bb99fe94
         Boot ID: 72ee24c7783f40d6a3cf67f8208c5fcd
  Virtualization: kvm
Operating System: Ubuntu Mantic Minotaur (development branch)
          Kernel: Linux 6.2.0-21-generic
    Architecture: x86-64
 Hardware Vendor: QEMU
  Hardware Model: Standard PC _Q35 + ICH9, 2009_
Firmware Version: 0.0.0

ubuntu@box:~$ uname -m
x86_64

All 3 values can be slightly different, and as such should be recorded in the output (no need to check the source code, zero bureaucracy for newcomers or maintainers a year later).

Interestingly #test `uname -m` = ${{ matrix.arch }} from ~14h ago was actually doing (half!) of this job — thankfully instantiated even despite being part of a comment: