🤖 GitHub comments

Just comment with:

• run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)
• run exhaustive tests : Run the exhaustive tests Buildkite pipeline.

do you have any example workflow runs or outputs/diffs to point to seeing how this works in action?

Dynamically generating sets of gems with the gem list + regex probably has some edge cases, but i'm not fully opposed to it. The other option would be to maintain a static list. The nice thing is that this action is just used to generate a PR which will be reviewed so we will have a built in check point to be monitoring the performance of whatever approach we go with.

@donoghuc Yes! here's the job eun and the resulting PR. As extra_gems_major input, I've set redis (previously downgraded manually )

I avoided creating and maintaining a separate list/file with the list of dependencies, I'm not really agains it, but I think would be easier using gem list+ regex. Anyway, it would be pretty straightforward to add a list of dependencies. WDYT?

@donoghuc I sent back this PR to its first version where just AWS gems were automatically updated to minor and 2 new input parameters to select specific gems and provide more flexibility, following the comment in the 8.19 PR. It is described in the PR description with an example run and PR.

The thing I've doubts about is the backport, it looks like the workflow has diverged a lot between 8.19 and 9.x branches, that are almost up to date with main. I think this workflow is always run ffrom main(correct me if I'm wrong). Maybe ithe backport to all active is not needed. WDYT?

The thing I've doubts about is the backport, it looks like the workflow has diverged a lot between 8.19 and 9.x branches, that are almost up to date with main. I think this workflow is always run ffrom main(correct me if I'm wrong). Maybe ithe backport to all active is not needed. WDYT?

Unfortunately no. The reason is that the lockfile has a ruby version component to it, so you must run the workflow from the branch that you are doing the update for. For example if you try to run the workflow from main on 8.19 you will be using bundler/jruby 10 that tracks ruby 3.4 to attempt to manage the bundler/jruby env in 8.19 which is for jruby 9.4 that tracks ruby 3.1.

SO, with the current architecture we must do backports to all branches so that the workflow we run corresponds to the branch it is operating on.

@Mergifyio backport 9.4 9.3 8.19

backport 9.4 9.3 8.19

✅ Backports have been created

On branch mergify/bp/8.19/pr-19118
Your branch is up to date with 'origin/8.19'.

You are currently cherry-picking commit f71e27b49.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   .github/workflows/version_bumps.yml

no changes added to commit (use "git add" and/or "git commit -a")