expose "commit_time"

[yarikoptic]

Continuation to #40:
so there is a "commit timestamp" -- could you expose it as well please in UTC time zone (so if commits come from different contributors within the PR we still could sort them), probably in ISO8601 i.e. YYYY-MM-DDThh:mm:ssZ ?

[yarikoptic]

then I would use {commit_time}-{abbrev_commit}/ and that would allow to get the likely sorting to get the "latest" of the commits in a PR

[jwodder]

@yarikoptic Problem: When Travis builds a tag, it reports the committed_at field as null.

[yarikoptic]

and it doesn't have a separate run and/or record on the corresponding commit itself?

[jwodder]

@yarikoptic There is a separate build for the pushing of the tagged commit, but the only thing linking them is that they have the same commit ID. There's also no guarantee that there would be build for the commit, as a developer could push the tagged commit in the middle of several other commits.

[yarikoptic]

ok, let's think about it

[yarikoptic]

as a workaround I think I could just use time of the build and have eg. {hour}{minute}{second}-{commit_abbrev} so I would get a logical likely sorting for within a PR. Suboptimal (will differ between CIs etc) but provides a way forward.

an idea (rejected by the end): A possible implementation for commit_time could be: clone and cache locally (and regit fetch upon rerun) that repo with all the PRs heads : I have

[alias]
    add-fetch-pulls = !git config --add remote.origin.fetch '+refs/pull/*:refs/pull/origin/*' && git fetch origin

then we could have access to any information needed about a commit AFAIK as long as that commit is still available though -- might have been purged / rewritten etc, so wouldn't be robust for fetching older logs

[yarikoptic]

as a workaround I think I could just use time of the build and have eg. {hour}{minute}{second}-{commit_abbrev} so I would get a logical likely sorting for within a PR. Suboptimal (will differ between CIs etc) but provides a way forward.

or will those times differ across jobs/workflows within the same commit+ci build @jwodder ?

[jwodder]

@yarikoptic The timestamp is taken from the workflow run (GitHub) or build (Travis/Appveyor). If multiple runs/builds are triggered for the same commit, they may have different timestamps. However, for Travis & Appveyor, all jobs belonging to a given build will share the same timestamp.