build_status fetches information from obs about the status
of the integration test builds. It also allows an easy refresh
of the tests regarding content changes on git when called
with the refresh parameter: build_status refresh
@classmethod are used in Python to represent methods that can
query and update the class (cls parameter). Is expected to be
used for metaprograming, or advanced techniques that require the
access to the class itself, before we have an instance.
@staticmethod are used to associate a function to a class. It will
not be have access to the instance (self) not the class (cls). In
other programming languages are known as class methods.
This patch replace all the @classmethod with @staticmethod when
there is not need to access to the cls parameter, because the
intention is to be used as normal functions.
The creation of the package changelog is based on a reference file.
However that reference file contained log information in a specific
timezone which requires to hardcode the region of that timezone
in the code to correctly run date/time calculations. This can
be done better from a conceptual point of view. This patch changes
the handling in a way that the reference file is a git log
excerpt including the dates as git log lists them. The dates
contains complete numeric time/date/zone information and can be
used for calculations. The changelog helper tool converts the
result data to match the requirements of rpm changelog files
and prints the time/date information localized to the callers
timezone or as UTC if the --utc switch is given. By default the
user local timezone settings applies. That way the setup of
the local timezone is immaterial to the changelog processor
and the workaround in the gitlab-ci rpm stage can be deleted
too.
Don't take commits into account that are older than the
given reference commit. This would destroy the chronological
order. Missing commits older than the reference can be
incorporated by rebuild_changelog_reference.sh
The bumpversion helper script updated the reference file
with changes since the latest date of the existing reference.
However even though the two pieces are in chronological order
that does not mean that the concatenated version of those
is still in chronological order. Thus that helper is deleted
and a new helper rebuild_changelog_reference exists. That
rebuilds the entire reference file from the history and
makes sure it is in chronological order. The tool should
only be called if the chronological order of the total changes
information is violated which under normal conditions
does not happen
In addition to create changelog information since the
latest date of a reference changelog, also allow to create
changelog information until the latest data of a reference
changelog
Make sure the commit for the changelog reference update
and the commit for the version bump have different
timestamps by sleeping 2sec between the two actions
Script that also updates the changelog reference file
before the version bump. It's optional to use this but
it would be handy as the commit would show the rpm
changelog differences from one tag to the other
The current way of creating the changelog file for the package
is based on reading the entire history of the git repository and
turns that information into a changelog. The downside of this
approach is that any change in the code that creates this changelog
information will impact older entries and could cause a conflict
on the changes file of the released package. This usually leads
to declined package submissions and blocks us in fixing bugs
in the changelog generator. This commit changes the process in
a way that only changes related to the oldest entry of a reference
changelog file compared to the current branch are taken into
account. This Fixes#979
The kiwi build process mostly does the right thing in terms of executing
with the correct Python interpreter throughout the build process, with
the exception of the Makefile not correctly locating the versioned Python
interpreter executable path, and the bash completion generator being executed
using '/usr/bin/python' without regard for what the target environment was.
This is a problem when a build environment complying with PEP 394 as it
stands today does not have Python 2 installed, such as when kiwi is being
built as a Python 3-only package in Fedora. Thus, the Makefile has been
adjusted to not only correctly locate the versioned Python interpreter, but
to also execute 'completion_helper' with the correct interpreter.
Additionally, a trivial change to the shebang to 'completion_helper'
was made to be consistent with other Python-based build helper scripts.
This is part of the overall effort to eliminate the dependencies on
Python 2 in Fedora.
Reference: https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3
The custom kiwi boot descriptions has been moved into
the kiwi-descriptions github repo and builds the compat
package kiwi-boot-descriptions from there. The build
of the boot image(initrd) is done by dracut and the
dracut module packages provided by kiwi. The classic
custom boot descriptions can still be used as alternative
method if the above package is installed. Related to
Issue #576
Prevent strict call of a specific version of the python
interpreter. All code has been written to work with py2
and py3 thus the venv environment setup should decide
what version a call of python is. Fixes#424
Given there is a valid Oxygen license owned by the company
as described in https://www.oxygenxml.com/oxygen_scripting.html
the schema documentation can be created using Oxygen. This
commit allows building the schema docs with alternative
doc builders and in case of Oxygen would change the way the
schema docs are generated in the following way:
1. Install Oxygen and setup the license to activate the tool
2. Setup the KIWI development shell environment to export
the schema_tool variable to point to the schemaDocumentation.sh
script provided by the Oxygen installation
export oxygen_tool=/path/to/Oxygen/schemaDocumentation.sh
3. In any case of a schema change manually call:
tox -e schema
This step was done before as part of the tox doc target
but can't be done automatically because it would require
a correctly licensed Oxygen installation in the travis
environment. Thus the result data has to be part of the
pull request
4. Build the documentation and review the result
tox -e doc
5. Create the pull request
when installing kiwi via pip, no alternatives setup done
when installing via rpm will be performed. In order to
allow the bash completion to work also the versioned
binaries needs to be added in the completion script
The schema parser to create the documentation run into
an endless recursion for the new k.any type. As any could
be anything there is not much do document for this type.
Thus it is now skipped from the traversal
The script is used to check which parts of the XML schema
are not used by the new (kiwi v8) version. The information
is helpful to find missing or obsolete attribute handling
in v8 vs. v7
A simple script to parse the RelaxNG schema that grabs relevant
information in order to produce autogenerated documentation from
the schema inline comments.
