File: README.asciidoc

package info (click to toggle)
os-autoinst 4.5.1527308405.8b586d5-4.1
  • links: PTS, VCS
  • area: main
  • in suites: bullseye, buster, sid
  • size: 22,688 kB
  • sloc: perl: 10,424; cpp: 1,527; python: 217; makefile: 211; sh: 71; xml: 11
file content (102 lines) | stat: -rw-r--r-- 3,928 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
os-autoinst image:https://api.travis-ci.org/os-autoinst/os-autoinst.svg?branch=master[link=https://travis-ci.org/os-autoinst/os-autoinst] image:https://coveralls.io/repos/github/os-autoinst/os-autoinst/badge.svg?branch=master[link=https://coveralls.io/github/os-autoinst/os-autoinst?branch=master]
=========================================================================================================================================================================================================================================================================================================
:author: openSUSE Team at SUSE
:toc:

The OS-autoinst project aims at providing a means to run fully
automated tests.  Especially to run tests of basic and low-level
operating system components such as bootloader, kernel, installer and
upgrade, which can not easily and safely be tested with other
automated testing frameworks.  However, it can just as well be used to
test firefox and openoffice operation on top of a newly installed OS.

os-autoinst can be executed alone, but is currently designed to be
executed together with openQA, the web user interface that allows to
run more than one os-autoinst instance at the same time.

More information on os-autoinst and openQA can be found on
http://os-autoinst.github.io/openQA/

Getting started
---------------

To install os-autoinst, you can see link:INSTALL.asciidoc[INSTALL]

To execute an instance of os-autoinst, we need to create file named
vars.json, that we use to store the values of the different variables
that will configure and drive the behavior of the application.

There are some variables used by os-autoinst itself and other that are
used by the tests.  A minimal vars.json file can be:

[source, javascript]
-------------------------------------------------------------------
{
   "DISTRI" :      "opensuse",
   "CASEDIR" :     "/full/path/for/tests",
   "NAME" :        "test-name",
   "ISO" :         "/full/path/for/iso",
   "VNC" :         "91",
   "BACKEND" :     "qemu",
   "DESKTOP" :     "kde"
}
-------------------------------------------------------------------

Be advised that the file vars.json is read and also written by isotovideo so
make sure to backup handcrafted versions of this file.

Now we can launch the application with:

$ ../os-autoinst/isotovideo

and we can use VNC to connect to the QEMU instance:

$ vncviewer localhost:91 -ViewOnly -Shared


Run isotovideo with the environment variable `RUN_VNCVIEWER` set to autostart
a VNC viewer on the right port.

Run isotovideo with the environment variable `RUN_DEBUGVIEWER` to start the
internal debug screenshot viewer updated with an always recent screenshot of
the test run.


How to contribute
-----------------

If you want to contribute to this project, please clone and send
git-pull requests via https://github.com/os-autoinst/os-autoinst.

More information on the contribution can be found on
http://os-autoinst.github.io/openQA/contact/, too.

Issues are tracked on https://progress.opensuse.org/projects/openqav3/

Rules for commits
^^^^^^^^^^^^^^^^^

* Every commit is checked by https://travis-ci.org/travis[Travis CI] as soon as
you create a pull request but you *should* run the os-autoinst tests locally,
i.e. call
----
./autogen.sh
make
----
once to setup your workspace and before every commit
----
make check
----

* You *may* also run local tests on your machine or in your own development
environment to verify everything works as expected.

* For git commit messages use the rules stated on
http://chris.beams.io/posts/git-commit/[How to Write a Git Commit Message] as
a reference

* Every pull request is reviewed in a peer review to give feedback on possible
implications and how we can help each other to improve

If this is too much hassle for you feel free to provide incomplete pull
requests for consideration or create an issue with a code change proposal.