- Infra - oVirt List Archives

[JIRA] (OVIRT-2669) CI scripts try to modify unrelated bugs
by Ehud Yonasi (oVirt JIRA) 05 Feb '19

05 Feb '19

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2669?page=com.atlassian.jira.… ] Ehud Yonasi updated OVIRT-2669: ------------------------------- Resolution: Duplicate Status: Done (was: To Do) > CI scripts try to modify unrelated bugs > --------------------------------------- > > Key: OVIRT-2669 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2669 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Nir Soffer > Assignee: infra > > If a commit message mention another bug, the CI script try to add the patch > to the bug in the commit message, and change the bug to POST. > Mentioning another bug in a commit message is good practice, making it > easier to follow, and avoiding unclear forms like "bug 1000000" or > "BZ#1000000", > or even worse shortened urls like https://goo.gl/bPuFGo. > Does it make sense that we cannot link to Red Hat bugzilla like god > intended? > Here is a proof: > https://gerrit.ovirt.org/c/97568/ > gerrit-hooks > Patch Set 1: > Check Bug-Url::10000000::WARN, failed to get bug info (private bug or > bug doesn't exist > Check Product::IGNORE, not relevant for branch: master > Check TM::IGNORE, not relevant for branch: master > Check Backport::IGNORE, not relevant for branch: master > Set POST::#10000000::WARN, failed to get bug info (private bug or bug > doesn't exist) > Update Tracker::#10000000::WARN, failed to get bug info (private bug or > bug doesn't exist) > CI scripts should process urls only inside Bug-Url: tag. > Expected behavior: > Extract bug urls *only* from Bug-Url: label. > The same issue exists with Related-To: label. > This is not a new bug. I reported it few years ago but for some reason the > issue > was not understood. > Nir -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100098)

1 0

[JIRA] (OVIRT-2669) CI scripts try to modify unrelated bugs
by Ehud Yonasi (oVirt JIRA) 05 Feb '19

05 Feb '19

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2669?page=com.atlassian.jira.… ] Ehud Yonasi commented on OVIRT-2669: ------------------------------------ Closing this ticket, opening in d/s jira. > CI scripts try to modify unrelated bugs > --------------------------------------- > > Key: OVIRT-2669 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2669 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Nir Soffer > Assignee: infra > > If a commit message mention another bug, the CI script try to add the patch > to the bug in the commit message, and change the bug to POST. > Mentioning another bug in a commit message is good practice, making it > easier to follow, and avoiding unclear forms like "bug 1000000" or > "BZ#1000000", > or even worse shortened urls like https://goo.gl/bPuFGo. > Does it make sense that we cannot link to Red Hat bugzilla like god > intended? > Here is a proof: > https://gerrit.ovirt.org/c/97568/ > gerrit-hooks > Patch Set 1: > Check Bug-Url::10000000::WARN, failed to get bug info (private bug or > bug doesn't exist > Check Product::IGNORE, not relevant for branch: master > Check TM::IGNORE, not relevant for branch: master > Check Backport::IGNORE, not relevant for branch: master > Set POST::#10000000::WARN, failed to get bug info (private bug or bug > doesn't exist) > Update Tracker::#10000000::WARN, failed to get bug info (private bug or > bug doesn't exist) > CI scripts should process urls only inside Bug-Url: tag. > Expected behavior: > Extract bug urls *only* from Bug-Url: label. > The same issue exists with Related-To: label. > This is not a new bug. I reported it few years ago but for some reason the > issue > was not understood. > Nir -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100098)

1 0

[JENKINS] Failed to setup proejct kubevirt_kubevirt_standard-check-pr
by jenkins＠jenkins.phx.ovirt.org 05 Feb '19

05 Feb '19

Failed to run project_setup.sh for: #3436 kubevirt [check-patch]. It probably means that docker_cleanup.py failed. This step doesn't fail the job, but we do collect data about such failures to find the root cause. Infra owner, ensure that we're not running out of disk space on openshift-kubevirt-org-xxlnf.

1 0

[JENKINS] Failed to setup proejct kubevirt_kubevirt_standard-check-pr
by jenkins＠jenkins.phx.ovirt.org 05 Feb '19

05 Feb '19

Failed to run project_setup.sh for: #3433 kubevirt [check-patch]. It probably means that docker_cleanup.py failed. This step doesn't fail the job, but we do collect data about such failures to find the root cause. Infra owner, ensure that we're not running out of disk space on openshift-kubevirt-org-n1p89.

1 0

[JIRA] (OVIRT-2669) CI scripts try to modify unrelated bugs
by Nir Soffer (oVirt JIRA) 05 Feb '19

