[
https://ovirt-jira.atlassian.net/browse/OVIRT-1385?page=com.atlassian.jir...
]
Barak Korren commented on OVIRT-1385:
-------------------------------------
The runtime different between cache-using mock runs and non-cache using ones is more then
a minute, so playing with the caching intervals would be I'll advised. Making this
configurable would not be trivial at all.
I suppose the {{*.packages}} file format can be extended to allow requesting certain
versions or forcing updates. Such changes will need to go into the {{mock_runner.sh}}
code. There had been similar requests made in the past (Can't locate the relevant
tickets right now).
I'm afraid I cannot prioritize this ticket very highly though. We are a bit reluctant
to add any new features to {{mock_runner.sh}} for the time being.
Patches will be welcome though....
Support installing latest version of specific pkgs
--------------------------------------------------
Key: OVIRT-1385
URL:
https://ovirt-jira.atlassian.net/browse/OVIRT-1385
Project: oVirt - virtualization made easy
Issue Type: Improvement
Reporter: Vojtech Szocs
Assignee: infra
There are multiple oVirt projects (see below) which contain a {{build.packages.force}}
(or similar) file, along with the following code in their build script:
{code}
# The "build.packages.force" file contains BuildRequires packages
# to be installed using their latest version.
# Force CI to get the latest version of these packages:
dependencies="$(sed -e '/^[ \t]*$/d' -e '/^#/d'
automation/build.packages.force)"
yum-deprecated clean metadata || yum clean metadata
yum-deprecated -y install ${dependencies} || yum -y install ${dependencies}
{code}
Used in projects: ovirt-engine-dashboard, ovirt-engine-nodejs-modules, ovirt-web-ui
Is it possible for CI to support this out of the box, using {{.force}} file convention?
(basically a suffix to standard {{.packages}} files)
I've looked at OVIRT-921 and IIUC the yum cache is cleaned every 2 days, so an
alternative to above proposal would be to have this interval configurable per-project.
Not sure what's the best approach here, please advise.
--
This message was sent by Atlassian JIRA
(v1000.967.1#100042)