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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible misleading prer commit history #73

Open
michaelschiff opened this issue Jul 15, 2021 · 0 comments
Open

Possible misleading prer commit history #73

michaelschiff opened this issue Jul 15, 2021 · 0 comments

Comments

@michaelschiff
Copy link
Collaborator

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:

bazel test //...
prer

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)

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

No branches or pull requests

1 participant