[release tool] Start go build and release tooling #8935
Conversation
+ minor cleanups
radTuti
added
docs-not-required
radTuti
force-pushed
the
go-release-pkg
branch
4 times, most recently
from
40970c2
to
ea3550f
Compare
TODO: fix test
- remove/address TODO comments - use embed for template files - update task names - update sshn - add release branch validations - add steps for non-release branch
outstandings - push operator manifest list - publish hashrelease using rsync
|
Some outstanding issues that I am hoping to defer to a new PR
Some additional optimization
EDIT: crossed out items are in this PR |
radTuti
force-pushed
the
go-release-pkg
branch
2 times, most recently
from
d73d11f
to
71538ee
Compare
| for scanner.Scan() { | ||
| line := scanner.Text() | ||
| for _, name := range hashreleaseNames { | ||
| if !strings.Contains(line, name) { |
There was a problem hiding this comment.
I think this is a little bit fragile. Instead of trying to make a diff of the existing file and the folders we just deleted, why can't we just build a new library file from the folders we know exist (i.e., all of the folders we didn't delete) and just overwrite what is there?
This would save us needing to fetch the current file, and would also save us needing to try and compare two sets of data (which is error prone).
There was a problem hiding this comment.
I considered that but it will still result in making a diff still because the content is in the format <hash> - <note> which we do have ability to recreate
release/internal/hashrelease/templates/pinned-version.yaml.gotmpl
Outdated
Show resolved
Hide resolved
radTuti
force-pushed
the
go-release-pkg
branch
2 times, most recently
from
b4a389f
to
eb9f2cf
Compare
…try URL + simplify to use default docker config
- update DevTagSuffix & RepoReleaseBranchPrefix config to be more consistent with rest of repo - Move RepoDefaultBranch from config to const in utils package - Add comments to where missing
There was a problem hiding this comment.
Looks good!
Plenty more to do here but I think we should get this one merged so we can get incremental improvements on top of it.
I think the most important next steps are:
- Actually switching hashreleases over to using this logic for OSS, disabling the old system.
- Incorporating the hack/release logic into this tooling to build "real" releases as well.
- Sharing as much code as possible between hashrelease / release.
In addition, some other things that we should track as tasks:
- Fix that Calico clones operator, which then clones Calico again as part of gen-versions.
- Consider hosting hashreleases elsewhere - e.g., S3
|
/merge-when-ready squash-commits |
radTuti
changed the title
radTuti
changed the title
Description
This is the core base of the go release tooling that will replace useage of Makefile and hack/release for a more cohesive process. It tries to adhere to standard go project layout
The borrows from the town in Bob the Builder: Ready Steady Build
Related issues/PRs
N/A
Todos
Release Note
I'm going to go with not required atm until it gets intergrated
Reminder for the reviewer
Make sure that this PR has the correct labels and milestone set.
Every PR needs one
docs-*label.docs-pr-required: This change requires a change to the documentation that has not been completed yet.docs-completed: This change has all necessary documentation completed.docs-not-required: This change has no user-facing impact and requires no docs.Every PR needs one
release-note-*label.release-note-required: This PR has user-facing changes. Most PRs should have this label.release-note-not-required: This PR has no user-facing changes.Other optional labels:
cherry-pick-candidate: This PR should be cherry-picked to an earlier release. For bug fixes only.needs-operator-pr: This PR is related to install and requires a corresponding change to the operator.