Reasonable point about starting with just pekko and pekko-http. 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.
On Wed, 6 Sept 2023 at 22:22, Matthew de Detrich <[email protected]> wrote: > > Also I forgot to mention that the advantage of having our own runner for > Scala Steward vs the default public VirtuisLabs one is that a runner in our > own org has access to all of the github secrets which can be important for > some integration tests (pekko-connectors has such a test). > > It basically allows us to test that dependency upgrades don't break > something. > > On Wed, Sep 6, 2023 at 11:19 PM Matthew de Detrich < > [email protected]> wrote: > > > > I would like to press on and add entries for our main repos to > > https://github.com/VirtusLab/scala-steward-repos/blob/main/repos-github.md > > > > * pekko > > * pekko-http > > * pekko-connectors > > * possibly more > > > > For pekko/pekko-http this can work since the 1.0.x branches have been > > setup but for other repos we need to create the branches yet since we > > shouldn't be getting dependency updates for the 1.0.x series unless they > > contain CVE's/ > > > > On Wed, Sep 6, 2023 at 7:25 PM PJ Fanning <[email protected]> wrote: > > > >> I would like to press on and add entries for our main repos to > >> https://github.com/VirtusLab/scala-steward-repos/blob/main/repos-github.md > >> > >> * pekko > >> * pekko-http > >> * pekko-connectors > >> * possibly more > >> > >> There are some Apache repos already managed this way. > >> > >> We can set up our own job later but it would be nice to get moving on > >> this and using the VirtusLab integration is trivial to set up. We can undo > >> it if we get too much noise in terms of generated PRs. > >> > >> > >> > >> On 2023/08/14 12:53:06 PJ Fanning wrote: > >> > We intend to use Scala Steward. There doesn't appear to anything that > >> matches Scala Steward's feature set for Scala based projects. > >> > > >> > The simplest approach is to add entries to this page and there is an > >> automated job that will raise PRs: > >> > > >> https://github.com/VirtusLab/scala-steward-repos/blob/main/repos-github.md > >> > > >> > Matthew de Detrich has expressed a preference for us to run our own > >> Scala Steward job. > >> > > >> > With dependencies between Pekko modules, we intend to follow: > >> > > >> > > >> https://pekko.apache.org/docs/pekko/current/project/downstream-upgrade-strategy.html > >> > > >> > With 3rd party dependencies, we will be conservative. If there are > >> security issues, we will almost certainly upgrade to a secure version. > >> Enabling Scala Steward will raise awareness of 3rd party jar releases but > >> merging the PRs will not be automatic. They will need careful review. > >> > > >> > > >> > > >> > On 2023/08/14 10:06:57 Samuele Resca wrote: > >> > > Hi, > >> > > > >> > > I'm opening a discussion regarding dependencies updates in Apache > >> Pekko > >> > > Core + modules. I saw that most of the Apache Pekko codebases already > >> have > >> > > the .scala-steward.conf file for automatically updating dependencies. > >> > > Few questions that I have on top of my head: > >> > > - Do we want to automate the stay current process in Apache Pekko > >> (core + > >> > > modules)? > >> > > - Do we want scala-steward running on Apache Pekko Core + modules? Is > >> > > there any other alternative system used by ASF projects? > >> > > - Which subset of dependency do we want to update? (i.e: excluding > >> > > intra-dependencies between Pekko modules) > >> > > - Do we have a preference for the schedule (see: > >> pullRequests.frequency)? > >> > > > >> > > Thanks in advance. > >> > > Samuele > >> > > > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [email protected] > >> > For additional commands, e-mail: [email protected] > >> > > >> > > >> > >> --------------------------------------------------------------------- > >> 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
