Use goreleaser to build binaries #601
Conversation
k8s-ci-robot
added
do-not-merge/work-in-progress
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: justinsb The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
needs-triage
|
This issue is currently awaiting triage. If the repository mantainers determine this is a relevant issue, they will accept it by applying the The 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. |
k8s-ci-robot
added
the
size/L
| set -e | ||
| set -x | ||
|
|
||
| source $(git rev-parse --show-toplevel)/tools/common |
There was a problem hiding this comment.
This assumes #599 , I've split it out for now
.goreleaser.yaml
Outdated
| - main: ./cmd/gke-gcloud-auth-plugin | ||
| id: gke-gcloud-auth-plugin | ||
| no_unique_dist_dir: true | ||
| binary: gke-gcloud-auth-plugin/{{.Os}}-{{.Arch}}/{{.Tag}}/gke-gcloud-auth-plugin |
There was a problem hiding this comment.
These paths are surprising, but I'm trying to mirror the current GCS structure.
I would have thought that this structure would be more logical:
{{.Tag}}/{{.Os}}-{{.Arch}}/gke-gcloud-auth-plugin
or
gke-gcloud-auth-plugin/{{.Tag}}/{{.Os}}-{{.Arch}}/gke-gcloud-auth-plugin
But in general the current structure implies to me that we're tagging the different architectures separately, which is ... not what we're doing.
There was a problem hiding this comment.
@ndixita @BenTheElder do you remember why we ended with these structures?
There was a problem hiding this comment.
I think they were just trying to get something hosted. I don't have strong opinions other than they should be predictable and uniquely identifiable
There was a problem hiding this comment.
I'm going to switch to something that is more conventional: project name (because we want to think of these as separate projects, even though they share a repo), then tag, then architecture.
The current staging buckets are basically broken anyway, they upload the binaries named by SHA, which I don't think work with our promotion tools or any tools I've seen in the ecosystem.
|
Justin ping me once you need reviews |
justinsb
force-pushed
the
with_gorelease
branch
2 times, most recently
from
67a4cb4
to
a97e20f
Compare
justinsb
changed the title
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
|
In the interests of cleaning things up as we go, I switched to follow the more conventional file paths. I don't think it's breaking because I think today's file paths are incompatible with our promotion tools anyway. This doesn't actually do the upload anyway, so I'd argue it's purely additive. Want to take another look @aojea ? |
Similar to adopting ko for images, we set up a parallel build to the bazel build, with the intention of using that with the normal OSS "push-to-staging and promote" workflow.
justinsb
force-pushed
the
with_gorelease
branch
from
a97e20f
to
8feeead
Compare
|
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
k8s-ci-robot
added
the
lifecycle/stale
|
The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
k8s-ci-robot
added
lifecycle/rotten
Continuing the idea of a parallel simpler build, leveraging goreleaser