Also one other additional thing I would like to mention is that while I apologize for dropping the ball a bit on setting up scala steward (have a lot of things on my plate at the moment), the benefits for Scala Steward are not going to be that great for pekko core/pekko-http because both of these projects have minimal dependencies (on the top of my head pekko core only has logback/slf4j, netty and maybe an additional one that I am missing).
The biggest benefit scala steward will give is to repositories like pekko-connectors and in light of what I said before in this case I really do think its a good idea to setup the Scala Steward within the apache github org because we don't want cases where we update an underlying dependency that is used for one of the connectors, only for that dependency to create a regression because we couldn't run proper tests due to secrets not being exposed. On Thu, Sep 7, 2023 at 9:57 AM Matthew de Detrich < [email protected]> wrote: > > Approval, probably yes, and we can see that as a feature. Secrets > should not be accessible but that is not a problem as PR validation > should not need secrets. > > With Pekko Connectors this is actually no longer the case, there are tests > that require secrets to work because they run against actual services (as > opposed to a local docker). > > Currently this is with S3 tests and this was added in because actual > regressions > were made in the pekko-connectors S3 client due to the fact that its not > possible to test all cases with docker services (with S3 specifically this > is > the minio docker image). > > I also expect that this will increase over time, there are other > connectors where the equivalent Docker images are only able to test a > smaller > scope of features (gcs is another such connector and I am sure there will > be others). > > On Thu, Sep 7, 2023 at 9:23 AM Johannes Rudolph < > [email protected]> wrote: > >> On Wed, Sep 6, 2023 at 11:31 PM PJ Fanning <[email protected]> wrote: >> > Scala Steward creates PRs in our repos so the GitHub Actions CI that >> > we have set up in our repos will run as normal on those PRs. These PR >> > CI runs will have full access to our repo secrets. It could be that >> > someone in the Apache GitHub org will need to press a button on the PR >> > to allow it to run the CI - I've seen this when PRs originate from >> > users who are not part of the Apache GitHub org. >> >> Approval, probably yes, and we can see that as a feature. Secrets >> should not be accessible but that is not a problem as PR validation >> should not need secrets. >> >> So, I don't see any reason to use our own instance for now. >> >> Incidentally, to make the updates less frequent I used to set a >> schedule to when those Scala steward are proposed, e.g. only once a >> week on Tuesday mornings, so that it is easier for maintainers to >> expect those updates and deal with them in a batch. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > -- > > Matthew de Detrich > > *Aiven Deutschland GmbH* > > Immanuelkirchstraße 26, 10405 Berlin > > Amtsgericht Charlottenburg, HRB 209739 B > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > *m:* +491603708037 > > *w:* aiven.io *e:* [email protected] > -- Matthew de Detrich *Aiven Deutschland GmbH* Immanuelkirchstraße 26, 10405 Berlin Amtsgericht Charlottenburg, HRB 209739 B Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen *m:* +491603708037 *w:* aiven.io *e:* [email protected]
