script out updating `download-git.js` about dugite HOT 9 CLOSED

It's good to download git in a better way. Shall we provide mirror mechanism to speed up users' downloading in some area like china ?

from dugite.

@shiftkey Could you give us some advice ?
The developers in china may suffer the speed of the download of dugite-native for some reason .

from dugite.

@frankLife this issue is for the contents of this file - the details in there change per release, and updating that is a manual process.

I was looking at letting the end user control where the local packages are stored in #134 so you could cache the artefacts for CI scenarios. But that's not quite what you're looking for.

If there's a secondary server which stores this releases in a similar, I'm happy to co-ordinate supporting this. I'm not sure how I feel about #137 and using three environment variables, but I do like using environment variables to control this behaviour.

What about if, instead of an environment variable for each platform, we had a single one like DUGITE_NATIVE_DOWNLOAD_SOURCE which we could then use to change the URLs we use?

from dugite.

@shiftkey If we use single one like DUGITE_NATIVE_DOWNLOAD_SOURCE , dose it mean that we join the three platform download urls and using it by splitting ?
or changing the prefix like https://github.com/desktop/dugite-native/releases/download/ to concat the source suffix ?
I feel the second method may be not very good that it needs to match the download path in other server.
But I hope the #134 can be merged soon which we can use to solve the problem in another way.

from dugite.

@frankLife

If we use single one like DUGITE_NATIVE_DOWNLOAD_SOURCE, dose it mean that we join the three platform download urls and using it by splitting ?

This depends on how this alternate source will host the artefacts. If they are at a predictable URL that is similar to the GitHub releases, and the file names remain the same, then we might be able to do it.

For example, this is a GitHub release URL:

https://github.com/desktop/dugite-native/releases/download/v2.14.3-rc1/dugite-native-v2.14.3-macOS-23.tar.gz

To simplify it down, let me swap in a few placeholders:

[HOST]/desktop/dugite-native/releases/download/[VERSION]/[FILE]

The VERSION and FILE parameters should be the same - we'll be doing the same checksumming of the downloaded bits - and HOST will obviously change to be a different server, but if the rest is done in a predictable way (GitHub has it's way of finding releases, HOST might be different) then I think we can get away with one environment variable for HOST.

I'll make finishing up #134 a priority in the meantime (I need to document it, I think that's all that's left).

from dugite.

Yes, we can only provide HOST and I think it needs more effort to deal with the download path. Shall we provide a way which it can save the effort and get more flexibility with consideration of checksumming ?

from dugite.

@frankLife I think the next step is finding someone is willing to setup an alternate server in China which mirrors these updates, so we can start experimenting with how this will work in the script.

from dugite.

@fengmk2 may you give this support ?

from dugite.

I'm going to close this out as it's sat for over a year without any movement, but if someone wants to get involved with hosting please get in touch.

from dugite.