Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/krel/cmd/ff: Initial commit of Go-based branchff tool #869
Here's the directory structure:
cmd/ ├── krel │ ├── BUILD.bazel │ ├── cmd │ │ ├── BUILD.bazel │ │ ├── ff.go │ │ └── root.go │ └── main.go pkg/ ├── util ├── BUILD.bazel ├── common.go └── git.go
After mulling this over for a bit, I decided we should get at least two things out of this:
This is still pretty rough, but it's at least in a good place to merge the structure in and iterate! :)
Signed-off-by: Stephen Augustus firstname.lastname@example.org
saschagrunert left a comment
hasheddan left a comment
Assuming we are good with deferring tests to a future iteration (which seems fine considering we don't plan to be using this in a production setting until the tool is more robust) then LGTM!
@justaugustus: you cannot LGTM your own PR.
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
[APPROVALNOTIFIER] This PR is APPROVED
The full list of commands accepted by this bot can be found here.
The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing
hoegaarden left a comment
While I really appreciate all the work and thoughts that are going into re-writing the tools in go, I am abit concerned about the general direction:
This seems to be generally go int o a direction of a monolithic tool for all the release things. I think it would be more useful to break the release tools apart. What do I mean by that:
# "monostep" / bakcbox-ish step - name: gcr.io/k8s-release-tools/krel args: [ "branchff", "--some-arg" ]
# get a thing, maybe not even git.k8s.io/kubernetes but some downstream vendor's repo - name: gcr.io/cloud-builders/git dir: src/k8s args: [ "pull", "$_K8S_RPEO", "--branch", "$_K8S_REPO" ] # only do the FF, nothing else - name: gcr.io/k8s-release-tools/branchff dir: src.k8s args: [ "$_FF_BRANCH" ] # push it upstream, wherever that is - name: gcr.io/cloud-builders/git dir: src/k8s args: [ "push", "upstream", "$_FF_BRANCH" ]
Now I want to run some tests on the branchff'ed branch (e.g. run e2e on kind or whatnot). Ideally that would be just adding a new GCB task, and not changing any code in
[....] # only do the FF, nothing else - name: gcr.io/k8s-release-tools/branchff dir: src.k8s args: [ "$_FF_BRANCH" ] # run some tests with the branchff'ed code - name: gcr.io/k8s-release-tools/kind-e2e args: [ "--k8s-src", "src/k8s" ] # push it upstream, wherever that is -- IFF the last step succeeded - name: gcr.io/cloud-builders/git dir: src/k8s args: [ "push", "upstream", "$_FF_BRANCH" ]
We're chatting in Slack (https://kubernetes.slack.com/archives/CJH2GBF7Y/p1572605765115500) w.r.t. @hoegaarden's review.
I think @hoegaarden 's concerns are valid. As new things are built there definitely should also be refactoring common things out of existing tools and instituting new splits in the tools and flow (as in the pull, branchff, push example). Those are more testable. It's totally conceivable one person wont see a pattern and other reviewers will, and ask for a refactor. We'll have to decide on a case by case basis if the refactor should happen before merge, be done by the original change proposer, or if it can follow and if somebody else can do it. The latter path will likely lead to more merge conflicts and rebase issues if folks aren't communicating.