05 Feb '19

Nir Soffer created OVIRT-2669: --------------------------------- Summary: CI scripts try to modify unrelated bugs Key: OVIRT-2669 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2669 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Nir Soffer Assignee: infra If a commit message mention another bug, the CI script try to add the patch to the bug in the commit message, and change the bug to POST. Mentioning another bug in a commit message is good practice, making it easier to follow, and avoiding unclear forms like "bug 1000000" or "BZ#1000000", or even worse shortened urls like https://goo.gl/bPuFGo. Does it make sense that we cannot link to Red Hat bugzilla like god intended? Here is a proof: https://gerrit.ovirt.org/c/97568/ gerrit-hooks Patch Set 1: Check Bug-Url::10000000::WARN, failed to get bug info (private bug or bug doesn't exist Check Product::IGNORE, not relevant for branch: master Check TM::IGNORE, not relevant for branch: master Check Backport::IGNORE, not relevant for branch: master Set POST::#10000000::WARN, failed to get bug info (private bug or bug doesn't exist) Update Tracker::#10000000::WARN, failed to get bug info (private bug or bug doesn't exist) CI scripts should process urls only inside Bug-Url: tag. Expected behavior: Extract bug urls *only* from Bug-Url: label. The same issue exists with Related-To: label. This is not a new bug. I reported it few years ago but for some reason the issue was not understood. Nir -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100098)

1 0

CI scripts try to modify unrelated bugs
by Nir Soffer 05 Feb '19

05 Feb '19

If a commit message mention another bug, the CI script try to add the patch to the bug in the commit message, and change the bug to POST. Mentioning another bug in a commit message is good practice, making it easier to follow, and avoiding unclear forms like "bug 1000000" or "BZ#1000000", or even worse shortened urls like https://goo.gl/bPuFGo. Does it make sense that we cannot link to Red Hat bugzilla like god intended? Here is a proof: https://gerrit.ovirt.org/c/97568/ gerrit-hooks Patch Set 1: Check Bug-Url::10000000::WARN, failed to get bug info (private bug or bug doesn't exist Check Product::IGNORE, not relevant for branch: master Check TM::IGNORE, not relevant for branch: master Check Backport::IGNORE, not relevant for branch: master Set POST::#10000000::WARN, failed to get bug info (private bug or bug doesn't exist) Update Tracker::#10000000::WARN, failed to get bug info (private bug or bug doesn't exist) CI scripts should process urls only inside Bug-Url: tag. Expected behavior: Extract bug urls *only* from Bug-Url: label. The same issue exists with Related-To: label. This is not a new bug. I reported it few years ago but for some reason the issue was not understood. Nir

1 0

[JIRA] (OVIRT-2668) WildFly 15 packages got to tested-4.3 repo, but not to tested-master repo
by Ehud Yonasi (oVirt JIRA) 05 Feb '19

