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

Introduce git branches in the bundle-kubeflow repo #743

Open
Tracked by #841
kimwnasptd opened this issue Nov 17, 2023 · 2 comments
Open
Tracked by #841

Introduce git branches in the bundle-kubeflow repo #743

kimwnasptd opened this issue Nov 17, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@kimwnasptd
Copy link
Contributor

What needs to get done

Like the rest of the Charm repos, I propose that we should have dedicated branches for releases in this repo.

Why it needs to get done

Having a flat architecture means that we'll need to create release folders for everything. This results in

  1. Needing dedicated GH action files (publish, run uats etc) for different releases
  2. Copies of the testing code
  3. Copies of the different bundles

On the other had if we'd use branches then the structure of this repo would be hugely simplified and different branches would just contain the code that is needed (and dependency versions like microk8s, juju) in each branch.

Items we need to consider though for this work are:

  1. The release handbook with manual steps on when to create the branches
  2. Which docs would we need to update
  3. Any files that are hardcoding file paths that require release folders
@kimwnasptd kimwnasptd added the enhancement New feature or request label Nov 17, 2023
@ca-scribner
Copy link
Contributor

ca-scribner commented Nov 21, 2023

Not a blocker but something to consider - we maintain a test suite that has shared code across multiple versions (to reduce the effort of actually maintaining it). For example, test code for 1.7 is reused for 1.8, etc. If we adopted branches as proposed, some possible ways forward are:

  • backport changes to relevant branches
  • moving any common testing code into a separate, generic repo, and importing it as a dependency here

Also it isn't that using branches removes the need to have copies of our testing code and different bundles, it just bookkeeps them differently (the copies are in branches, not in main). Not saying branches are better or worse, just saying its a bookkeeping change rather than removing something entirely

@ca-scribner
Copy link
Contributor

I don't think our other repos function exactly as described in the original post. Our charm repos:

  • track branches in our repos represent the code currently in trackX/edge
  • Charmhub releases (which we document with corresponding releases in our gh repos) represent everything in beta/candidate/stable.

Its a bit of a hybrid, and I dont know if its clear what the analagous organisation would be for the bundle kubeflow repo. Maybe each release has a branch, but then that branch has the current version of all four risks rather than just edge?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Labeled
Development

No branches or pull requests

2 participants