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

Feature Request: support for testing BOSH releases. #126

Open
bikramnehra opened this issue Mar 12, 2020 · 2 comments
Open

Feature Request: support for testing BOSH releases. #126

bikramnehra opened this issue Mar 12, 2020 · 2 comments

Comments

@bikramnehra
Copy link

After switching over to kubecf, we feel there is a need to build a tool for developers which would make changing, building, deploying and testing changes in BOSH releases consumed by kubecf.

The anatomy of the current process is as follows:

  1. Clone the target BOSH release and make changes locally or push it to feature branch.
  2. Create a BOSH release using bosh create-release...
  3. Build its release image using fissile build release-images...
  4. Load that image into target system e.g: minikube or kind.
  5. Test the changes.
  6. If there are any issues then repeat step 1 through 6.

We have created a script to automate the aforementioned steps in the attached script - rebuild-brains.sh.txt, however its not generic and easily configurable. It would be great to see if this use-case can be accomodated in catapult.

@viccuad
Copy link
Member

viccuad commented Mar 13, 2020

thanks for opening this feature request!

I would just approach this the following way, but it's just a suggestion:

  • add a make bosh that checkouts the code if not present into the buildfolder and builds bosh.
  • add a make fissile (there's is already a target like that, maybe needs to be rewritten or a different name) that takes the artifacts inside a know path in the buildfolder and builds a fislle image, and uploads it

By making the targets idempotent, you can call them several times, and even like make bosh fissile of course.

This maybe should go in modules/scf/* or modules/extra/* for now, we can change it later.

To understand how the folder structure works and so, I recommend:
https://github.com/SUSE/catapult/wiki/Architecture-and-implementation#folder-structure-and-makefile-calls (the full page too)
Basically, create the makefile targets by looking at others, add scripts in modules/{scf,extra}/*.sh . On those scripts, all lines after . .envrc are executed with the environment (helm home, kubeconfig, bins) of the buildfolder of the cluster you are targetting.

I'm a bit stretched thin this week, feel like tackling this on your own?

Please tell us if you feel there's lacking docs on specific points, and don't hesitate to edit the wiki.

@mudler
Copy link
Contributor

mudler commented Mar 13, 2020

module-extra-fissile tries to do exactly this, but it is more a WIP, and still doesn't support all the backend that Catapult supports.

It needs definitely rework !

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

No branches or pull requests

3 participants