Skip to content

Conversation

@MeteorsLiu
Copy link
Contributor

@MeteorsLiu MeteorsLiu commented Apr 25, 2025

Changes for custom name:

  1. llpkgstore generate retrieve the package name from user-provided directory name for generating llcppg.cfg

  2. llpkgstore verfication retrieve the custom name from parsing the last element of module path in go.mod.

    For example,
    go.mod:

    module github.com/goplus/llpkg/libcjson
    
    go 1.22
    

    Its custom name is libcjson

  3. CheckPR finds out the real llpkg root directory containing llpkg.cfg / llcppg.cfg / go.mod from all changed files.

  4. The name in llpkg.cfg will be only used in llpkgstore.json.To clarify their difference, ClibName represents the name in llpkg.cfg while Name represent the actual name(custom name).

  5. Release-as: directive must match the custom name, not the clib name, like

directory structure:

-- libcjson
       |-- llpkg.cfg ...

Its Release-as: directive is like Release-as: libcjson/v1.0.0

Test: MeteorsLiu/llpkg#78
https://github.com/MeteorsLiu/llpkg/actions/runs/14690247173

@MeteorsLiu MeteorsLiu marked this pull request as ready for review April 27, 2025 06:46
@codecov
Copy link

codecov bot commented Apr 27, 2025

Codecov Report

Attention: Patch coverage is 23.45277% with 235 lines in your changes missing coverage. Please review.

Project coverage is 41.95%. Comparing base (237b8f9) to head (f8772e1).
Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
internal/actions/core.go 0.00% 175 Missing ⚠️
internal/actions/llpkg/package.go 65.51% 17 Missing and 3 partials ⚠️
internal/actions/api.go 0.00% 16 Missing ⚠️
internal/actions/actions.go 40.00% 12 Missing ⚠️
internal/actions/llpkg/type.go 0.00% 8 Missing ⚠️
cmd/llpkgstore/internal/verification.go 0.00% 4 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main      #60      +/-   ##
==========================================
+ Coverage   39.68%   41.95%   +2.27%     
==========================================
  Files          32       35       +3     
  Lines        1968     2052      +84     
==========================================
+ Hits          781      861      +80     
+ Misses       1089     1083       -6     
- Partials       98      108      +10     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@MeteorsLiu MeteorsLiu marked this pull request as draft April 27, 2025 08:20
@MeteorsLiu MeteorsLiu marked this pull request as ready for review April 27, 2025 08:42
@qiniu-x
Copy link
Contributor

qiniu-x bot commented Apr 28, 2025

[Git-flow] Hi @MeteorsLiu, There are some suggestions for your information:


Rebase suggestions

  • Following commits have duplicated messages

    fix: ci

    fix: ci

    fix: ci

Which seems insignificant, recommend to use git rebase command to reorganize your PR.

For other git-flow instructions, recommend refer to these examples.

Details

If you have any questions about this comment, feel free to raise an issue here:

Comment on lines +54 to +82
t.Run("one-go-file", func(t *testing.T) {
tempGoFileName := filepath.Join(demoDir, "x.go")
err := os.WriteFile(tempGoFileName, []byte(`package libcjson`), 0644)
if err != nil {
t.Error(err)
return
}
defer file.RemovePattern(filepath.Join(demoDir, "*.go"))

checkName(t, demoDir, false)
})

t.Run("multi-go-files", func(t *testing.T) {
tempGoFileName1 := filepath.Join(demoDir, "a.go")
err := os.WriteFile(tempGoFileName1, []byte(`package libcjson`), 0644)
if err != nil {
t.Error(err)
return
}
tempGoFileName2 := filepath.Join(demoDir, "x.go")
err = os.WriteFile(tempGoFileName2, []byte(`package cjson`), 0644)
if err != nil {
t.Error(err)
return
}
defer file.RemovePattern(filepath.Join(demoDir, "*.go"))

checkName(t, demoDir, false)
})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

table-driven test maybe is also better

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some tests require multiple files, these logics cannot be reused.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps could use a slice like []struct{name, content string} to hold each file’s name and content, and then simply loop over that slice to write out the files—it should work just fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in that case, simply use t.Run may be better, should we change to table-driven style?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What needs to be clarified is that t.Run is merely the mechanism for running subtests, whereas table-driven is a testing style—they are not mutually exclusive. In this case, we can embed t.Run within a table-driven setup to avoid repeatedly writing and cleaning up files.

and in this case,we actual have four similar test case,like,multi-go-files-fallback,no-go-files,multi-go-files,one-go-file,it have redunant logic here.

// cfg: Package configuration
func (d *DefaultClient) checkVersion(ver *versions.Versions, cfg config.LLPkgConfig) error {
func (d *DefaultClient) checkVersion(ver *mappingtable.Versions, pkg *llpkg.LLPkg) error {
// 4. Check MappedVersion
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some comment like this is deprecated

type LLPkg struct {
cfg config.LLPkgConfig

packageName string
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIT:indicate where to fetch the packageName to reduce misunderstandings—after all, this update introduces two package names

Suggested change
packageName string
packageName string // package name from go file.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And this field's type consist with PackageName as other struct is better ? the PackageName describe the custom name of llpkg.

Copy link
Contributor Author

@MeteorsLiu MeteorsLiu May 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exporting PackageName will make it mutable, which it's not expected. packageName should be only readable after initialization

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i mean packageName 's type change string to type PackageName

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants