Install DDEV binary manually instead via APT

[mxr576]

The Issue

#42

How This PR Solves The Issue

Install DDEV as a binary instead via apt.

More details in #42 (comment)

Manual Testing Instructions

Automated Testing Overview

Related Issue Link(s)

Release/Deployment Notes

[mxr576]

LLM generated with corrections.

[rfay]

The real-user maintainers will need to comment, @jonaseberle @davereid

[jonaseberle]

Thank you for your effort!

I like it.
But it's quite hard to follow because it is indeed several changes in one.

1. using a "composite" workflow instead of our previous JavaScript just makes sense because it is easier. Couldn't node_modules be deleted now, too?
2. retry (with exponential delays) for downloads and install
3. moving away from install via apt
4. And finally the possibility to use an external installation URL. Is https://raw.githubusercontent.com/ddev/ddev/master/scripts/install_ddev.sh a good default? Shouldn't it be https://ddev.com/install.sh as per https://docs.ddev.com/en/stable/users/install/ddev-installation/#linux ?

I am asking you to deliver smaller steps and communicate the reasons for further changes.

Could you please do the refactoring from 1. first without the other changes? Please stick to the commands we currently have first.

In my opinion 2. does not make sense and adds a lot of unnecessary complexity. The use case seems to be unstable downloads and failing installations (that somehow fix themselves on multiple tries)? I have not experienced that. If you see i, please open an issue for it and fix it in a separate pull request. jitterPercent makes me chuckle hard due to its feature creep and obvious useless-yet-sounds-cool-attitude. Remove all the non-sense, please!

Regarding 3. and 4.: You did the research that it would save runtime on Github Actions. It is fine with me as long as the action's default uses one of DDEV's published installation methods. I think it should be https://ddev.com/install.sh as per https://docs.ddev.com/en/stable/users/install/ddev-installation/#install-script-linux then, doesn't it? – I like to stick to officially published ways to increase resilience...

[jonaseberle]

I have rebased your branch onto main.

[mxr576]

I have rebased your branch onto main.

thanks!

[mxr576]

using a "composite" workflow instead of our previous JavaScript just makes sense because it is easier. Couldn't node_modules be deleted now, too?

Good point, deleted all node related remnants.

[mxr576]

And finally the possibility to use an external installation URL. Is https://raw.githubusercontent.com/ddev/ddev/master/scripts/install_ddev.sh a good default? Shouldn't it be https://ddev.com/install.sh as per https://docs.ddev.com/en/stable/users/install/ddev-installation/#linux ?

❯ curl https://ddev.com/install.sh
Redirecting to https://raw.githubusercontent.com/ddev/ddev/main/scripts/install_ddev.sh%     

We can use that alias for sure, but the result won't change.

[mxr576]

Could you please do the refactoring from 1. first without the other changes? Please stick to the commands we currently have first.

In my opinion 2. does not make sense and adds a lot of unnecessary complexity.

I totally agree that the scope of the change is bigger than anybody would anticipate, but based on my tests (and suffering) from yesterday, I simply do not know how to separate these changes but still deliver a 100% stable solution.

The main problem is Github's infrastructure where HTTP requests - even within Github - fails randomly with curl 35 and similar errors for no reasons. So Curl's built-in retry strategy ( curl -fsSL --retry 3 --retry-max-time 60 --retry-connrefused) simply does not enough alone to ensure GHA does not randomly fail due to these random issues.

[jonaseberle]

The main problem is Github's infrastructure where HTTP requests - even within Github - fails randomly with curl 35 and similar errors for no reasons. So Curl's built-in retry strategy ( curl -fsSL --retry 3 --retry-max-time 60 --retry-connrefused) simply does not enough alone to ensure GHA does not randomly fail due to these random issues.

That's weird. I'd like to see that on my own. I am averse to add complexity by workarounds that Github should fix on their side (which they probably will, won't they?).

[jonaseberle]

❯ curl https://ddev.com/install.sh
Redirecting to https://raw.githubusercontent.com/ddev/ddev/main/scripts/install_ddev.sh%     

We can use that alias for sure, but the result won't change.

Yes, please use the communicated official URL unless there would be reasons to use internal, undocumented behaviour.

[mxr576]

Opened #46 without the extra retry script. Of course, those transient errors are not happening atm... or maybe they primarily happening on private Github repos? 🤔

Since actions are not triggered on my PRs yet, the original runs can be seen in my fork: https://github.com/mxr576/github-action-setup-ddev/actions/workflows/main.yml

[jonaseberle]

I am closing here in favour of #46.