Comments (6)
I spoke with @zhangtbj on this, I think being able to specify which strategies to run during e2e tests isn´t ideal, e2e tests should run everything. In the meantime, we can live with a minor patch from our side to disable the two strategies we cannot run successfully(buildah and s2i).
However, I think we would like to have the flexibility to avoid running the following pieces during e2e tests, due to our specific tenant environments and the way where we run components:
- Avoid running the
framework.AddToFrameworkScheme
, see lines - Avoid running the
ctx.InitializeClusterResources
, see lines - Avoid running the
e2eutil.WaitForOperatorDeployment
, see lines - Avoid running the
createClusterBuildStrategy
calls for all strategies, see lines - Avoid running the
tekton task verification
, see lines , this is because we cannot check the tekton resource on the tenant namespace.
All of the above can be done with a new env variable, I can do this easily(I think), @sbose78 pls let us know what u think. With this we will only patch to skip those two strategies, and once we resolved the issues, we will not longer need to patch anything. Also, this will not break your setup.
from build.
@sbose78 let me know about the above.
from build.
If I understand this correctly,
-
There are specific strategies that we would want skipped.
-
There are specific things we would not want to validate. Example, tekton resources.
Can we make our tests resilient enough to understand that specific validations may be skipped?
Which user do you run these tests as in your internal environment?
- In my opinion we should create "environment templates" in our upsteam CI for running tests in such environments.
- Make our tests smarter to skip validating Specific things based on the environment.
from build.
Agree.
Because our Production system is ready and deployed at the beginning (build controller and cluster build strategies). So every time, we just need to update the controller and re-run the e2e tests.
- So require to deploy the builder controller and cluster build strategies is not good for our production system upgrade.
- If I deploy a test env and already deploy above required resources, I would like to run the e2e tests with a similar parameter
--skip-deploy
to JUST run the e2e tests directly.
from build.
But ....
It issues is used to extract the current test code as the common functions
, so that each test can reuse and share together.
I think later, we can create a new issue to separate these two requirements.
from build.
This basic requirement is resolved by using this PR:
#120
Close this first and will open the advanced issue for the new requirement.
Thanks!
from build.
Related Issues (20)
- [FEATURE] Move Readme Try It Section to BETA HOT 5
- [FEATURE] v0.13 Bump Tekton and Kubernetes dependencies
- [FEATURE] Document usage of OCIArtifact source type HOT 2
- [BUG] Endless reconcile of build when strategy kind is unknown
- [SHIP-0038] Use Release Branches for Releasing HOT 4
- [tech-debt] Release Workflow Action No Longer Maintained
- [BUG] BuildStrategy: Cannot Use Context Dir as Working Directory HOT 4
- [FEATURE] Conditional step HOT 1
- [FEATURE] Build Strategy from Tekton Task/Pipeline HOT 1
- [BUG] Automatic release README update needs to be fixed HOT 4
- [FEATURE] Provide Storage Version Migration from v1alpha1 to v1beta1 HOT 1
- [BUG] git clone issue on newest Git version HOT 3
- [FEATURE] Windows Containers/Node Support HOT 2
- [FEATURE] Support another technology to define and orchestrate the image creation inside a pod HOT 2
- [BUG] Unit tests run fine with `go test`, but fail when used with Ginkgo CLI HOT 1
- SHIP-0039: Allow node selector on `Build` and `BuildRun` to be set HOT 7
- SHIP-0039: Allow tolerations on `Build` and `BuildRun` to be set
- SHIP-0039: Allow custom scheduler to be used for `Build` and `BuildRun`
- [FEATURE] Establish a release cadence based on Tekton LTS releases HOT 2
- [BUG] The container name for shipwright build webhook doesn't match the environment variable HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from build.