Re: Fedora CI update 2020-03-11

2020-03-11 Thread Sudhir D


On 3/11/20 7:14 PM, Aleksandra Fedorova wrote:

Hi, all.

Here is the summary of CI-related work happening in Fedora.

If you have questions or topics to discuss you can also join Fedora CI
SIG bi-weekly meeting. Next session is today in #fedora-ci IRC channel
at 15:30 UTC

https://apps.fedoraproject.org/calendar/SIGs/#m9618



### Dist-git tests support multipackage updates

You can define package tests in dist-git via STR format

https://docs.fedoraproject.org/en-US/ci/standard-test-roles/

Note that dist-git/STR tests are different from running %check tests
in the rpm building phase. STR tests are executed in a clean virtual
machine with proper setup of repositories for the latest Fedora
Rawhide packages. This environment is better suited for integration
tests, which need to test the installed package, not the sources of
it.

Dist-git tests are fully compatible with the dynamic sidetag approach:
if you create a dynamic sidetag for the multi-package update, test
environment will be created with the content of the entire sidetag,
not an individual package.

Status: Ready to Use
Contact: Bruno Goncalves (bgoncalv) and #fedora-ci IRC channel.

### New test: rpminspect

There is a new rpminspect test running in Fedora Rawhide gating
enabled by default for all packages in a non-blocking mode.

More details:
https://github.com/rpminspect/rpminspect

Status: Ready to Use
Contact: David Cantrell (dcantrell)



Thanks for sending out all this information, Aleksandra :)

I also want to call out Tim Flink (irc: tflink) from Fedora QA team who 
worked extensively on getting rpminspect to run in a way that its 
results could show up in bodhi.





### Tests for pull-requests via Zuul

Zuul team has enabled Zuul CI engine to test Pagure pull requests.

You can opt-in to Zuul CI per package.

On every pull-request Zuul will
* run a scratch build
* run rpminspect on that build
* run dist-git test defined in STR format(if available)
* provide comment in the pull-request
* wait for you to put an manual approval on the PR
* merge the PR

* you can also get Zuul to handle merge events, so that it will
automatically build the regular koji build, after the merge.

Zuul now has support for EPEL8 branches.

More details:
https://fedoraproject.org/wiki/Zuul-based-ci

Status: Ready to use
Contact: Fabien Boucher (fbo)

### Koschei as a gating test

With sidetag gating feature enabled it is now possible to run Koschei
for each dynamic sidetag and make it a part of the gating process.

We do have Koschei deployed on Fedora infrastructure. There is
on-going work by Mikolaj Izdebski to get it integrated with the Fedora
Messaging, so that sidetags are submitted in Koschei when created.

Status: research and prototyping
Contact: Serhii Turivnyi (sturivny)

### Infra change: new Jenkins master

New Jenkins master to run generic tests and inherit Taskotron pipelines.

Our current Jenkins master, which is used for dist-git tests, was not
updated for some time and it is by design bundled to the pipeline it
runs. So adding new pipelines and separating pipelines from the
Jenkins master configuration is problematic.

The goal here is to have a Jenkins master setup which is easy to
update. It will have a set of plugins pre-installed and configured for
Fedora infrastructure endpoints, but jobs configuration will be
applied to it independently.

More details:
Current work is done on a Communishift project. Code will be available
soon at https://github.com/fedora-ci

Status: WIP
Contact: Jim Bair (jbair)

### Infra change: common repository and common format for generic tests

We are refactoring the Groovy pipeline library so it is better suited
to run generic tests.

One of the goals is that generic tests are all run in the same way,
and you don’t need to add a lot of new Groovy code to add a certain
bash script as a generic test.

We’d like people to be able to contribute new generic tests without
prior knowledge of the Jenkins internal setup.

Current focus is rpmdeplint and rpminspect pipelines.

More details:
https://github.com/fedora-ci

Status: WIP
Contact: Michal Srb (msrb)

### Infra change: ODCS composes

We are updating ODCS staging infrastructure to the latest ODCS
release. Once the Fedora instractructure freeze is over, we will also
update the ODCS production instance. This work is preparation for
possible further use of ODCS to generate composes used by Fedora CI as
well as main Fedora composes.

Status: WIP
Contact: Jan Kaluza (jkaluza)

### Infra change: Testing Farm Service

Testing Farm Team is working on open-sourcing parts of the RH internal
CI infrastructure as a service, which will be used by Fedora CI's
general tests and functional tests pipeline. The main input of the
service will be test definitions in the TMT/FMF format.

TMT documentation:
https://tmt.readthedocs.io/en/latest/
(recently added testcloud + podman provisioner)

Code is hosted at GitLab:

Re: 'No More Alphas': wiki revision drafts

2017-08-22 Thread Sudhir D



On 08/22/2017 07:34 PM, Matthew Miller wrote:

On Tue, Aug 22, 2017 at 07:18:04PM +0530, Sudhir D wrote:

On a slightly different thought, if we run all existing Alpha
criteria tests in rawhide, we can then probably look at existing
Alpha blocker as Branch blocker.. i.e, we don't branch unless the
blockers are fixed and thereby keeping rawhide at Alpha quality all
the time. We might want to call 'Basic Release Criteria' as 'Basic
Branch Criteria'.

H. I guess this would avoid needing to fix problems on both the
branch and rawhide. But, sometimes the fix should be different (e.g.
backport or quick fix on branch, update to new version or other long
term solution on rawhide).



Such fix must then be tracked separately for branched version.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: 'No More Alphas': wiki revision drafts

2017-08-22 Thread Sudhir D



On 08/03/2017 05:46 AM, Adam Williamson wrote:

* My proposal for 'what do we do about release criteria / validation'
is basically: the 'Fedora 27 Alpha Release Criteria' page gets renamed
'Basic Release Criteria' (note: not versioned, I don't think it should
be), and we document that *all* composes - not just Beta and Final
candidate composes, but also Rawhide and Branched nightlies - will be
automatically tested for (and release of them gated on) compliance with
them. Which is more or less what's proposed in the Change. All external
references to the 'Alpha' criteria get changed to 'Basic' (e.g. this is
what changed on the other criteria pages, and on the test matrix
template pages). Practically speaking, we currently have automated
testing for *most* of the existing Alpha criteria, but a few items
aren't covered. We can choose to move these to the Beta criteria, or
leave them on Basic and just accept that *actual* coverage doesn't
quite meet what we aspire to. I do *NOT* propose to have any kind of
blocker tracking bug for the Basic release criteria; it doesn't seem to
fit in the process, there is no Alpha release to block, and we can't
realistically block nightly composes on manual test results. So a
tracker bug wouldn't really have any reason to exist. In the case where
a violation of the Basic criteria makes it into composes despite the
automated testing, it should be marked as a Beta blocker.




On a slightly different thought, if we run all existing Alpha criteria 
tests in rawhide, we can then probably look at existing Alpha blocker as 
Branch blocker.. i.e, we don't branch unless the blockers are fixed and 
thereby keeping rawhide at Alpha quality all the time. We might want to 
call 'Basic Release Criteria' as 'Basic Branch Criteria'.


Regards,
Sudhir
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org