-
-
Notifications
You must be signed in to change notification settings - Fork 9.9k
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
[update.sh] Parsing token inside each upstream #16289
Conversation
Move global token HOMEBREW_GITHUB_API_TOKEN support inside each upstream repository to parse local token (if any) and setup it accordingly (local supersede global token - this can be reordered if needed)
@sazriel26 can you explain the motivation for this PR rather than what it is doing? Thanks! |
@MikeMcQuaid Well I started using a private repository for hosting some formulas with access through Git token (thus ran Such token is not a "global" but rather a local dedicated to this repository (git config is able to retrieve it and brew update can update the repository accordingly) This is not a must have just proposing you this contribution for reviewing if it can suit |
@sazriel26 Ok, I understand a bit more about what you're doing here but not the "why" behind the pull request. What did it do before that you didn't like and what does it do now instead? |
@MikeMcQuaid Sorry for the late reply, need to wait until next working day for getting access to test environment (and hopefully having a fresh mind) About this pull request, it is aiming to help update command to check through Github API for private repository if continuing or not the process like for public ones. To illustrate, when UPSTREAM_REPOSITORY_URL (from
fails due to URL with user and token and skip this section of code
With this "patch", if there is a token provided, it is parsed and can supersede the global one for using the API of Github to help deciding on going ahead or skipping the fetch - see
Not a "big deal" but I wanted to share this "enhancement" for your attention. Thanks for your attention and patience about this matter |
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 understand a bit more what you're asking for here, thanks
… HEAD See discussion in #16289
Is it ok? |
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.
Thanks for the PR! Just to set expectations: I think this feature is desirable but this PR is currently quite a long way off being an implementation we can merge and support. I find it very hard to read and understand right now and the error-handling in update.sh
needs to be absolutely rock-solid otherwise we run a risk of breaking Homebrew's own update mechanism.
Thanks again!
better wording Co-authored-by: Mike McQuaid <[email protected]>
First thank you @MikeMcQuaid for your kind support and availability about this PR. According to #16289 (review), it looks hard to satisfy some prerequisites in contributing for a newcomer like me, isn't it? What about to discard this PR which is not ready at this moment for merge? Thanks again for your understanding and sorry for the annoyance (including time consuming) |
You're welcome ❤️
I think we can get there together; I'm just giving you the heads up that it may take a while. Some newcomers contributions are merged very quickly, others are not. It depends on the readability of the code, the invasiveness of the change and the potential negative effects of any issues.
Up to you, I'm happy to keep working here if you are!
Thank you and no apologies needed; not annoyed here at all 😁 |
Thanks @MikeMcQuaid ! Let's give a try this week and state about if it can suit or not See you then. |
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
@MikeMcQuaid With some delay, and thinking of the shell used (bash), I have rewritten this pull request accordingly (with help of BASH_REMATCH array) |
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.
Thanks @sazriel26. This is looking a lot clearer now. I've suggested some tweaks (that may need fixed up with brew style
) to ensure your new logic is a fallback rather than taking priority or encompassing the old logic.
Library/Homebrew/cmd/update.sh
Outdated
|
||
# HOMEBREW_UPDATE_FORCE and HOMEBREW_UPDATE_AUTO aren't modified here so ignore subshell warning. | ||
# shellcheck disable=SC2030 | ||
if [[ "${UPSTREAM_REPOSITORY_URL}" == "https://github.com/"* ]] | ||
then | ||
UPSTREAM_REPOSITORY="${UPSTREAM_REPOSITORY_URL#https://github.com/}" | ||
UPSTREAM_REPOSITORY="${UPSTREAM_REPOSITORY%.git}" | ||
elif [[ "${UPSTREAM_REPOSITORY_URL}" =~ https://(([^:@]+)(:([^@]+))?@)?github.com/(.*)$ ]] |
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.
elif [[ "${UPSTREAM_REPOSITORY_URL}" =~ https://(([^:@]+)(:([^@]+))?@)?github.com/(.*)$ ]] | |
elif [[ "${DIR}" != "${HOMEBREW_REPOSITORY}" ]] && [[ "${UPSTREAM_REPOSITORY_URL}" =~ https://(([^:@]+)(:([^@]+))?@)?github.com/(.*)$ ]] |
I think this is what we want to do here based on discussion with @MikeMcQuaid.
Can it suit better now? |
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 convinced that this code does what it's intended and is unlikely to break anything important.
However, is this the correct API for providing repository/tap-specific credentials?
IIUC, encoding access credentials in the URL is insecure and discouraged. If so, then, at minimum, we should:
- at least redact the credentials from the URL we pass to
curl
; or, - maybe consider a different API for passing these credentials.
We're not passing auth in the URL to curl. We're decoding it from an already-encoded git URL and passing it to curl via On the credential retrieval side, it isn't fully foolproof. You can supply git with a plain URL and retrieve credentials via the keychain (where available) or use |
In my experience: it's also the only method that 100% works across That's not to say "let's encourage it" but it is a completely reasonable thing to do particularly given:
|
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.
Thanks for your first PR to Homebrew, @sazriel26, you rock and I appreciate your patience with all the back-and-forth!
@sazriel26 Can you please rebase this so we can get it merged? Thanks! |
Thanks in advance |
You can check the Git manual for this. |
Oops ! I have broken this pull request, isn't it? When I have tried to reproduce the https://git-scm.com/book/en/v2/Git-Branching-Rebasing:
it is saying "Current branch parse-git-token is up to date." Shall I reopen a new pull request from the parse-git-token (old master from which I have opened this PR)? Thanks in advance and sorry for the inconvenience |
You need to instead run
Yes, please. |
@MikeMcQuaid Thanks for your answer I have created a draft pull request #16649 as demanded Can you check if it suits the requirements of rebase ? Thanks in advance |
brew style
with your changes locally?brew typecheck
with your changes locally?brew tests
with your changes locally?This pull request is not for formula but for update.sh script to allow local token parsing inside each upstream