WIP: Kraken buy multiple assets

[Sebastix]

No description provided.

[Jorijn]

Tip: Maak hier een multistage Dockerfile van, je kan dan de productie laag van de image hergebruiken voor development.

Voorbeeld:

FROM php:7.4-cli-alpine AS production

productie dingen hier

FROM production AS development

hier development dingen toevoegen

[Sebastix]

Handy! Ik zag het ook in Dockerfile in de app root voorbij komen, ben niet bekend met het multistage concept binnen Docker maar sounds logic :) Kan dit dan ook in de Dockerfile geplaatst die in de app root staat?

[Sebastix]

Ik heb nu een development stage toegevoegd in de Dockerfile:

##################################################################################################################
# Development Stage
##################################################################################################################
FROM production AS dev

RUN composer install

[Jorijn]

Zeker! Je zal dan alleen tijdens het bouwen van bijv. de productiebuild moeten aangeven dat je tot een specifiek target wil gaan en niet verder.

[Sebastix]

Heb nu een development stage (helemaal onderaan) toegevoegd FROM base_image AS development in de Dockerfile in de app root. Hier staan verder (nog) geen commands in.
In docker/development/docker-compose.yml heb ik het volgende nu staan mbt de build:

    build:
      context: ../../
      dockerfile: Dockerfile
      target: development

Als ik echter daarna docker-compose --build doe, zou ik verwachten dat er een development image wordt gebouwd voor de service, zonder de test en production_build stages. Toch lijkt dit niet te gebeuren, want ik zie bij het builden de output van test voorbij komen.

Hetzelfde als ik docker build --target development -t jorijn/bitcoin-dca:development . uitvoer.

[Jorijn]

Je wijkt hier af van de interface wat in de regel niet zo'n goed idee is, buiten development is er eigenlijk ook geen reden om de aankoop te simuleren.

[Sebastix]

De $simulate moet er uit inderdaad. Icm Docker die ziet of je in de development stage zit, zouden we dit wel kunnen gebruiken?

[Jorijn]

Als je er op staat om perse een simulate optie er in te houden zou ik een extra service introduceren, deze kan dan de KrakenBuyService extenden of decoraten.

Door middel van prioriteiten aan je tags mee te geven kun je dan je KrakenSimulatedBuyService net boven de andere KrakenBuyService zetten. In de supports methode kun je dan controleren op de aanwezigheid van bijvoorbeeld KRAKEN_SIMULATE_BUY environment variabele.

Dit zou dan ongeveer zo uitwerken:

$ KRAKEN_SIMULATE_BUY=1 bin/bitcoin-dca buy 10 --yes

[Sebastix]

@Jorijn Het zijn ondertussen aardig wat changes...teveel eigenlijk nu.
Elke WithdrawAddressProvider heb ik voorzien van een van een $asset property, zodat er gecheckt kan worden welk adres hoort bij welke asset (als je een andere suggestie hebt om dit op te lossen hoor ik dat graag).
Echter loop ik vast op 1 ding en dat is hier in de WithdrawServiceTest.php. Ik heb geen ervaring met het schrijven van PHP unit tests, dus ik begrijp niet goed wat ik hier moet oplossen:

 ✘ Get recipient address
   ┐
   ├ Expectation failed for method name is "provide" when invoked 2 time(s).
   ├ Method was expected to be called 2 times, actually called 0 times.     
   ┴