-
Notifications
You must be signed in to change notification settings - Fork 28
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
Conversation
There was a problem hiding this 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()) { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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)
this.isGitInstalled = isGitInstalled; | ||
} | ||
|
||
static GitMetadata given(boolean isGitInstalled) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
a4ea7f7
to
4b70d9d
Compare
return Optional.empty(); | ||
} | ||
|
||
static class GitMetadataBuilder { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :))
There was a problem hiding this 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.
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. |
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() { |
There was a problem hiding this comment.
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?
@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. |
I don't think it was intentionally left out. |
@etiennestuder This would address the issue where CI checks out the branch in a detached HEAD state. In this case, This is the case for GitHub Actions when a workflow is triggered by a
My expectation in this case is that the Build Scan is tagged with 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 Now if we drop the 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 |
@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? |
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 The similar #114 issue that I referenced is actually from a customer. |
Closing in favor of #240 |
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.