prer implicitly assumes that is is run in strict order on the commits in the tracked branch. If commits execute in parallel (as is the case if its run in Github Actions) there is no guarantee that these will complete in order. This can lead to generated release notes missing commits from which they do contain changes, or referencing commits from which the changes are not included.
Let's assume prer is run in a GithubAction workflow with two steps:
Two commits which modify different services: A-B, and begin workflow execution. For the sake of example, assume the test step takes twice as long for A as it does for B. B completes, renders manifests, see changes and pushes to the PR branch all of the changes it produced (from both A and B). A completes, renders manifests, sees no changes and does not push to the PR branch. In this example changes from both A and B are included but the notes only contain a reference to B.
Taking the same example, but this time assuming that A and B modify the same service. In this case when A completes it will see changes (since B's changes include A's but A's dont include B's) and commit them. In this case, the release notes will reference both A and B (though in reverse order) however the changes in the output will only be build as of A. The changes from B will ultimately be included by the next commit (which plays out like the example above).
This scenario can be checked by prer. When it looks at the git log as of its current ref it can decide:
- if this commit is ahead of the commit for which im running - abort
- if this commit is behind the commit for which im running - include a log of all changes since then, not just the log for the commit im running.
Another possible outcome is that both run and checkout the accumulation branch as of the same commit. This will lead one of the executions to fail when it tries to push this branch. This could be addressed with a retry (which includes the logic described above)
prerimplicitly assumes that is is run in strict order on the commits in the tracked branch. If commits execute in parallel (as is the case if its run in Github Actions) there is no guarantee that these will complete in order. This can lead to generated release notes missing commits from which they do contain changes, or referencing commits from which the changes are not included.Let's assume
preris run in a GithubAction workflow with two steps:Two commits which modify different services:
A-B, and begin workflow execution. For the sake of example, assume the test step takes twice as long forAas it does forB.Bcompletes, renders manifests, see changes and pushes to the PR branch all of the changes it produced (from both A and B).Acompletes, renders manifests, sees no changes and does not push to the PR branch. In this example changes from bothAandBare included but the notes only contain a reference toB.Taking the same example, but this time assuming that
AandBmodify the same service. In this case whenAcompletes it will see changes (since B's changes include A's but A's dont include B's) and commit them. In this case, the release notes will reference both A and B (though in reverse order) however the changes in the output will only be build as of A. The changes from B will ultimately be included by the next commit (which plays out like the example above).This scenario can be checked by
prer. When it looks at the git log as of its current ref it can decide:Another possible outcome is that both run and checkout the accumulation branch as of the same commit. This will lead one of the executions to fail when it tries to push this branch. This could be addressed with a retry (which includes the logic described above)