ci: periodic pipeline can perform a dry run of the promote step #334
Conversation
kubevirt-bot
added
release-note-none
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey @nestoracunablanco - I've reviewed your changes and they look great!
Here's what I looked at during the review
- 🟢 General issues: all looks good
- 🟢 Security: all looks good
- 🟢 Testing: all looks good
- 🟢 Complexity: all looks good
- 🟢 Documentation: all looks good
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
0xFelix
left a comment
0xFelix
left a comment
There was a problem hiding this comment.
Can you give an example set of commands that this helps with?
pipeline-periodic.sh
Outdated
|
|
||
| make medius | ||
|
|
||
| export KUBEVIRT_PROVIDER=${KUBEVIRT_PROVIDER:-k8s-1.31} |
There was a problem hiding this comment.
If we can we should not fix that value but use the kubevirtci default instead.
Sure, when we run it using the environment variable PROMOTE_DRY_RUN=true, it allows us to periodically run tests for other architectures without needing to publish anything. A valid use case could be to run tests for ARM and s390x with this option, and if everything goes well, run tests for AMD64 and publish the images. There is also a PR in the pipeline for project-infra, which will be opened for discussion if this change is approved. What do you think? |
This approach allows for code reuse, enabling testing of different architectures without the need to promote changes. Signed-off-by: Nestor Acuna Blanco <nestor.acuna@ibm.com>
nestoracunablanco
force-pushed
the
feat/pipelinePeriodicDryRunMode
branch
from
039f357 to
89e0be6
Compare
|
Is it because we can't have a single pipeline that builds and tests all artifacts for a given containerdisk Entry? |
|
Yes, the issue is that kubevirtci, with its default parameters, starts a Kubernetes cluster on the same machine. This means that only one architecture can be tested without complicating the code. This setup could allow for periodic jobs for other architectures that do not publish images. |
|
/retest |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: 0xFelix The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
kubevirt-bot
added
the
approved
|
@akrejcir what do you think about this change? |
|
/lgtm |
4 participants
This approach allows for code reuse, enabling testing of different architectures without the need to promote changes.
Release note: