Rename {commit} to {build_commit}; {commit} now refers to triggering commit#64
Rename {commit} to {build_commit}; {commit} now refers to triggering commit#64yarikoptic merged 1 commit intomasterfrom
{commit} to {build_commit}; {commit} now refers to triggering commit#64Conversation
| as ``{build_commit}``. For pull request builds on | ||
| Appveyor, this is the head of the PR branch. For pull | ||
| request builds on Travis, this is ``UNK``, as the API does | ||
| not expose the original commit. |
There was a problem hiding this comment.
but I still hope we workaround as discussed in #55 (comment), right?
There was a problem hiding this comment.
If you mean pulling PR branches from GitHub, I consider that overkill.
There was a problem hiding this comment.
but we do not have a better solution, do we?
The only other workaround I see is particular to DataLad setup since would require Appveyor run (now that we know that merge is done by github so the same across CIs) is to take information from Appveyor run which knows the commit for the build_commit and use for all CIs. Might also be needed/desired to establish persistent cache of knowing such mappings from build_commit to commit.
There was a problem hiding this comment.
The best alternative I can think of is querying the GitHub API for information on the PR, checking whether the merge commit is the same as the build commit, and, if so, using the head commit listed there. It'll require some rewriting of the code that I'd prefer to do in a separate PR.
There was a problem hiding this comment.
ok, thank you, let's proceed then
2 participants
Closes #55.