> 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.
Afaik this is not the case, I actually experienced this issue when setting up Scala Steward at my company and to solve this issue we had to create our own runner as I am suggesting (you can see https://github.com/Aiven-Open/guardian-for-apache-kafka/pull/478 as an example of what a custom runner looks like). The issue with using the public Scala Steward is that the public Scala Steward user is not part of the apache github org and so it cannot access our secrets, from the POV of our github its just an external user creating PR's against our repository and secrets can never be exposed to external users. I just created an INFRA ticket at https://issues.apache.org/jira/browse/INFRA-24961 so lets see where it lands, if it takes too long then we can just fallback to the public Scala Steward. On Wed, Sep 6, 2023 at 11:31 PM PJ Fanning <[email protected]> wrote: > 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] > > -- 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]
