Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect timestamp is used when drafting #222

Closed
jetersen opened this issue May 27, 2019 · 14 comments 路 Fixed by #541
Closed

Incorrect timestamp is used when drafting #222

jetersen opened this issue May 27, 2019 · 14 comments 路 Fixed by #541

Comments

@jetersen
Copy link
Member

jetersen commented May 27, 2019

@TimonVS seems that the GraphQL is using the date from the tag/release when it was created instead of using the date from when the tagged commit was created. That way, not all PRs will show 馃槩

https://github.com/jenkinsci/accurev-plugin

image
image

@jetersen
Copy link
Member Author

The latest release was created after merging #67,68,70

@TimonVS
Copy link
Member

TimonVS commented May 27, 2019

If I understand correctly, v0.7.19 was using an older commit as a target when the release was created?

@jetersen
Copy link
Member Author

yes 0.7.19 was tagged on this commit: jenkinsci/accurev-plugin@22689d7 dating back to Jan 22, 2019, 10:52 AM GMT+1

@jetersen
Copy link
Member Author

jetersen commented May 27, 2019

Probably unrelated to GraphQL now that I think about it.

I'd say it's still a "bug" it is using the date from the "latest" release instead of taking the date from the latest released tag 馃槗

@TimonVS
Copy link
Member

TimonVS commented May 28, 2019

How do you propose we fix this? Should we use the date of the tagged commit?

@jetersen
Copy link
Member Author

jetersen commented May 28, 2019

For me, using the tagged commit's date if available otherwise default to release's date, makes the most sense.

@jetersen
Copy link
Member Author

I'll try and get to this tonight. Unless your faster @TimonVS 馃槄

@TimonVS
Copy link
Member

TimonVS commented May 31, 2019

You can take this one if you'd like, the next issue I'll work on is #139, but I'll do that next week :)

@mangolas
Copy link

Has there been any work done on this yet? We stumbled on this problem as well on our release automation work. Tag would be better source of truth for change calculation than release date.

Why commits are searched with dates to begin with? Wouldn't it be better to use releases tag sha to calculate changed commits?

@jetersen
Copy link
Member Author

@mangolas no I never got time to fix it.

Yes it would make more sense to use last release tag sha to calculate changes.

@mangolas
Copy link

Ok, looks like one would only need to figure out how to change findCommitsWithAssociatedPullRequestsQuery at

module.exports.findCommitsWithAssociatedPullRequestsQuery = /* GraphQL */ `

@mangolas
Copy link

I tried to fix this. Looks like for sha based solution one would need to use git to do it, or at least I couldn't figure out how one could do it using GraphQL.

@jetersen
Copy link
Member Author

Here is a quick way of getting the commit sha from the object/tag

query { 
  repository(owner: "release-drafter", name: "release-drafter") {
    object(expression: "v5.2.0") {
      oid
      ... on Commit {
        oid
        history(first: 100, since: "2018-06-22T04:37:29Z") {
          nodes {
            oid
            messageHeadline
            author {
              user {
                login
              }
            }
            committedDate
          }
        }
      }
    }
  }
}

@mangolas
Copy link

mangolas commented Jan 31, 2020

Thanks, what I meant is that after one has tag sha in hand, how one could utilise it in order to limit pr history query as it only has 'since' and 'until' parameters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants