Pass --no-changelog to auto shipit if changelog already has entry#5952
Pass --no-changelog to auto shipit if changelog already has entry#5952yarikoptic merged 1 commit intodatalad:maintfrom jwodder:gh-5782
--no-changelog to auto shipit if changelog already has entry#5952Conversation
Codecov Report
@@ Coverage Diff @@
## maint #5952 +/- ##
==========================================
- Coverage 90.28% 83.71% -6.58%
==========================================
Files 300 297 -3
Lines 42516 41375 -1141
==========================================
- Hits 38387 34638 -3749
- Misses 4129 6737 +2608
Continue to review full report at Codecov.
|
| then echo "[ERROR] Could not compare new version '$new_version' to changelog version '$changelog_version'" | ||
| exit 1 | ||
| fi | ||
| ~/auto shipit $opts |
There was a problem hiding this comment.
elaborate but looks kosher... I was fearing that the empty $opts would freak out auto but my shell foo was weak -- should be ok unless it is "$opts":
lena:/tmp
$> opts=
$> ./printargs.sh 1 2 $opts
> 1
> 2
$> ./printargs.sh 1 2 "$opts"
> 1
> 2
>
$> cat printargs.sh
#!/bin/bash
for a in "$@"; do
echo "> $a"
done
yarikoptic
left a comment
There was a problem hiding this comment.
@mih et al - please have a look too. With this custom-changelog-makers will not be ignored! ;)
|
ah -- it was rebased against maint, that is why probably linters complain! |
|
So the approach will be to commit a changelog (or define its version) just before a release? Sounds good to me. Thx! |
yes. Can as well work if that CHANGELOG adding PR is the one which triggers the release (has |
| elif ! dpkg --compare-versions "$new_version" gt "$changelog_version" | ||
| then echo "[ERROR] Could not compare new version '$new_version' to changelog version '$changelog_version'" | ||
| exit 1 | ||
| fi |
There was a problem hiding this comment.
an idea! @jwodder -- would it be possible to move this checking into a separate step(I guess not needed as a separate step, just don't ship it if in a PR), make this workflow run also on PRs which have release label, but without actually doing ~/auto shipit?
Then we could be certain that release PR is a kosher one.
Workflow should react on change to labels (like the other one).
There was a problem hiding this comment.
@yarikoptic No, if the workflow is running on an open release PR, auto won't consider the project eligible for a release (as the PR isn't merged yet), and so auto shipit --dry-run --quiet will output nothing.
There was a problem hiding this comment.
damn, it was a good idea! ;) just to make sure -- it wouldn't work even if we adjust "baseBranch": "maint" to point to current to PR merge branch (I guess there is none on github) in .autorc, right?
There was a problem hiding this comment.
@yarikoptic I think that wouldn't work, as then auto wouldn't pick up the PRs that had already been merged into maint, and so the version bump level would be potentially inaccurate.
|
ok, let's proceed on this in preparation for 0.15 . Should be glorious! ;) |
Closes #5782.