This message was deleted.

More details In our CI/CD pipeline we construct version tags based on commit timestamp, e.g.

backend:2023.09.21-1645-49078d2

(a mix of

git show -s --format=%aI

and

git rev-parse --short HEAD

). Seeing a datestamp a day (or more - with weekends and holidays) prior to when the PR actually entered the CD pipeline can be confusing when debugging things. We can rethink how we construct the version tags, but the simplicity / reproducibility / idempotence of the current solution is very nice.

Git has two timestamps on a commit — it sounds like you want the Committer timestamp instead of the Author timestamp?

Ohh, that’s promising! Let me see if I can get it to work then, though I still fear a fast forward merge which AFAIK repoints trunk at a commit might leave even the “commiter timestamp” unchanged.

For "fast forward" merges, we will try to avoid touching the commit if we can (if it doesn't need to be rebased or squashed). This allows us to parallelize CI runs for stacked changes, which can significantly speed up merges. So if a PR happens to not require a rebase when we process it in the MQ, you are correct that it could be merged with the original commit data (including the timestamps). Currently, I think the only way around this would be to disable fast forward merge. But we could look into having an option to ensure we update the commit timestamps at the time the MQ processes the commits regardless of whether they need to be rebase on trunk or not. This would result in an extra CI run that you weren't seeing before, but I think would get the behavior you are describing.

Thanks David!

But we could look into having an option to ensure we update the commit timestamps at the time the MQ processes the commits regardless of whether they need to be rebase on trunk or not.

That would be amazing! I assume the CI time overhead shouldn't be too bad there either. Would love to be kept in the loop on the status here, thanks! 🙂 I imagine other MQ users might suffer from the "yesterday's commit time" problem at times too.

This would result in an extra CI run that you weren't seeing before

We could probably work around this by pushing through CI checks once we know they've passed?

FYI, we've migrated to

git show -s --format=%cI

everywhere now anyway – thanks for pointing it out!

Happy to help!