Open shaas opened 3 years ago
@jhesketh Please have a look
I'm a little unsure if building from git is the right place. We may carry patches and other nuances in OBS. I'm inclined to say that the correct method would be to:
* branch the devel or OBS project into your home repo, * pull in your git branch of github.com/SUSE/rook, * build in OBS * Point rookcheck at the built containers
This will ensure we are building in the same manner as the proper pipeline.
Thoughts?
My point is to test a self-built rook-container (this might be a branch of SUSE/rook or also rook/rook) against SES. Testing changes with your proposal would take ages.
I'm a little unsure if building from git is the right place. We may carry patches and other nuances in OBS. I'm inclined to say that the correct method would be to:
* branch the devel or OBS project into your home repo, * pull in your git branch of github.com/SUSE/rook, * build in OBS * Point rookcheck at the built containers
This will ensure we are building in the same manner as the proper pipeline. Thoughts?
My point is to test a self-built rook-container (this might be a branch of SUSE/rook or also rook/rook) against SES. Testing changes with your proposal would take ages.
Why would it take ages? It's a few more manual steps, but it at least allows us to use the same tooling as the release pipeline.
I'm a little unsure if building from git is the right place. We may carry patches and other nuances in OBS. I'm inclined to say that the correct method would be to:
* branch the devel or OBS project into your home repo, * pull in your git branch of github.com/SUSE/rook, * build in OBS * Point rookcheck at the built containers
This will ensure we are building in the same manner as the proper pipeline. Thoughts?
My point is to test a self-built rook-container (this might be a branch of SUSE/rook or also rook/rook) against SES. Testing changes with your proposal would take ages.
Why would it take ages? It's a few more manual steps, but it at least allows us to use the same tooling as the release pipeline.
This feature is really all about to test changes while the development process or e.g. bug hunting. This means adding additional steps makes it more complicated and adds more possible places of errors. But you are correct, in the end it needs to go the way you described. But IMO not for each and every dev-test I want to do "locally". (Also, adding this possibility does not hurt ;) )
Is this OK for you?
I'm a little unsure if building from git is the right place. We may carry patches and other nuances in OBS. I'm inclined to say that the correct method would be to:
* branch the devel or OBS project into your home repo, * pull in your git branch of github.com/SUSE/rook, * build in OBS * Point rookcheck at the built containers
This will ensure we are building in the same manner as the proper pipeline. Thoughts?
My point is to test a self-built rook-container (this might be a branch of SUSE/rook or also rook/rook) against SES. Testing changes with your proposal would take ages.
Why would it take ages? It's a few more manual steps, but it at least allows us to use the same tooling as the release pipeline.
This feature is really all about to test changes while the development process or e.g. bug hunting. This means adding additional steps makes it more complicated and adds more possible places of errors. But you are correct, in the end it needs to go the way you described. But IMO not for each and every dev-test I want to do "locally". (Also, adding this possibility does not hurt ;) )
Is this OK for you?
Well it adds a bit of complication and also the possibility for something to work in this environment but not OBS. Having said that, I'm fine with this. If you can fix up the tox issues we can merge it :-)
I'm a little unsure if building from git is the right place. We may carry patches and other nuances in OBS. I'm inclined to say that the correct method would be to:
* branch the devel or OBS project into your home repo, * pull in your git branch of github.com/SUSE/rook, * build in OBS * Point rookcheck at the built containers
This will ensure we are building in the same manner as the proper pipeline. Thoughts?
My point is to test a self-built rook-container (this might be a branch of SUSE/rook or also rook/rook) against SES. Testing changes with your proposal would take ages.
Why would it take ages? It's a few more manual steps, but it at least allows us to use the same tooling as the release pipeline.
This feature is really all about to test changes while the development process or e.g. bug hunting. This means adding additional steps makes it more complicated and adds more possible places of errors. But you are correct, in the end it needs to go the way you described. But IMO not for each and every dev-test I want to do "locally". (Also, adding this possibility does not hurt ;) ) Is this OK for you?
Well it adds a bit of complication and also the possibility for something to work in this environment but not OBS. Having said that, I'm fine with this. If you can fix up the tox issues we can merge it :-)
Fixed!
Thank you.
This PR adds the possibility to test self-built rook containers against SES
Signed-off-by: Stefan Haas shaas@suse.com