Description
Travis provides nice integration with GitHub, it can automatically run tests for every commit or every pull request.
It is already used in e.g. registration module, see the build result.
Unfortunately the current support is quite limited, the problem is that Yast packages are not available at Travis builders. The workaround is to mock used Yast calls (that leads to overmocking) and reimplementing some Yast core functions. Another solution is to test only the functionality which does not rely on Yast much, but that means the code coverage will be rather small...
Provide Yast packages for Ubuntu
Travis allows to install additional packages (see the doc), but the builders are running Ubuntu and we do not have Yast packages for Ubuntu...
The solution is to repackage Yast packages to deb
packages for Ubuntu in YaST:Head:Travis OBS project.
Notes
We do not need to package all Yast modules, just the base packages like
yast2-core
,yast2
,yast2-ruby-bindings
and the dependent packages, the leaf packages do not need to packaged.It's really about repackaging, the Yast packages will very likely not work in Ubuntu out of box (because of different config files, package names, file locations, services, different system defaults, different package management...). But that should not matter as the system access will be stubbed/mocked in the tests anyway, for running tests the real functionality is not needed, we just need that the files can compiled and loaded.
Current Status
I have already started the project at the CSM department workshop last month. What has been done:
YaST:Head:Travis OBS project set up
Some modules already have
.travis.yml
file added and Travis builds are enabled inTravis
branchThere is the overview of already converted modules is available
The Goal
- Enable Travis builds for all currently maintained Yast packages (in Git master branch)
- As a side effect we could attract some Debian/Ubuntu developers to help us with the Yast port and this could help us to broaden the community around Yast.
The Future
- The support could be enhanced to other Git branches, for example SLE12-GA branch could be used for testing SLE12 maintenace updates.
- The tests run at Travis can be enhanced to report test code coverage using coveralls
Links
- http://docs.travis-ci.com/user/installing-dependencies/
- http://en.opensuse.org/openSUSE:BuildServiceDebian_builds
- https://wiki.debian.org/HowToPackageForDebian
- https://www.debian.org/doc/manuals/maint-guide/dreq.en.html
This project is part of:
Hack Week 11
Activity
Comments
-
about 10 years ago by lslezak | Reply
The Result
I have managed to enable Travis support to all Yast modules, which I consider a big success!
See the details in this document.
This should improve testing automation for all Yast modules and we should be more confident when doing changes in Yast as basically every commit to Git
master
will be automatically tested.
Similar Projects
Update Haskell ecosystem in Tumbleweed to GHC-9.10.x by psimons
Description
We are currently at GHC-9.8.x, which a bit old. So I'd like to take a shot at the latest version of the compiler, GHC-9.10.x. This is gonna be interesting because the new version requires major updates to all kinds of libraries and base packages, which typically means patching lots of packages to make them build again.
Goals
Have working builds of GHC-9.10.x and the required Haskell packages in 'devel:languages:haskell` so that we can compile:
git-annex
pandoc
xmonad
cabal-install
Resources
- https://build.opensuse.org/project/show/devel:languages:haskell/
- https://github.com/opensuse-haskell/configuration/
- #discuss-haskell
- https://www.twitch.tv/peti343
Framework laptop integration by nkrapp
Project Description
Although openSUSE does run on the Framework laptops out-of-the-box, there is still room to improve the experience. The ultimate goal is to get openSUSE on the list of community supported distros
Goal for this Hackweek
The goal this year is to at least package all of the soft- and firmware for accessories like the embedded controller, Framework 16 inputmodule and other tools. I already made some progress by packaging the inputmodule control software, but the firmware is still missing
Resources
As I only have a Framework laptop 16 and not a 13 I'm looking for people with hardware that can help me test
Progress:
Update 1:
The project lives under my home for now until I can get an independent project on OBS: Framework Laptop project
Also, the first package is already done, it's the cli for the led-matrix spacer module on the Framework Laptop 16. I am also testing this myself, but any feedback or questions are welcome.
You can test the package on the Framework 16 by adding this repo and installing the package inputmodule-control
Update 2:
I finished packaging the python cli/gui for the inputmodule. It is using a bit of a hack because one of the dependencies (PySimpleGUI) recently switched to a noncommercial license so I cannot ship it. But now you can actually play the games on the led-matrix (the rust package doesn't include controls for the games). I'm also working on the Framework system tools now, which should be more interesting for Framework 13 users.
You can test the package on the Framework 16 by installing python311-framework16_inputmodule and then running "ledmatrixctl" from the command line.
Update 3:
I packaged the framework_tool, a general application for interacting with the system. You can find it some detailed information what it can do here. On my system everything related to the embedded controller functionality doesn't work though, so some help testing and debugging would be appreciated.
Update 4:
Today I finished the qmk interface, which gives you a cli (and gui) to configure your Framework 16 keyboard. Sadly the Python gui is broken upstream, but I added the qmk_hid package with the cli and from my testing it works well.
Final Update:
All the interesting programs are now done, I decided to exclude the firmware for now since upstream also recommends using fwupd to update it. I will hack on more things related to the Framework Laptops in the future so if there are any ideas to improve the experience (or any bugs to report) feel free to message me about it.
As a final summary/help for everyone using a Framework Laptop who wants to use this software:
The source code for all packages can be found in repositories in the Framework organization on Github
All software can be installed from this repo (Tumbleweed)
The available packages are:
inputmodule-control (FW16) - play with the inputmodules on your Framework 16 (b1-display, led-matrix, c1-minimal)
python-framework16_inputmodule (FW16) - same as inputmodule-control but is needed if you want to play and crontrol the built-in games in the led-matrix (call with ledmatrixctl or ledmatrixgui)
framework_tool (FW13 and FW 16) - use to see and configure general things on your framework system. Commands using the embedded controller might not work, it looks like there are some problems with the kernel module used by the EC. Fixing this is out of scope for this hackweek but I am working on it
qmk_hid (FW16) - a cli to configure the FW16 qmk keyboard. Sadly the gui for this is broken upstream so only the cli is usable for now
Packaging Mu on OBS by joeyli
Description
Packaging Microsoft Mu project
Goals
Packaging Mu RPM on OBS.
Resources
https://microsoft.github.io/mu/
https://github.com/microsoft/mu
https://github.com/microsoft/mu_basecore
https://github.com/microsoft/mutianoplatforms
https://github.com/microsoft/mutianoplus
https://github.com/microsoft/mu_plus
Hackweek 22: Look at Microsoft Mu project
https://hackweek.opensuse.org/22/projects/look-at-microsoft-mu-project
https://drive.google.com/file/d/1BT31i7z3qh13adj9pdRz3lTUkqIsXvjY/view?usp=drive_link
Testing and adding GNU/Linux distributions on Uyuni by juliogonzalezgil
Join the Gitter channel! https://gitter.im/uyuni-project/hackweek
Uyuni is a configuration and infrastructure management tool that saves you time and headaches when you have to manage and update tens, hundreds or even thousands of machines. It also manages configuration, can run audits, build image containers, monitor and much more!
Currently there are a few distributions that are completely untested on Uyuni or SUSE Manager (AFAIK) or just not tested since a long time, and could be interesting knowing how hard would be working with them and, if possible, fix whatever is broken.
For newcomers, the easiest distributions are those based on DEB or RPM packages. Distributions with other package formats are doable, but will require adapting the Python and Java code to be able to sync and analyze such packages (and if salt does not support those packages, it will need changes as well). So if you want a distribution with other packages, make sure you are comfortable handling such changes.
No developer experience? No worries! We had non-developers contributors in the past, and we are ready to help as long as you are willing to learn. If you don't want to code at all, you can also help us preparing the documentation after someone else has the initial code ready, or you could also help with testing :-)
The idea is testing Salt and Salt-ssh clients, but NOT traditional clients, which are deprecated.
To consider that a distribution has basic support, we should cover at least (points 3-6 are to be tested for both salt minions and salt ssh minions):
- Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
- Onboarding (salt minion from UI, salt minion from bootstrap scritp, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator)
- Package management (install, remove, update...)
- Patching
- Applying any basic salt state (including a formula)
- Salt remote commands
- Bonus point: Java part for product identification, and monitoring enablement
- Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
- Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)
- Bonus point: testsuite enablement (https://github.com/uyuni-project/uyuni/tree/master/testsuite)
If something is breaking: we can try to fix it, but the main idea is research how supported it is right now. Beyond that it's up to each project member how much to hack :-)
- If you don't have knowledge about some of the steps: ask the team
- If you still don't know what to do: switch to another distribution and keep testing.
This card is for EVERYONE, not just developers. Seriously! We had people from other teams helping that were not developers, and added support for Debian and new SUSE Linux Enterprise and openSUSE Leap versions :-)
Pending
FUSS
FUSS is a complete GNU/Linux solution (server, client and desktop/standalone) based on Debian for managing an educational network.
https://fuss.bz.it/
Seems to be a Debian 12 derivative, so adding it could be quite easy.
[x]
Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)[P]
Onboarding (salt minion from UI, salt minion from bootstrap scritp, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator) --> Works from UI, need to test the rest.[P]
Package management (install, remove, update...) --> Installing a new package works, needs to test the rest.[ ]
Patching (if patch information is available, could require writing some code to parse it, but IIRC we have support for Ubuntu already)[ ]
Applying any basic salt state (including a formula)[ ]
Salt remote commands[ ]
Bonus point: Java part for product identification, and monitoring enablement
Fix RSpec tests in order to replace the ruby-ldap rubygem in OBS by enavarro_suse
Description
"LDAP mode is not official supported by OBS!". See: config/options.yml.example#L100-L102
However, there is an RSpec file which tests LDAP mode in OBS. These tests use the ruby-ldap
rubygem, mocking the results returned by a LDAP server.
The ruby-ldap
rubygem seems no longer maintaned, and also prevents from updating to a more recent Ruby version. A good alternative is to replace it with the net-ldap
rubygem.
Before replacing the ruby-ldap
rubygem, we should modify the tests so the don't mock the responses of a LDAP server. Instead, we should modify the tests and run them against a real LDAP server.
Goals
Goals of this project:
- Modify the RSpec tests and run them against a real LDAP server
- Replace the
net-ldap
rubygem with theruby-ldap
rubygem
Achieving the above mentioned goals will:
- Permit upgrading OBS from Ruby 3.1 to Ruby 3.2
- Make a step towards officially supporting LDAP in OBS.
Resources
Git CI to automate the creation of product definition by gyribeiro
Description
Automate the creation of product definition
Goals
Create a Git CI that will:
- automatically be triggered once a change (commit) in package list is done.
- run tool responsible to update product definition based on the changes in package list
- test the updated product definition in OBS
- submit a pull request updating the product definition in the repository
NOTE: this Git CI may also be triggered manually
Resources
- https://docs.gitlab.com/ee/ci/
- https://openbuildservice.org/2021/05/31/scm-integration/
- https://github.com/openSUSE/openSUSE-release-tools
Research openqa-trigger-from-obs and openqa-trigger-from-ibs-plugin by qwang
Description
openqa-trigger-from-obs project is a framework that OSD is using it to automatically sync the defined images and repositories from OBS/IBS to its assets for testing. This framework very likely will be used for the synchronize to each location's openqa include openqa.qa2.suse.asia Beijing local procy scc scc-proxy.suse.asia(although it's not a MUST to our testing) it's now rewriting requests to openqa.qa2.suse.asia instead of openqa.suse.de, the assets/repo should be consistent the format Beijing local openQA is maintaining an own script but still need many manually activities when new build comes, and not consistent to OSD, that will request many test code change due to CC network change
Goals
Research this framework in case it will be re-used for Beijing local openQA, and will need to be setup and maintained by ourselves
Resources
https://github.com/os-autoinst/openqa-trigger-from-obs/tree/master https://gitlab.suse.de/openqa/openqa-trigger-from-ibs-plugin
beijing :rainbow machine
Bootstrap openSUSE on LoongArch by glaubitz
Description
LoongArch is a new architecture from China which has its roots in the MIPS architecture. It has been created by Loongson and is already supported by Debian Ports, Gentoo and Loongnix.
Upstream support for LoongArch is already quite complete which includes LLVM, Rust, Golang, GRUB, QEMU, LibreOffice and many more. In Debian Ports, where the port is called "loong64", more than 95% of the whole Debian archive have been successfully built for LoongArch.
QEMU support is rather complete and stable such that packages can be built in emulated environments. Hardware can also be requested by Loongson on request for free. Access to real hardware is also provided through the GCC Compile Farm.
Goals
The initial goal should be to add LoongArch to OBS and build a minimal set of packages.
Resources
- Introduction to LoongArch: https://docs.kernel.org/arch/loongarch/introduction.html
- LoongArch community on Github: https://github.com/loongarchlinux
- Debian Ports repository for loong64: http://ftp.ports.debian.org/debian-ports/pool-loong64/main/
- Gentoo stage3 for loong: https://www.gentoo.org/downloads/#loong