On Tue, Mar 08, 2022 at 08:05:31PM +0100, Tim Düsterhus wrote:
> 
> Let me make a competing proposal that:
> 
> 1. Keeps the complexity out of the GitHub workflow configuration in 
> haproxy/haproxy.
> 2. Still allows VTest caching.
> 
> For my https://github.com/TimWolla/haproxy-auth-request repository I 
> have created a reusable GitHub Action to perform the HAProxy 
> installation similar to 'actions/checkout':
> 
> https://github.com/TimWolla/action-install-haproxy/
> 
> I just spent a bit of time to fork that action and to make it VTest 
> specific:
> 
> https://github.com/TimWolla/action-install-vtest/
> 
> The action receives the VTest branch or commit as the input and will 
> handle all the heavy lifting of downloading, compiling and caching VTest.
> 
> The necessary changes to HAProxy then look like this:
> 
> https://github.com/TimWolla/haproxy/commit/78af831402e354f22d67682be0f323dec9c26a52
> 
> This basically replaces the use of 'scripts/build-vtest.sh' by 
> 'timwolla/action-install-vtest@main', so the configuration in the 
> haproxy/haproxy repository is not getting any more complicated, as all 
> the heavy lifting is done in the action which can be independently 
> tested and maintained.
> 
> If this proposal sounds good to you, then I'd like to suggest the following:
> 
> 1. Willy creates a new haproxy/action-install-vtest repository in the 
> haproxy organization.
> 2. Willy creates a new GitHub team with direct push access to that 
> repository.
> 3. Willy adds me to that team, so that I can maintain that repository 
> going forward (e.g. to handle the Dependabot pull requests that keep the 
> JavaScript dependencies up to date).
> 
> If that repository is properly set up, I'll send a patch to switch over 
> haproxy/haproxy to make use of that action.
> 
> Best regards
> Tim Düsterhus

Tim,

Honestly I'm confused, it is overcomplicated in my opinion :(

I don't really see the benefits in creating a whole new repository
instead of the few lines in the yaml file.

We are talking about doing a new project for just the equivalent of a 5
lines shell script... which really don't need to be tested and
maintained outside of the project.

I feel like I'm missing something with my simple implementation, we are
already downloading all the SSL libraries, should we stop doing it this
way? What could be the problems with this?

It seems like you want to do this in a strict github way, which is
probably convenient for a lot of usecase, but it just look really more
complicated that my first proposal.

-- 
William Lallemand

Reply via email to