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
Challenge:
----------
Libzypp supports parallel download and install. Yast installation progress does
not fit it at all [1]. Issues are secondary progress bar that does not work
with parallel installation. Also there are overwhelming amount of
information on screen that is quite distracting. That information is often
wrong like time estimation. And also table for media is a bit useless nowadays
as everything is on one iso/medium, so there is no need to see when cd switch
will be needed. The details tab are the most visible as it is default one.
Proposal:
---------
Remove completely that details tab and keep just release notes one[2]. It
contains release notes that contain useful information and also has just one
progress bar. For that bar remove keep always just remaining size and count of packages,
so user has idea how it does, but do not print what exactly is installing
or any time estimation. If there are more release notes allow to switch between them.
Also keep possibility to have slide show which we had in past for installation
if someone create some ( when checked other OSes, the Ubuntu slide show during
installation looks probably the best from user POV ).
The same changes will apply to ncurses front end[3], we just need to check why formatting
of release notes are so badly formatted.
And same for opensuse[4] of course.
Josef
[1] https://pasteboard.co/cNBjER6SnLLT.png
[2] https://pasteboard.co/WnI7wS7VVVqq.png
[3] https://pasteboard.co/vzQvY1PaVDaD.png
[4] https://pasteboard.co/FzEqcIN7Xnas.png
This email is automatic generated from yast CI node. It lists of pull requests that have no activity more then three working days. If your module is listed, please check all pull request, why they are not merged yet.
Pending requests in repository yast-country:
- Unify YaST module mocking in unit tests (9 days)
https://github.com/yast/yast-country/pull/289
Pending requests in repository yast-devtools:
- Set %yast_icondir to /usr/share/icons/hicolor (bsc#1186066) (186 days)
https://github.com/yast/yast-devtools/pull/161
Pending requests in repository yast-s390:
- S390 formatting progress dialog improvements (6 days)
https://github.com/yast/yast-s390/pull/93
Pending requests in repository yast-sound:
- Fix module filename matching (jsc#SLE-21256). (41 days)
https://github.com/yast/yast-sound/pull/53
Pending requests in repository yast-theme:
- Add pantheon desktop support (61 days)
https://github.com/yast/yast-theme/pull/154
Pending requests in repository yast-journal:
- Use Yast::Builtins.strftime in 'Change Filter' dialog (118 days)
https://github.com/yast/yast-journal/pull/45
Pending requests in repository yast-sap-ha:
- SUSE SAP HA Yast wizard for HANA doesn´t configure the HANA hooks. (48 days)
https://github.com/yast/yast-sap-ha/pull/7
Hi all,
some time ago we discussed where and how we should share
"Tips&Tricks" for YaST users and developers.
IIRC there was no clear conclusion so I decided to start
a wiki [1] to collect all our tricks we know or use.
For now it's just a place for dumping your ideas, links, short
howtos, etc... When we collect enough data we can probably
split it to several categories or move it somewhere else.
We just need the data first.
I have added there some my tricks from my personal "knowledgebase"
file. If you have better tricks or find something wrong simply
change it, it's a wiki ;-)
Ladislav
[1] https://github.com/yast/yast.github.io/wiki/YaST-Tips-and-Tricks
--
Ladislav Slezák
YaST Developer
SUSE LINUX, s.r.o.
Corso IIa
Křižíkova 148/34
18600 Praha 8
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi all,
While working on a P1[1], I found out that the SP4 inst-sys already
ships SUSEConnect-ng (the new Go-based version). So we should have that
into account when dealing with registration bugs and contact the SCC
team if something does not work as we expected.
Regards,
Imo
[1] https://bugzilla.suse.com/show_bug.cgi?id=1194989#c7
--
Imobach González Sosa
YaST Team at SUSE LLC
https://imobachgs.github.io/
Hi!
I have enabled RSpec verifying doubles in all remaining YaST unit tests where they
were not used. The advantage is that RSpec checks that the mocked methods really
exist in the original class. Without it if you make a typo in a method call in the
code and make the same typo in the unit test mock then the test will pass but the
code will actually crash at run time.
So ideally we should enable this feature everywhere.
But in the YaST unit test we quite often replace some YaST modules with an empty
class to avoid too long or cyclic build dependencies. If you mock an YaST module
completely then you have the same problem back as the dummy methods are really
defined there so even RSpec verifying doubles will not catch the problems there.
To use advantages from the both worlds I have created a new
Yast::RSpec::Helpers.define_yast_module helper method. [1]
It tries to load the requested YaST module via the usual YaST.import call. If that
fails then it defines a dummy replacement for it. So if the module is present in the
system, like when you run the unit tests locally on your machine or when running in
GitHub Actions where most of the modules are present, then it will load the real
modules and the verifying doubles will fully work.
In RPM build it will create dummy modules and the build dependencies can be avoided.
Examples:
# defined here, needs yast2-ruby-bindings >= 4.4.7
require "yast/rspec"
# if you do not mock the module methods in the tests you can use
# this simple variant
Yast::RSpec::Helpers.define_yast_module("AutoInstall")
# if you mock some methods then they must be defined in the mocked class
# so the verifying doubles check does not fail
Yast::RSpec::Helpers.define_yast_module("Profile", methods: [:current])
# note: for simplification all mocked methods accept any number of parameters,
# the real parameters should be verified when running against the real modules
# you can also pass a block which is evaluated in the context of the created class
# so you can define some defaults, in theory you could define also some logic there
# but I'd avoid it, the mocked logic might easily go out of sync with the real module
Yast::RSpec::Helpers.define_yast_module("Language") do
def language
# the default
"en_US"
end
end
Then if you run "rake test:unit" locally the modules will be loaded from system when
found. If you want to force creating the mocked modules even when they are present in
the system then just set the YAST_FORCE_MODULE_STUBS environment variable, e.g.:
YAST_FORCE_MODULE_STUBS=1 rake test:unit
This is useful if you want to test locally how it will work in RPM build, whether
your mocks implement all the methods used in the tests.
You can check some real examples in [2] and [3].
And interestingly enabling verifying doubles found a real bug in the code! [4]
Enjoy!
Ladislav
[1] https://github.com/yast/yast-ruby-bindings/pull/281
[2] https://github.com/yast/yast-bootloader/pull/663/files
[3] https://github.com/yast/yast-network/pull/1278/files
[4]
https://github.com/yast/yast-installation/pull/1013/files#diff-05183469b1a0…
--
Ladislav Slezák
YaST Developer
SUSE LINUX, s.r.o.
Corso IIa
Křižíkova 148/34
18600 Praha 8
Hi all,
During 2021, the YaST team was playing with the idea of building a web-
based installer using our libraries. Finally, we have decided to define
the project and try to invest some CPU cycles on it. 🙂
Please, read the announcement in our blog and do not hesitate to share
your point of view with us.
https://yast.opensuse.org/blog/2022-01-18/announcing-the-d-installer-project
Regards,
Imo
--
Imobach González Sosa
YaST Team at SUSE LLC
https://imobachgs.github.io/
Hello!
I created an empty testing RPM repository [1] which might be easily used in some tests.
Advantage of an empty repository is that it cannot affect the installed packages or
cause any conflicts. It can be also used with any product in any version.
The most important feature of this particular repository is that it is signed by the
official SUSE GPG keys! So YaST or zypper will not complain about unknown or missing
GPG signatures and it can be easily used in automated tests.
Enjoy! :-)
Ladislav
[1] https://github.com/lslezak/empty_repo
--
Ladislav Slezák
YaST Developer
SUSE LINUX, s.r.o.
Corso IIa
Křižíkova 148/34
18600 Praha 8