-
Notifications
You must be signed in to change notification settings - Fork 1
Upgrade to 1.24 #45
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
Upgrade to 1.24 #45
Conversation
f6a0eb7
to
0d593fb
Compare
b0557a3
to
1a83a03
Compare
435f658
to
38eadd2
Compare
aec25eb
to
71018de
Compare
README.md
Outdated
Following this practice removes the need for dual maintenance of dependency versions in the builder image. It also produces a build cycle that is significantly faster. | ||
|
||
Cross repository builds in docker while using go.work to refer to locally modified sources don't work. And this setup is essential for an efficient workflow. | ||
1. Execute the `go get -tool` command to add the package to the go.mod file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, where do I do this ? the deleted lines tell me how to do this for existing api support. Do we have taskfile support for doing this at the right spot ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The is a manual process that sets up the go.mod file - it should not be executed in any workflow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we add a new tool the we would exeute the go get -tool command for that tool once
this changes go.mod - after that tool management is transparent
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then I think we need a task rune for that please
|
||
### Use an avid/src/go.work | ||
|
||
First point avid at a clone of this repo so that it's imports will resolve |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain how we build against locally changed sources without committing and pushing ?
I don't know if go.work is necessar nor not post this change. But I do want to be able to build forestrie, avid and avid-events against a locally modified common-api.
With this change (and with particular reference to the deleted instructions) how do I do that ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dont think anything has changed in this regard
I exercised the workflow commands in this README and all just worked.
The only change is how tools are managed not how they are used
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, can you please test that and show some evidence of it in the PR. but sounds good thanks
README.md
Outdated
The general use entry points all use Docker and do not support efficiently and | ||
iteratively developing avid and other dependents against a local clone of this | ||
repo. | ||
This repo use the go-task tool and also the go toolchain. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You need to explain how go-task tool impacts the work flow
@@ -68,15 +47,11 @@ If you want to iterate on *just* the helper go code and there tests, do one roun | |||
|
|||
Then just iterate using `task apis:generate` and `task apis:test` | |||
|
|||
#### For avid |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume your not saying "we don't support this for avid" rather you are saying it works for any consuming package ? Do I have that right ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes - the deleted text was written when we only had avid
its any repo now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#### For avid | |
#### For any repo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will do
71018de
to
0e4d112
Compare
0e4d112
to
4f72f68
Compare
Remove rotten protoc-gen-doc Upgrade tools version to correspond to those in general codebase. Use new avid-tools Add .gitattributes Add dependabot.yml Install protoc-gen-doc binary in ci workflow Use new go get -tool command to set tools and remove tools.go Use 'go install tool' to install all tools. Move all helper go code into separate directory and copy over when appropriate otherwise installing tools fails with unknown import. AB#10624 Signed-off-by: Paul Hewlett <[email protected]>
4f72f68
to
e53b532
Compare
obsolete |
Remove rotten protoc-gen-doc
Upgrade tools version to correspond to those in general codebase.
Use new avid-tools.
Add .gitattributes
Add dependabot.yml
Install protoc-gen-doc binary in ci workflow
Use new go get -tool command to set tools and remove tools.go
Use 'go install tool' to install all tools.
Move all helper go code into separate directory and copy over
when appropriate otherwise installing tools fails with unknown
import.
Testing
The github-action ci.yml executes cleanly and visual inspection of exported files is correct.
AB#10624