search

mmkal / runovate

An experimental GitHub Action to manage a renovate branch, for rolling up updates easily and safely
0 stars 1 forks source link

Understanding scheduling of PR from `deps` to `main`, and why run on `deps` push? #2

Closed jamesbraza closed 1 month ago

jamesbraza commented 1 month ago

Hello I am super happy to give this GitHub Action a try. I like how you default the branches and GitHub token, and even create the deps-branch branch if isn't present.

I noticed in trpc-cli that the deps.yml runs on push to deps: https://github.com/mmkal/trpc-cli/blob/v0.5.0/.github/workflows/deps.yml

on:
  push:
    branches: [main, deps]

I understand why you run the GitHub Action on push to main, but why run on push to deps?

One other question is, I would like to control when a "rolled up" PR is opened from deps into main. How can I specify a schedule for the rolled up PRs?

mmkal commented 1 month ago

Triggering on deps push is needed because that's the branch renovate is configured to push to. Triggering on main push is so that when normal non-dependency-related code is pushed to main, it's merged into deps to make sure deps and main don't diverge other than dependency upgrades.

Re: scheduling the rolled up PRs, right now I don't think you could do that here, but you could of course change the renovate config to only run monthly or whatever. Why would you want to delay the PR being created though?

jamesbraza commented 1 month ago

Let me get back to you on this, I need to play around for a bit. I am now using this in a private repo as a pilot

jamesbraza commented 1 month ago

To add more answers to this question:

I understand why you run the GitHub Action on push to main, but why run on push to deps?

This is necessary so that after Renovate auto-merges into deps, runovate is run to open a PR from deps to main.

As far as scheduling, I understand now that runovate makes one "rolled up" PR, and all new Renovate automerges to deps lead to the rolled up PR being in-place updated. So scheduling isn't actually really necessary here.

I supposed one could schedule the rolled up PR's merge as long as CI is passing.

Closing this out as resolved, thank you for your help here @mmkal!