Hi,
I found a quite interesting tool called Overcommit [1].
It provides an easy way for setting up Git commit hooks and provides
some basic checking plugins.
The nice feature of the Git commit hooks is that you can run some checks
automatically and early in the development. For example with the commit hooks you can
run Rubocop check automatically whenever a commit is created. And if the check fails
the commit is not created.
I can see "make Rubocop happy" commits quite often (happens to me as well),
with Overcommit you can easily avoid that.
I have tried several Overcommit checks:
- Rubocop - runs Rubocop at "commit"
- Rspec - runs the tests before "push"
- Branch blacklist - can forbid direct commits to configured branches,
e.g. "master" (forces using pull requests, avoids commits to master my mistake)
- Commit message spellcheck - warns when there is a possible typo
Check my blog post [2] for the details, esp. watch the recorded screencast where
I wanted to show some mistakes which it can catch.
The tool looks promising, I'll try using it for some time. If you want to try it
as well check the blog post for the installation steps.
Enjoy!
[1] https://github.com/brigade/overcommit
[2] http://blog.ladslezak.cz/2016/06/06/overcommit/
--
Ladislav Slezák
Appliance department / YaST Developer
Lihovarská 1060/12
190 00 Prague 9 / Czech Republic
tel: +420 284 028 960
lslezak(a)suse.com
SUSE
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hello,
recently I fixed a small bug in cockpit [1]. The fix is rather trivial but it was
quite difficult to test it and verify that it really fixes the problem.
ALP Prerequisites
=================
1. Install ALP from https://download.opensuse.org/repositories/SUSE:/ALP/images/,
see the previous mails about the installation and configuration
2. Install cockpit with "transactional-update pkg install cockpit",
then reboot the system
(the backend packages are already preinstalled in the ALP image, this will
install the web frontend)
3. Start the cockpit service: "systemctl enable --now cockpit.socket"
Now you will have the standard cockpit installed and ready to run, you might
test it by connecting to https://localhost:9090
Development
===========
Note: I needed to patch a cockpit plugin which is basically a JS code + HTML + CSS.
If you would need to patch the cockpit core (the C code) it would be more
difficult, see the suggestion in the end.
I did the development directly on my workstation (Leap 15.4), the ALP instance was
running in a VM.
Development Prerequisites
-------------------------
For patching a cockpit plugin you should not need much libraries installed, but the
the Makefile (generated by autotools) requires the libraries also for the C part.
On my workstation I had to additionally install these packages:
zypper install json-glib-devel krb5-devel sassc nodejs16
You might actually need some more libraries or tools (autotools), I use my
workstation as a development machine and it already contains a lot of libraries.
Check that nodejs and npm default versions are 16, esp. if you have multiple versions
installed. Originally I probably did something wrong and got some strange failures...
Then you can checkout the sources from GitHub
git clone git@github.com:cockpit-project/cockpit.git
and checkout the version used in ALP
cd cockpit
git checkout -b 276
Check https://build.opensuse.org/package/show/SUSE:ALP/cockpit, it might change in
the future.
To build the sources use:
# this installs the npm packages using "npm install"
./autogen.sh
# autogen.sh runs configure but it will very likely fail, by default it needs
# some additional libraries, if you want to patch just a plugin then run
./configure --disable-doc --disable-ssh --disable-pcp --disable-polkit
make
Now the compiled plugins are available in ./dist/ subdirectory. Now we need to
transfer these changed file to the ALP system.
There are several possibilities to do this. You can run an "scp" command after each
edit/build or you can use some network file system.
I tested that with sshfs. The disadvantage is that the sshfs packages are not
available for ALP, as a workaround I installed the "sshfs" and "fuse3" packages from
Tumbleweed. That works currently because ALP is based on TW, but that will probably
not work later when ALP is branched from TW. The clean solution would be to provide a
container for that...
To mount a directory over sshfs run
sshfs <user>@<machine>:<path_to_git_checkout> /mnt
Now we need cockpit to load the new files. Fortunately it can load the plugins from
the user's $HOME:
mkdir ~/.local/share/cockpit
link the shared directory from the development machine
ln -s /mnt/dist/networkmanager/ ~/.local/share/cockpit/networkmanager
(You could link the whole /dist/ to override all plugins, but that could possibly
have some side effects, I'd rather just override the updated plugin to be safe.)
Then you can just reload the cockpit page in the web browser and that's it, you do
not need to relogin or restart the cockpit service.
Testing with the "main" branch
==============================
Then I wanted to test my change also with the "main" branch to be sure it can be
properly submitted to upstream.
It turned out that they changed the way how the node modules are loaded. They do not
run "npm install" anymore, but rather use Git submodules for that, the whole
"node_modules" directory is a Git submodule.
The problem is that the submodules are not checked out by default. If you want to
use the "main" branch then do the initial checkout with
git clone --recurse-submodules git@github.com:cockpit-project/cockpit.git
or if you already have a clone without submodules then you can download them with
git submodule update --init
Be careful when switching the branches! When you later switch to an older version you
might need to delete the "node_modules" directory and run ./autogen.sh to install
them via npm otherwise you will end up with different modules and probably get some
nasty errors!
Patching the Core Cockpit
=========================
If you need to patch the C part then you could just run "make" and copy the built
binary to the ALP VM.
The problem is that /usr is read-only in ALP. But you can create a writable overlay
using overlayfs:
mkdir /tmp/upperdir
mkdir /tmp/workdir
mount -t overlay overlay -o
lowerdir=/usr,upperdir=/tmp/upperdir/,workdir=/tmp/workdir/ /usr
Then the /usr will become writable, see more details in
https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt
Now you can easily rewrite or edit the files there
cp /mnt/cockpit-tls /usr/libexec/cockpit-tls
To take effect you need to restart the cockpit service
systemctl restart cockpit
HTH
Ladislav
[1] https://github.com/cockpit-project/cockpit/pull/17776
--
Ladislav Slezák
YaST Developer
SUSE LINUX, s.r.o.
Corso IIa
Křižíkova 148/34
18600 Praha 8
Helping out :)
On Thu, Oct 27, 2022 at 1:33 PM ddemaio <ddemaio(a)suse.de> wrote:
>
> Hi all,
>
> I wanted to bring your attention to an article I just posted about the
> next generation installer. The team is looking to have people test out
> the images. There is a guide to walk you through it should you be
> interested in testing it.
>
> https://news.opensuse.org/2022/10/27/call-for-testing-next-gen-installer/
>
> v/r
> Doug
Hi all,
Reading YaST logs, especially from installation or upgrade might be very
difficult. The log is very long and contains every detail of the YaST run. Even a
default openSUSE Leap 15.4 installation where you basically just press Next, Next,...
produces about a 13MB log file (uncompressed) with more than 80.000 lines!
Navigating in such a log is very difficult, you can see every tiny detail what was
done, but it is hard to see the big picture, why was that happening, what was
the goal.
Also some code parts are repeated during the installation. For example evaluating
the base product is done several times during installation, in the self-update step,
when displaying the base product license, when registering the system... So if you
see in the log the base product evaluation you cannot be sure to which step that
belongs.
To improve the situation I have implemented two things:
- enhanced logging
- a new log viewer
Enhanced logging
----------------
I have added a new logger call to YaST, "log.group" call. It logs special markers
around the passed code block:
log.group "Description of the group" do
foo
end
Then you can easily know where that block started and where it finished.
The groups can be nested, you can have a big group consisting of several
smaller subgroups.
See more code examples in [1] or [2].
You can add this call to your code to structure the log better.
Usage
-----
Here are some real examples which show using the new call in two packages.
- ProductControl - controls the installation workflow, now each installation
step is wrapped in a separate log group [3]
- Registration - each registration step now has separate log group [4]
Log Viewer
----------
To take advantage of the new log messages we need a new log viewer.
I created an experimental web based log viewer at
https://lslezak.github.io/ylogviewer
It can load a local y2log file or an archive created by the "save_y2log" script
(a *.tar.(bz2|gz|xz) file). It can also load a remote file from a specified URL.
It provides basic filtering functions so you can hide some messages depending on the
log lever or the component. Click the "Filter" button in the top right corner.
It is a static web page and it uses some HTML5 features, the files are processed
completely locally. See the notes on the main page.
(Note: Martin found out that it cannot read tarballs in FireFox, reading plaing text
logs works fine. Use Chrome/Chromium browser, that works fine. Later I'll look at
this problem...)
The source code is available in [5], ideas or pull requests with improvements will be
appreciated. :-)
So far it is hosted in my GitHub account, if it is useful I can move it to the
"yast" organization later.
Example Log
-----------
I uploaded an example log with the new features so you can see how it looks in
the new viewer. See link [5] below, click the "Load URL" button, scroll to the
bottom to see the new grouped sections.
Enjoy!
Ladislav
[1]
https://github.com/yast/yast-ruby-bindings/blob/df4390875bbaed6c2cc8d4a47b5…
[2] https://github.com/yast/yast-ruby-bindings/pull/287
[3] https://github.com/yast/yast-yast2/pull/1278
[4] https://github.com/yast/yast-registration/pull/583
[5] https://github.com/lslezak/ylogviewer
[6]
https://lslezak.github.io/ylogviewer/?log_url=https%3A%2F%2Fgist.githubuser…
--
Ladislav Slezák
YaST Developer
SUSE LINUX, s.r.o.
Corso IIa
Křižíkova 148/34
18600 Praha 8
Here it comes another bunch of news from the YaST Team trenches including:
- Several news about D-Installer
- An update about the new Security Policies in the YaST installer
- An effort to streamline a bit the YaST container
- Some polishing of Podman checkpoints for Tumbleweed and ALP
Check the full report at
https://yast.opensuse.org/blog/2022-10-20/yast-report-2022-10
Cheers.
--
Ancor González Sosa
YaST Team at SUSE Linux GmbH