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

Get branch name from env var (#74) #76

Closed
wants to merge 4 commits into from
Closed

Get branch name from env var (#74) #76

wants to merge 4 commits into from

Conversation

alextu
Copy link
Member

@alextu alextu commented Jul 15, 2022

The implemented behavior will try to get the branch name from the env var first (even if the Git CLI is available).
This PR includes some refactoring to rely on Optional.

@alextu alextu requested a review from runningcode July 15, 2022 12:38
Copy link
Member

@runningcode runningcode left a comment

Choose a reason for hiding this comment

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

looks good, i have mostly comments around the GitMetadata class but I can't think of the best way to improve it in my head.

if (isNotEmpty(gitRepo) && isNotEmpty(gitCommitId)) {
if (gitRepo.contains("github.com/") || gitRepo.contains("github.com:")) {
Matcher matcher = Pattern.compile("(.*)github\\.com[/|:](.*)").matcher(gitRepo);
if (gitRepo.isPresent() && gitCommitId.isPresent()) {
Copy link
Member

Choose a reason for hiding this comment

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

the previous logic would also ensure the resolved value is not empty, could we also check that here?

Copy link
Member Author

Choose a reason for hiding this comment

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

I could but the current code implicitly already handles the empty strings in the nested ifs

Copy link
Member Author

Choose a reason for hiding this comment

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

I've hardened this by making sure having an empty string does not happen (see GitMetadataResolver logic and test)

src/main/java/com/gradle/GitMetadata.java Outdated Show resolved Hide resolved
this.isGitInstalled = isGitInstalled;
}

static GitMetadata given(boolean isGitInstalled) {
Copy link
Member

Choose a reason for hiding this comment

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

i'm not a fan of the name given here for the static constructor method since it isn't very descriptive when used inline.

Copy link
Member Author

Choose a reason for hiding this comment

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

it's been removed with the builder changes


import static com.gradle.Utils.execAndGetStdOut;

class GitMetadata {
Copy link
Member

Choose a reason for hiding this comment

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

I like having a class here encapsulate the logic for fetching the gitmetadata but it seems to me that the encapsulation is not fully complete and requires the caller to know the implementation details. for example you must know you need to pass either the cmd args or the value supplier depending on whether git is installed or not.

Copy link
Member Author

Choose a reason for hiding this comment

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

That's a good point, actually I made a change to be more flexible and silently accept the case: git is installed but no cmd is provided.

@alextu alextu force-pushed the atual/fix-branch branch 3 times, most recently from a4ea7f7 to 4b70d9d Compare July 25, 2022 15:09
@alextu alextu requested a review from runningcode July 25, 2022 15:10
return Optional.empty();
}

static class GitMetadataBuilder {
Copy link
Member

Choose a reason for hiding this comment

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

in the current state, this feels a bit more like a Factory to me :D

I'm trying to think of the best way to structure this though. i haven't really fully thought it out but the current implementation seems like it could be simplified.

Copy link
Member

Choose a reason for hiding this comment

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

yeah, i think a factory would make sense since it would remove the case of the .build().resolve() that is used in every case.

Copy link
Member Author

Choose a reason for hiding this comment

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

How about the latest refactoring a bit less expressive but simple: a resolver that just resolves :))

Copy link
Member

@runningcode runningcode left a comment

Choose a reason for hiding this comment

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

Looks good to me aside from the testing change.

We have intentionally kept this repository free of tests in order to make it as simple as possible for customers to copy and understand. I am not saying we should keep or remove the tests but I think it needs to be discussed before making a change like this to add these.

@etiennestuder also wants to take a look at this so I'll let him have the final review.

@etiennestuder
Copy link
Member

I would hold off on merging this PR until we have resolved the config caching issue explored in this PR and raised in this issue.

I believe we need to make significant changes to where we read the env vars in order to not cause constant config cache invalidation. Depending on how that will be solved, it might require a different approach/implementation.

@runningcode
Copy link
Member

Closing PR for now. Let's re-open after making the CC compatibility changes.

@@ -381,24 +369,15 @@ private boolean isGitInstalled() {
return execAndCheckSuccess("git", "--version");
}

private String getGitBranchName(Supplier<String> gitCommand) {
private Optional<String> getGitBranchNameFromEnv() {
Copy link
Member

Choose a reason for hiding this comment

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

Why is GitHub actions not included?

@etiennestuder
Copy link
Member

etiennestuder commented Mar 1, 2023

@erichaagdev how often does this actually come up? We have 1 case for sure which is the one that triggeed this PR. Before time is spent on this PR, we need to be certain is worth the added complexity to itegrate and maintain. 1 single customer would not justify it.

@runningcode
Copy link
Member

I don't think it was intentionally left out.
I think we should also include GitHub actions but this PR is very, very old. This would improve our samples and our builds. For example here

@erichaagdev
Copy link
Member

@etiennestuder This would address the issue where CI checks out the branch in a detached HEAD state. In this case,
git rev-parse --abbrev-ref HEAD returns HEAD rather than the branch name.

This is the case for GitHub Actions when a workflow is triggered by a pull_request event. For example, consider this build for android-cache-fix-gradle-plugin:

My expectation in this case is that the Build Scan is tagged with erichaagdev/update-daily-dependabot-time and has a custom value of Git branch=erichaagdev/update-daily-dependabot-time.

Of course this has the side effect that you cannot filter the Build Scan dashboard to include only builds for your branch.

To better understand the impact this has, consider this filter project: android-cache-fix-gradle-plugin and tags: CI not:main not:head for the last 90 days. There are only 16 builds shown: https://ge.solutions-team.gradle.com/scans?search.relativeStartTime=P90D&search.rootProjectNames=android-cache-fix-gradle-plugin&search.tags=ci%2Cnot:head%2Cnot:main&search.timeZoneId=America/Chicago

Now if we drop the tag: HEAD, we have 1954 builds: https://ge.solutions-team.gradle.com/scans?search.relativeStartTime=P90D&search.rootProjectNames=android-cache-fix-gradle-plugin&search.tags=ci,not:main&search.timeZoneId=America/Chicago

This PR also defines a pattern for how to address #114. In that case, builds running on Bamboo with the repository caching feature enabled will see the Git repository custom value as a local file path, rather than the remote repository. See the issue for more details.

@etiennestuder
Copy link
Member

@erichaagdev Thanks for the details. But you are not addressing the core of my question which is: how often does this come up with customers?

@erichaagdev
Copy link
Member

Sorry, @etiennestuder but I will not be able to provide an exact frequency.

This would be a problem for any customer using GitHub Actions to run workflows on pull_request events, or any other CI provider which checks out projects in a detached state.

The similar #114 issue that I referenced is actually from a customer.

@runningcode runningcode closed this Jan 8, 2024
@runningcode
Copy link
Member

Closing in favor of #240

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

Successfully merging this pull request may close these issues.

None yet

4 participants