05 Feb '19

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2668?page=com.atlassian.jira.… ] Ehud Yonasi reassigned OVIRT-2668: ---------------------------------- Assignee: Ehud Yonasi (was: infra) > WildFly 15 packages got to tested-4.3 repo, but not to tested-master repo > ------------------------------------------------------------------------- > > Key: OVIRT-2668 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2668 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Martin Perina > Assignee: Ehud Yonasi > > Hi, > I have a problem with publishing WildFly 15 packages to tested repos for master and 4.3. I've merged [#97474|https://gerrit.ovirt.org/97474] and next day I've found out that [ovirt-engine-wildfly-15.0.1-1.el7.x86_64.rpm|https://plain.resources.ovirt.…] and [ovirt-engine-wildfly-overlay-15.0.1-1.el7.noarch.rpm|https://plain.resource…] packages appeared in ovirt-4.3 tested repo, but they were not published to master-tested repo, although I have both branches mentioned in [stdci.yaml|https://github.com/oVirt/ovirt-engine-wildfly/blob/master/stdci.…] in the project. > Is it some issue with stdci.yaml or something went wrong in CQ publishing? > The absence of WildFly 15 in master-tested repo blocks finishing of [BZ1671635|https://bugzilla.redhat.com/1671635] > Thanks > Martin -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100098)

1 0

[JIRA] (OVIRT-2668) WildFly 15 packages got to tested-4.3 repo, but not to tested-master repo
by Ehud Yonasi (oVirt JIRA) 05 Feb '19

05 Feb '19

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2668?page=com.atlassian.jira.… ] Ehud Yonasi commented on OVIRT-2668: ------------------------------------ Hi [~mwperina], It was published into master CQ, but since there was a packaging issue that was solved today, all master cq jobs failed. I've re-added your patch into the cq system and if it passes CQ, it should be published to tested. > WildFly 15 packages got to tested-4.3 repo, but not to tested-master repo > ------------------------------------------------------------------------- > > Key: OVIRT-2668 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2668 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Martin Perina > Assignee: infra > > Hi, > I have a problem with publishing WildFly 15 packages to tested repos for master and 4.3. I've merged [#97474|https://gerrit.ovirt.org/97474] and next day I've found out that [ovirt-engine-wildfly-15.0.1-1.el7.x86_64.rpm|https://plain.resources.ovirt.…] and [ovirt-engine-wildfly-overlay-15.0.1-1.el7.noarch.rpm|https://plain.resource…] packages appeared in ovirt-4.3 tested repo, but they were not published to master-tested repo, although I have both branches mentioned in [stdci.yaml|https://github.com/oVirt/ovirt-engine-wildfly/blob/master/stdci.…] in the project. > Is it some issue with stdci.yaml or something went wrong in CQ publishing? > The absence of WildFly 15 in master-tested repo blocks finishing of [BZ1671635|https://bugzilla.redhat.com/1671635] > Thanks > Martin -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100098)

1 0

[JIRA] (OVIRT-2668) WildFly 15 packages got to tested-4.3 repo, but not to tested-master repo
by Martin Perina (oVirt JIRA) 05 Feb '19

05 Feb '19

Martin Perina created OVIRT-2668: ------------------------------------ Summary: WildFly 15 packages got to tested-4.3 repo, but not to tested-master repo Key: OVIRT-2668 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2668 Project: oVirt - virtualization made easy Issue Type: Bug Reporter: Martin Perina Assignee: infra Hi, I have a problem with publishing WildFly 15 packages to tested repos for master and 4.3. I've merged [#97474|https://gerrit.ovirt.org/97474] and next day I've found out that [ovirt-engine-wildfly-15.0.1-1.el7.x86_64.rpm|https://plain.resources.ovirt.…] and [ovirt-engine-wildfly-overlay-15.0.1-1.el7.noarch.rpm|https://plain.resource…] packages appeared in ovirt-4.3 tested repo, but they were not published to master-tested repo, although I have both branches mentioned in [stdci.yaml|https://github.com/oVirt/ovirt-engine-wildfly/blob/master/stdci.…] in the project. Is it some issue with stdci.yaml or something went wrong in CQ publishing? The absence of WildFly 15 in master-tested repo blocks finishing of [BZ1671635|https://bugzilla.redhat.com/1671635] Thanks Martin -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100098)

1 0

Build failed in Jenkins: system-sync_mirrors-fedora-base-fc29-x86_64 #269
by jenkins＠jenkins.phx.ovirt.org 04 Feb '19

04 Feb '19

See <http://jenkins.ovirt.org/job/system-sync_mirrors-fedora-base-fc29-x86_64/26…> Changes: [Sandro Bonazzola] ovirt-release: move to check-patch to v2 ------------------------------------------ Started by timer [EnvInject] - Loading node environment variables. Building remotely on mirrors.phx.ovirt.org (mirrors) in workspace <http://jenkins.ovirt.org/job/system-sync_mirrors-fedora-base-fc29-x86_64/ws/> > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url http://gerrit.ovirt.org/jenkins.git # timeout=10 Cleaning workspace > git rev-parse --verify HEAD # timeout=10 Resetting working tree > git reset --hard # timeout=10 > git clean -fdx # timeout=10 Pruning obsolete local branches Fetching upstream changes from http://gerrit.ovirt.org/jenkins.git > git --version # timeout=10 > git fetch --tags --progress http://gerrit.ovirt.org/jenkins.git +refs/heads/*:refs/remotes/origin/* --prune > git rev-parse origin/master^{commit} # timeout=10 Checking out Revision 0c58c6af77462077362709504192b5388a90f207 (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f 0c58c6af77462077362709504192b5388a90f207 Commit message: "ovirt-release: move to check-patch to v2" > git rev-list --no-walk 2475ed85fd8420315ce9833bd51cc956f7bda7e8 # timeout=10 [system-sync_mirrors-fedora-base-fc29-x86_64] $ /bin/bash -xe /tmp/jenkins8359310665409060836.sh + jenkins/scripts/mirror_mgr.sh resync_yum_mirror fedora-base-fc29 x86_64 jenkins/data/mirrors-reposync.conf + MIRRORS_MP_BASE=/var/www/html/repos + MIRRORS_HTTP_BASE=http://mirrors.phx.ovirt.org/repos + MIRRORS_CACHE=/home/jenkins/mirrors_cache + MAX_LOCK_ATTEMPTS=120 + LOCK_WAIT_INTERVAL=5 + LOCK_BASE=/home/jenkins + OLD_MD_TO_KEEP=100 + HTTP_SELINUX_TYPE=httpd_sys_content_t + HTTP_FILE_MODE=644 + main resync_yum_mirror fedora-base-fc29 x86_64 jenkins/data/mirrors-reposync.conf + local command=resync_yum_mirror + command_args=("${@:2}") + local command_args + cmd_resync_yum_mirror fedora-base-fc29 x86_64 jenkins/data/mirrors-reposync.conf + local repo_name=fedora-base-fc29 + local repo_archs=x86_64 + local reposync_conf=jenkins/data/mirrors-reposync.conf + local sync_needed + mkdir -p /home/jenkins/mirrors_cache + verify_repo_fs fedora-base-fc29 yum + local repo_name=fedora-base-fc29 + local repo_type=yum + sudo install -o jenkins -d /var/www/html/repos/yum /var/www/html/repos/yum/fedora-base-fc29 /var/www/html/repos/yum/fedora-base-fc29/base + check_yum_sync_needed fedora-base-fc29 x86_64 jenkins/data/mirrors-reposync.conf sync_needed + local repo_name=fedora-base-fc29 + local repo_archs=x86_64 + local reposync_conf=jenkins/data/mirrors-reposync.conf + local p_sync_needed=sync_needed + local reposync_out + echo 'Checking if mirror needs a resync' Checking if mirror needs a resync + rm -rf /home/jenkins/mirrors_cache/fedora-base-fc29 ++ IFS=, ++ echo x86_64 + for arch in '$(IFS=,; echo $repo_archs)' ++ run_reposync fedora-base-fc29 x86_64 jenkins/data/mirrors-reposync.conf --urls --quiet ++ local repo_name=fedora-base-fc29 ++ local repo_arch=x86_64 ++ local reposync_conf=jenkins/data/mirrors-reposync.conf ++ extra_args=("${@:4}") ++ local extra_args ++ reposync --config=jenkins/data/mirrors-reposync.conf --repoid=fedora-base-fc29 --arch=x86_64 --cachedir=/home/jenkins/mirrors_cache --download_path=/var/www/html/repos/yum/fedora-base-fc29/base --norepopath --newest-only --urls --quiet Traceback (most recent call last): File "/usr/bin/reposync", line 343, in <module> main() File "/usr/bin/reposync", line 175, in main my.doRepoSetup() File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 681, in doRepoSetup return self._getRepos(thisrepo, True) File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 721, in _getRepos self._repos.doSetup(thisrepo) File "/usr/lib/python2.7/site-packages/yum/repos.py", line 157, in doSetup self.retrieveAllMD() File "/usr/lib/python2.7/site-packages/yum/repos.py", line 88, in retrieveAllMD dl = repo._async and repo._commonLoadRepoXML(repo) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1479, in _commonLoadRepoXML result = self._getFileRepoXML(local, text) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1256, in _getFileRepoXML size=102400) # setting max size as 100K File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1022, in _getFile result = self.grab.urlgrab(misc.to_utf8(relative), local, File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 700, in <lambda> grab = property(lambda self: self._getgrab()) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 695, in _getgrab self._setupGrab() File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 632, in _setupGrab urls = self.urls File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 878, in <lambda> urls = property(fget=lambda self: self._geturls(), File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 875, in _geturls self._baseurlSetup() File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 821, in _baseurlSetup mirrorurls.extend(list(self.metalink_data.urls())) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 918, in <lambda> metalink_data = property(fget=lambda self: self._getMetalink(), File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 914, in _getMetalink self._metalink = metalink.MetaLinkRepoMD(self.metalink_filename) File "/usr/lib/python2.7/site-packages/yum/metalink.py", line 189, in __init__ raise MetaLinkRepoErrorParseFail, "File %s is not XML" % filename yum.metalink.MetaLinkRepoErrorParseFail: File /home/jenkins/mirrors_cache/fedora-base-fc29/metalink.xml is not XML + reposync_out='Could not get metalink https://mirrors.fedoraproject.org/metalink?repo=fedora-29&arch=x86_64 error was 16: error opening file from https://mirrors.fedoraproject.org/metalink?repo=fedora-29&arch=x86_64, IOError: [Errno 2] No such file or directory: '\''/home/jenkins/mirrors_cache/fedora-base-fc29/metalink.xml.tmp'\''' Build step 'Execute shell' marked build as failure

1 1