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

Make CI build and use the e2e image #5083

Merged
merged 6 commits into from
Aug 24, 2022
Merged

Make CI build and use the e2e image #5083

merged 6 commits into from
Aug 24, 2022

Conversation

antgamdia
Copy link
Contributor

Description of the change

This PR simply adds a new step in the CI so that the e2e runner image is built on each run.

Benefits

The CI will always use the latest integration image as it is being built on each CI run.

Possible drawbacks

If a dependency happens to break the e2e tests, the CI runs will also fail.

Applicable issues

Additional information

N/A

Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
@netlify
Copy link

netlify bot commented Jul 16, 2022

Deploy Preview for kubeapps-dev ready!

Name Link
🔨 Latest commit 56b49d3
🔍 Latest deploy log https://app.netlify.com/sites/kubeapps-dev/deploys/6305fabdaa77a8000864c43a
😎 Deploy Preview https://deploy-preview-5083--kubeapps-dev.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site settings.

@castelblanque
Copy link
Collaborator

Not sure that we want to build the E2E image every CI run. That adds a lot of time to the (already) slow CI pipeline.
On top of that, it is an image that rarely changes, so why having it built every time?

@antgamdia
Copy link
Contributor Author

so why having it built every time?

Well, this is a matter of considering the tradeoffs, I mean: on the one hand, there is the reproducibility, in that we are building whatever we later consume, so the repo is the single source of truth here. On the other, the time spent (in this case is just around 3 minutes).

The whole discussion is here, but in short, we want to be able to know if a dependabot upgrade or an image update on the playwright runner is breaking the CI. Otherwise, we would only know it once we follow the release process and perform the regular updates.

Perhaps we could improve it and just build the image for pushes to main if you want to save some time, but still, 3 minutes (given the order of magnitude we are handling, >20-30 min) is not that bad, IMHO.

Anyway, happy to follow any alternative approach.

@castelblanque
Copy link
Collaborator

Perhaps we could improve it and just build the image for pushes to main if you want to save some time

+1 to building the image less times.

Another option would be to have the task that builds it run only if e.g. integration'sDockerfile has changed using GH actions like this: enables conditional execution of workflow steps and jobs, based on the files modified by pull request, feature branch or in pushed commits.

@ppbaena
Copy link
Collaborator

ppbaena commented Jul 27, 2022

Perhaps we could improve it and just build the image for pushes to main

+1. In general, we should try to decrease CI times, but it makes sense for pushes to main, so we rely on what we're building is going to work later when releasing (do not wait to the release process to identify a dependency problem).

Copy link
Collaborator

@castelblanque castelblanque left a comment

Choose a reason for hiding this comment

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

Approving as discussed in Slack.

Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
@antgamdia antgamdia merged commit 24eab95 into main Aug 24, 2022
@antgamdia antgamdia deleted the 2792-buildCIRunner branch August 24, 2022 11:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Build and push the integration image during the CI
4 participants