Improve version bump flexibility and automate AWS and sequel deps to minor automatically#19118
Conversation
…r version level (minor, major)
🤖 GitHub commentsJust comment with:
|
3c7a074 to
c357e5e
Compare
|
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 |
1d740df to
fcae407
Compare
|
@donoghuc Yes! here's the job eun and the resulting PR. As 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 |
c357e5e to
3947da9
Compare
42666bf to
c18ee2d
Compare
| - run: ./gradlew clean installDefaultGems | ||
| - run: ./vendor/jruby/bin/jruby -S bundle update --all --${{ env.INPUTS_BUMP }} --strict | ||
| - name: Bump selected deps at minor level | ||
| if: ${{ inputs.bump == 'patch' }} |
There was a problem hiding this comment.
nit: I know naming is hard, but I've found the bump type to be misleading here, is patch level rather than minor level?
- major : from 9.x to 10.x, such as 9.0.0 or 10.0.0
- minor: from 9.x to 9.x+1, such as 9.3.x to 9.4.0
- patch: from 9.x.y to 9.x.y+1, such as 9.2.0 to 9.2.1
There was a problem hiding this comment.
This step is intended to update selected gems at minor level and should only be exec when the bump type is patch.
| ./vendor/jruby/bin/jruby -S bundle update $GEMS --minor --strict --conservative | ||
| fi | ||
| - name: Bump selected deps at major level | ||
| if: ${{ inputs.bump != 'major' && inputs.extra_gems_major != '' }} |
There was a problem hiding this comment.
will that include minor and patches?
There was a problem hiding this comment.
Yes, it is possible that at some point (really unusual but harness to have it) we'd like some feature shipped with a new major dependency version while running patch/minor bump dependencies.
c18ee2d to
3947da9
Compare
|
@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 |
| if: ${{ inputs.bump == 'patch' }} | ||
| run: | | ||
| AWS_GEMS=$(./vendor/jruby/bin/jruby -S bundle list --name-only | grep '^aws-') | ||
| EXTRA="${{ inputs.extra_gems_minor }}" |
There was a problem hiding this comment.
nit: when using inputs let's use an intermediate env variable
| - name: Bump selected deps at major level | ||
| if: ${{ inputs.bump != 'major' && inputs.extra_gems_major != '' }} | ||
| run: | | ||
| GEMS=$(echo "${{ inputs.extra_gems_major }}" | xargs) |
There was a problem hiding this comment.
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 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. |
Release notes
[rn:skip]
What does this PR do?
Automates AWS minor updates on lock file patch bumps and adds 2 config parameters, allowing selected gems to be updated to minor or major automatically, improving workflow flexibility.
Why is it important/What is the impact to the user?
It allows to select gems where a desired feature/fix has been shipped as minor/major release and also keeps up to date gemps that don't ship patch releases (AWS).
Related issues
Tests
Example job run and the resulting PR. Some gems were manually downgraded at target branch befor the workflow execution.
elasticsearchandrubocopchose as selected minor gems input param, and redis as major.