Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ci: Use the exttests container #677

Draft
wants to merge 1 commit into
base: testing-devel
Choose a base branch
from

Conversation

cgwalters
Copy link
Member

This is an incremental step to test out running exttests.
But hopefully soon want we do is go multi-pod/multi-stage
and split off exttests separately - we may not always
want to gate on them, etc.

This is an incremental step to test out running exttests.
But hopefully soon want we do is go multi-pod/multi-stage
and split off exttests separately - we may not always
want to gate on them, etc.
@cgwalters
Copy link
Member Author

From Jenkins logs looks like it worked!

--- PASS: ext.ostree.destructive-rs.transactionality (397.98s)

@cgwalters
Copy link
Member Author

To recap with this we have a flow where:

  • Change to tests (or new test for new feature) in upstream ostree/ignition/etc git repo is submitted
  • Change is tested in CI on that repo
  • Change merges
  • (Later, or maybe sooner) Submit PR to bump the tag on https://github.com/coreos/coreos-assembler/blob/master/exttests/build.sh (could be automated)
  • (hmm, that change should be covered by CI but isn't today)
  • New exttests container builds
  • New test is run on our main builds too

Or in other words, we run upstream tests on both upstream builds and our pipeline without duplicating the tests.

cosaPod {
// Use the exttests container here in CI to get extra coverage; xref
// https://github.com/coreos/coreos-assembler/pull/1745
cosaPod(image: "registry.svc.ci.openshift.org/coreos/cosa-exttests:latest") {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a strong preference for having CI keep using the canonical cosa image from quay.io for all the main steps. It's what devs use locally. We've also had multiple encounters with OpenShift CI having stale versions of cosa or rebuilds of layered images like this not triggering. It's a major pain to debug.

How about instead we add sugar to coreos-ci-lib to have the exttest container be added to the pod and then for the kola run, it knows to use the exttest container just for the installed tests? (I.e. using container("exttests") { ... }).

Hmm, or maybe it is indeed easier to just fold this into cosa for now until we do something fancier as discussed in coreos/coreos-assembler#1745.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants