Attempt to fix #151

[katyo]

No description provided.

[wangfenjin]

I test the code, result.repository.ref this is null, so result.repository.ref.target throws cannot read property 'target' of null

[katyo]

Looks really strange. Seems Github's graphql API has unexpected behavior in some rare cases.

[katyo]

Could you try again?

[wangfenjin]

Error: Unable to retrieve history for path 'libduckdb-sys' (res: {"repository":{"ref":null}})

[wangfenjin]

I think we can disable these logic, and just check the published version?

https://github.com/wangfenjin/publish-crates/blob/926eb3732ca6823d0876df86520f0f11e41c0cf2/src/main.ts#L58-L70

[wangfenjin]

https://github.com/wangfenjin/duckdb-rs/pull/23/checks?check_run_id=3575158281

[wangfenjin]

Seems related to inner package?

[katyo]

@wangfenjin Seems the problem related to $GITHUB_REF variable value.

API request:

query lastCommitDate($owner: String!, $repo: String!,
                     $ref: String!, $path: String!) {
    repository(owner: $owner, name: $repo) {
        ref(qualifiedName: $ref) {
            target {
                ... on Commit {
                    history(first: 1, path: $path) {
                        edges {
                            node {
                                committedDate
                            }
                        }
                    }
                }
            }
        }
    }
}

Request data:

{
  "owner": "wangfenjin",
  "repo": "duckdb-rs",
  "ref": "refs/remotes/pull/23/merge",
  "path": "libduckdb-sys"
}

Response from GitHub:

{
  "data": {
    "repository": {
      "ref": null
    }
  }
}

We may try to find solution or bypass this logic as a quick fix.

NOTE: This check prevents forgetting to change version of package which contents changed since previously published version so bypassing this logic little bit dangerous.

[katyo]

@wangfenjin At all I think publishing packages using pull-requests is not so good idea in any case. I suggest you use tags for that purpose.

[katyo]

Seems we can get last path modification time locally via git.

[wangfenjin]

@wangfenjin At all I think publishing packages using pull-requests is not so good idea in any case. I suggest you use tags for that purpose.

Agree. For that because it's the first time using github action to release, so I want to make it work before merge the code.

So you mean, after merge to master all things should work? What about the dry-run mode, is it work in PR? Because every PR should run the dry-run mode

[katyo]

@wangfenjin Currently I'm on a way to change implementation of this feature. New implementation will deal with local clone of repository directly without using octokit. Also it will checks contents of packages more fine grained i.e. file by file.
Maybe I will release v2 of this action. It shall works as expected in your case.

[katyo]

Closed in favor of #311

[katyo]

@wangfenjin Could you test pr #311 ?