Some people reported in #centos-devel that their CI jobs were failing
(example
https://ci.centos.org/job/minishift-addons-nightly-b2d/49/console)
because of yum errors.
As you can see it was happening when using EPEL repository.
We have confirmation that EPEL infrastructure had an issue with
corrupted repodata everywhere, so it hurted us too. While it was fixed
upstream, it can take time for the corrected repodata to be replicated
everywhere, and I switched the EPEL mirror we're syncing/pulling from to
fix that earlier (the previous mirror we used was still bad)
This should fix your EPEL yum errors for now in CI.centos.org
--
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 56BEC54E | twitter: @arrfab
Didn't arrive at mailing list for some reason.
---------- Forwarded message ----------
From: <tdancs(a)redhat.com>
Date: Thu, May 10, 2018 at 10:05 AM
Subject: ci.centos.org network issues
To: ci-users(a)centos.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello guys,
We are experiencing some intermittent, but frequently appearing network
blackouts on ci.centos.org
At random times and random places during jenkins job run the network will
just disconnect, causing issues like `yum` unable to find mirros, `git`
unable to contact github.com, our tests stop communicating with
openshift.io and prod-preview.openshift.io che-servers and other issues
during our selenium tests.
Could please somebody take a look at this pressing issue?
Sincerely,
Tibor Dancs
-----BEGIN PGP SIGNATURE-----
Version: FlowCrypt 5.4.5 Gmail Encryption flowcrypt.com
Comment: Seamlessly send, receive and search encrypted email
wsFcBAEBCAAQBQJa8/1kCRCbdsMMvWqtvAAA9ZMP/RCS+2daO9/JfXaqO8qs
SCcLRnr7197i7xtTonHL7su74YLtCfQLp0Pqo7OOfssQ8K9pRSeg3TpicwhH
+Re9gfO3E5fv1cjg5bdXxAl01lqGayZjLewSa4FOLmgz1JP1dE5+619RlaDY
/lPbv2DjZH9uyeRLvm8OuHWCMBMCQstsWU0Ei6mXV9zcPCmg+qqpp3MZs0sc
JpEQ+a8s2wg2tzKJm+9/tYUcyEIJ61TlM2hoFBR9+Hk2dS1JIodM8pqqXBS2
7C/oqpTkVfnr145FFNaGwA44HmyakZxLuaj2IB8x6PFRvcpcfqPjyqvACl8q
YyOMgOValAS5KV4rpkXykQkECb+D4dyW0sZPh2kPKqS/QpISyNiYrAJIYjmo
UrsYEcbI4r2yd0guFIE2UZA7NjJSI4F6xP8NVfggwrZy2XSuYp8SSjRe1s+0
eVPd3hQ6/lZhhcYxa4DZD4mcAHqoEzx/A0t0aPAd7BKAmPIVgZhyzFzJZuex
QV6dykKGsGlpVDx144boS/Gdf1otyDtTmxKa0nmuhMF0caFLmXkrd/fqGqWg
QTQy6B5ISokunXsNv2VnND00SRhceNAw+X4hAKckn+lMJHXvSq6HPDm/uox7
tvI7GF+vmxPdAgRxhgzE/jlK0jJcTmdOK7Yu9KlfpSM9eOjM4DJIoPv2v69k
HHH+
=10UA
-----END PGP SIGNATURE-----
Hi Folks,
We're working on seeding CR
(https://wiki.centos.org/AdditionalResources/Repositories/CR)
Typically at this time we reinstall all the duffy nodes to get the
latest content, and allow you to test against what will be in 7.1804.
Until we have a healthy pool of machines built back up, I'll be pausing
Jenkins and letting your jobs queue up.
Happy Testing!
--
Brian Stinson
CentOS CI Infrastructure Team
Hi Brian,
We are facing some issue with Duffy, so we are not able to borrow any
machine.
I've reported it as bug[1], is that the right place for this issue report?
[1] https://bugs.centos.org/view.php?id=14715
Thanks,
Daniel
Hi, we'd like to migrate some of our workloads into
Kubernetes jobs; see for example:
https://github.com/projectatomic/papr/pull/70/commits/bdaabc975b6770e2c6826…
What are the available resources in apps.ci versus Duffy?
A lot of our jobs want basically a "classic Docker"
environment with e.g. uid 0, but not CAP_SYS_ADMIN. And with seccomp disabled, etc.
I was trying to create the test pod below, but it fails. It looks like our accounts
use the default SCC. Can we lift these restrictions?
BTW, I'd also like oci-kvm-hook installed, with this patch: https://github.com/stefwalter/oci-kvm-hook/pull/4
apiVersion: v1
kind: DeploymentConfig
metadata:
labels:
run: cgwalters-shell
name: cgwalters-shell
spec:
replicas: 1
selector:
run: cgwalters-shell
strategy:
resources: {}
template:
metadata:
labels:
run: cgwalters-shell
spec:
containers:
- args:
- sleep
- 24h
image: registry.fedoraproject.org/fedora:27
name: cgwalters-shell
# Run as uid 0
securityContext:
runAsUser: 0
Hi all,
we[1] have jobs triggered by every new or updated PR, configured
accordingly to [2] - Mode 2.
The jobs are triggered properly for people listed in the "Admin list" or
"White list" section, but not for people from "List of organizations.
Their members will be whitelisted.".
The relevant part of JJB configuration:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
triggers:
- github-pull-request:
admin-list:
- dahorak
org-list:
- Tendrl
allow-whitelist-orgs-as-admins: false
trigger-phrase: '.*run build.*'
skip-build-phrase: 'no build'
github-hooks: true
cancel-builds-on-update: true
status-context: 'CentOS CI - package build'
status-add-test-results: false
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Is there any other configuration needed, to enable the "List of
organizations" functionality?
Also the "cancel-builds-on-update: true" configuration seems not to
work, but I didn't debug it more.
[1] https://github.com/Tendrl
[2] https://wiki.centos.org/QaWiki/CI/GithubIntegration
Thanks,
Daniel
Dear CentOS CI Team & CI users,
We run quite a few jobs on the CentOS CI system and it's an essential
part for testing our libvirt deployment style of TripleO Quickstart.
With the recent Jenkins security update our jobs broke[1] while
requesting nodes with the cico client. It was easy to fix, however it
made us think about the advantage of using a single job scheduler for
all our testing.
Upstream OpenStack infra is now completely based on Zuul v3[2] without
having Jenkins as a backend for running jobs. Soon the same thing is
going to happen to our rdoproject.org instance as the new version of
SoftwareFactory[3] contains the v3 version, and we're considering
replacing our downstream jobs with Zuul based ones as well.
It would be an obvious advantage for us in the long term if we could
unify the way we handle job running and configuration through Zuul
instead of Jenkins.
I just wanted to test the waters with regards to the CentOS CI team's
willingness to consider setting up an instance and the other users
interest in it.
Please let me know what you think.
Best regards,
Attila
[1] https://bugs.launchpad.net/tripleo/+bug/1749845
[2] https://docs.openstack.org/infra/zuul/
[3] https://softwarefactory-project.io/docs/main_components.html