Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Introducing changelog generation tool #264
Introducing changelog generation tool #264
Changes from 3 commits
97a64c0
47c7d92
7d016de
d8046e7
2bfafc1
62d5e67
eb0adee
9f091be
cc60d0d
d604039
de6e47e
6d34444
7ce3d02
3d7f69d
6b00945
7ffa993
d3a4a52
f7c537f
9acb082
6e67e79
d48641f
207e590
a6692fb
c94b5c0
f4a6950
62ba564
2c75aae
86a40ae
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
@fheinecke I added the
go.mod
at the top of the directory to get my code in a working state. I wasn't quite sure what the intention was for the Go module. I did see in the file structure that there were somego.mod
files in nested directories. To me that seemed kind of odd because I'd imagine that most of the code would be versioned together (or at leastlibs
andtools
). Withgo.mod
setup in different directories we would have to use Go workspaces to manage the dependency between modules.Oh also the
go.sum
is currently messed up a bit I'll have to fix it.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 typo'd this in the original PR for that RFD. Each project should have their own go.mod/sum files, though they shouldn't be under the
workflows
directory. Generally we don't want all the code in this repo versioned together. It's intended to be used as a collection of unrelated projects, so we don't want that direct coupling. This includes libraries, as we would like to avoid needing to update all dependents immediately if a library interface changes.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 don't think this is correct still. We should have a go.mod per tool I feel, not a single one for the entire repo or one for each package.
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.
Oh I think I have a better idea of what is wanted here then. I'm thinking then it should be a module for libs as a whole and a module for each tool.
For example in this change two modules will be created.
Tools are versioned separately. Everything under
libs
will be versioned together.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.
Btw I implemented the above. Check it out and let me know if it seems right.
Large diffs are not rendered by default.
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.
Since we're moving this to shared-workflows, we should use github package we use in other tools here rather than calling CLI: https://github.com/gravitational/shared-workflows/blob/main/bot/internal/github/github.go
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.
Something to mention is that packages cannot import
internal
unless they're nested in the same parent directory asinternal
. I'd imagine that everything under theinternal
package would be moved up underlibs
.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.
Yea it'd need to move to a new module under
/libs
. Probably just the github package for now though, to avoid too much scope creep.