Hello *,
So, sometimes you think you are the only one having _that_ software itch
and one day you find out everyone around you is scratching themselves!
Alright :-)
Although I have been registered in the `bootstrappable` list for the best
of two years, it is only thanks to FOSDEM'21 and Janneke's GNU Mes
presentation [1] and the irc logs that gave an understanding on how far the
task has gone (arrived at?). The combined effort of the last few months is
just astonishing, I don't have all the words to give congratulations either
for the past work, as well as about what is coming next!
Ideally, more hands should come on board and inspect the activity and
hopefully contribute. After all, that would be the success of an
auditable/verifiable project.
Said that, I have created on gitlab.com the group & project
https://gitlab.com/bootstrappable, so that it is possible to collate, if so
desired, many different efforts under one single CI/CD roof. Now, that
would be a great resource to educate and engage other folks and facilitate
experimentation on how the pieces fit together. To be clear, any existing
git(hub) repositories do not need to move at all, the only potential action
point is to add a single `.gitlab-ci.yml` file on a given git repository to
start defining a few gitlab pipelines, if there is such interest. If so,
please read on.
By running the pipelines also on gitlab, they are better exposed and,
hence, also more trustable. IMHO github is superior for the forking model,
however gitlab wins on the experience of an integrated ci/cd. If you wish
to inspect examples or take ideas from, look at the ci/cd workings of the
`qemu` project at [10], [11], [12].
Now, In case you fall into this: if you begin any build script in bash with
`set -ex` (or any equivalent method) it should be relatively trivial to
convert them to a gitlab ci/cd process - that is the part in which I may
help with. Ideally the script names and structure should follow a
descriptive and shortable naming pattern alike:
`Phase_0__Rebuild_hex0_from_the_hex0_seed.sh` - naming is shamelessly taken
from https://github.com/oriansj/stage0-posix#how-does-this-process-work -
ty @oriansj btw! Next would be to find how to best define the pipeline
stages and make visually digestible the deep build graph within gitlab:
https://github.com/oriansj/talk-notes/blob/master/live-bootstrap.pdf
There should be no worries about getting it perfect the first time: as
always, these are iterative improvement processes... as
https://github.com/fosslinux/live-bootstrap/blob/master/parts.rst has been
and still keeps going strong ;-)
Let me know what you think or, this stays on the sideline, for a more
opportune moment.
cheers,
Fotis
P.S.
My interest is somewhat on the periphery of this community's current
activity, since my primary interest/itch is bootstrapping systems via OISC
(One Instruction Set Computer) environments, especially some particular
variants of the type `subtract-and-branch-if-negative` SBN4 [2], as well as
-at the extreme other end- providing complex builds for HPC environments
with full reproducibility from source: as you can see in the diagram in [3]
within the EasyBuild community we are familiar with highly complex and deep
build graphs [4]. Also and for related reasons, I have been looking at
injecting compilers in EasyBuild such as {P,SD,T}CC since quite a while
[5], having in mind exactly that: bootstrapping scenaria.
[1] https://fosdem.org/2021/schedule/event/gnumes/
[2] https://esolangs.org/wiki/OISC
[3]
https://hpcbios.readthedocs.io/en/latest/HPCBIOS_2012-92.html#example-build-tree-of-wrf-wps-along-with-gcc-openmpi-dependency-libraries
[4]
https://docs.easybuild.io/en/latest/Typical_workflow_example_with_WRF.html
[5] https://github.com/easybuilders/easybuild-easyconfigs/pull/486/files
[10] https://gitlab.com/qemu-project/qemu/-/pipelines
[11] https://gitlab.com/qemu-project/qemu/-/pipelines/279463140/dag
[12] https://wiki.qemu.org/Testing/CI/Integrated#GitLab_CI_setup
