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

Use triple-dot diff YAML in CI #41222

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

cottsay
Copy link
Member

@cottsay cottsay commented May 16, 2024

The current diff mechanism in rosdep_repo_check uses a 'bare' diff with the configured upstream ref. If the upstream ref contains additional commits which are not present in the PR's HEAD which remove lines of YAML, this bare diff will report those lines as 'added' when comparing the PR to the target, which is certainly not what we want to do.

We can use the git triple-dot notation to compare only commits which are present in HEAD but not in target, effectively comparing between the PR's HEAD and the merge base with the target branch, instead of the target branch directly.

One disadvantage of this approach is that uncommitted changes are no longer considered part of the diff. For this reason, I'm only adding the triple dot during diffs with the specifically-configured upstream branch and not the 'fallback' comparison with origin/master. This way, you can still invoke the test locally without the need to commit the changes first.

Fixes part of #31439

@cottsay cottsay self-assigned this May 16, 2024
@cottsay cottsay changed the title Use triple-dot do diff YAML in CI Use triple-dot diff YAML in CI May 16, 2024
The current diff mechanism in rosdep_repo_check uses a 'bare' diff with
the configured upstream ref. If the upstream ref contains additional
commits which are not present in the PR's HEAD which remove lines of
YAML, this bare diff will report those lines as 'added' when comparing
the PR to the target, which is certainly not what we want to do.

We can use the git triple-dot notation to compare only commits which are
present in HEAD but not in target, effectively comparing between the
PR's HEAD and the merge base with the target branch, instead of the
target branch directly.

One disadvantage of this approach is that uncommitted changes are no
longer considered part of the diff. For this reason, I'm only adding the
triple dot during diffs with the specifically-configured upstream branch
and not the 'fallback' comparison with origin/master. This way, you can
still invoke the test locally without the need to commit the changes
first.
@cottsay
Copy link
Member Author

cottsay commented May 16, 2024

Oh lame. I'm pretty sure this doesn't work because we're using a shallow clone for "upstream". Without the full history, we can't compute the merge base to figure out what changes are present in what trees, so the best we can do is continue to diff the blobs without considering history. I don't think we have the information we need to answer the question we're asking here, at least not without changing some of the more core CI setup.

We're pretty backed into a corner here. I'm inclined to leave the existing code as-is and address this more directly in the next iteration of the rosdep_repo_check.

@nuclearsandwich
Copy link
Member

One disadvantage of this approach is that uncommitted changes are no longer considered part of the diff. For this reason, I'm only adding the triple dot during diffs with the specifically-configured upstream branch and not the 'fallback' comparison with origin/master. This way, you can still invoke the test locally without the need to commit the changes first.

This seems like a good baseline heuristic to me.

I'm pretty sure this doesn't work because we're using a shallow clone for "upstream". Without the full history, we can't compute the merge base to figure out what changes are present in what trees, so the best we can do is continue to diff the blobs without considering history.

We could get a bit over-engineer-y and do repeated shallow clones (depth = 8, depth = 16, depth = 32, ..) until we find a merge base

There are also other tools to limit what we actually need to fetch until just-in-time: https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/

That being said, an initial clone of ros/rosdistro outright is 100MiB which at 30MiB/s is ~3.3s of GitHub's bandwidth and energy. I think the python setup for the test takes 10x that time. I'd be fine with a non-shallow clone.

@nuclearsandwich
Copy link
Member

We're pretty backed into a corner here. I'm inclined to leave the existing code as-is and address this more directly in the next iteration of the rosdep_repo_check.

What do you have in mind that changes things in a future iteration?

Copy link

This PR hasn't been activity in 14 days. If you are still are interested in getting it merged please provide an update. Otherwise it will likely be closed by a rosdistro maintainer following our contributing policy. It's been labeled "stale" for visibility to the maintainers. If this label isn't appropriate, you can ask a maintainer to remove the label and add the 'persistent' label.

@github-actions github-actions bot added the stale Issue/PR hasn't been active in a while and may be closed. label May 31, 2024
@nuclearsandwich nuclearsandwich added persistent Issue/PR won't be marked as stale if inactive for a while. and removed stale Issue/PR hasn't been active in a while and may be closed. labels Jun 4, 2024
Copy link
Member

@nuclearsandwich nuclearsandwich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Outstanding questions don't actually block merging this improvement.

@cottsay
Copy link
Member Author

cottsay commented Jun 4, 2024

Outstanding questions don't actually block merging this improvement.

I'll need to switch away from the shallow clone for this to work. I need to get an idea of how much that will cost.

@mjcarroll
Copy link
Member

@cottsay is this still relevant with the new bot?

@cottsay
Copy link
Member Author

cottsay commented Nov 25, 2024

is this still relevant with the new bot?

The new automation Does This Right. I'd like to keep this open for just a LITTLE while longer until I finish moving more of the existing pytest checks into rosdistro-reviewer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
persistent Issue/PR won't be marked as stale if inactive for a while.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants