1
0
Fork 0
mirror of https://codeberg.org/forgejo/forgejo.git synced 2025-07-19 01:29:40 +02:00
forgejo/release-notes-assistant.sh

307 lines
6.9 KiB
Bash
Raw Normal View History

#!/bin/bash
# Copyright twenty-panda <twenty-panda@posteo.com>
# SPDX-License-Identifier: MIT
label_worth=worth
label_bug=bug
label_feature=feature
label_ui=forgejo/ui
label_breaking=breaking
label_security=security
label_localization=forgejo/i18n
payload=$(mktemp)
pr=$(mktemp)
trap "rm $payload $pr" EXIT
function test_main() {
set -ex
PS4='${BASH_SOURCE[0]}:$LINENO: ${FUNCNAME[0]}: '
test_payload_labels $label_worth $label_breaking $label_security $label_bug
test "$(categorize)" = 'AA Breaking security bug fixes'
test_payload_labels $label_worth $label_security $label_bug
test "$(categorize)" = 'AB Security bug fixes'
test_payload_labels $label_worth $label_breaking $label_security $label_feature
test "$(categorize)" = 'AC Breaking security features'
test_payload_labels $label_worth $label_security $label_feature
test "$(categorize)" = 'AD Security features'
test_payload_labels $label_worth $label_security
test "$(categorize)" = 'ZA Security changes without a feature or bug label'
test_payload_labels $label_worth $label_breaking $label_feature
test "$(categorize)" = 'BA Breaking features'
test_payload_labels $label_worth $label_breaking $label_bug
test "$(categorize)" = 'BB Breaking bug fixes'
test_payload_labels $label_worth $label_breaking
test "$(categorize)" = 'ZB Breaking changes without a feature or bug label'
test_payload_labels $label_worth $label_ui $label_feature
test "$(categorize)" = 'CA User Interface features'
test_payload_labels $label_worth $label_ui $label_bug
test "$(categorize)" = 'CB User Interface bug fixes'
test_payload_labels $label_worth $label_ui
test "$(categorize)" = 'ZC User Interface changes without a feature or bug label'
test_payload_labels $label_worth $label_localization
test "$(categorize)" = 'DA Localization'
test_payload_labels $label_worth $label_feature
test "$(categorize)" = 'EA Features'
test_payload_labels $label_worth $label_bug
test "$(categorize)" = 'EB Bug fixes'
test_payload_labels $label_worth
test "$(categorize)" = 'ZE Other changes without a feature or bug label'
test_payload_labels
chore: improve the wording of the "not worth a release note" category (#8542) Hi all, I believe that open source projects in general are under-appreciated. And no matter how big or small, every contribution matters, whether it's the implementation of a shiny new feature or just taking the time to make sure that a dependency is updated to its latest patch release. I don't usually contribute to Forgejo, but we run an instance, and highly appreciate all of the work everyone involved is doing. As such, it kinda pains me to see the "Included for completeness but __not worth__ a release note" line (emphasis mine) in the release notes every time. More often than not, when clicking on one of those PRs, you'll see that people actually do put some thought into the changes hidden down there, there may even be more or less heated discussions about them, and even though these changes may not directly influence the user experience, they are an important part of running a project like this. As such, I propose changing that line to "Included for completeness but not user facing (chores, etc.)" (courtesy of @earl-warren on Matrix). It's a really really small change, but I think it matters. ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. There also are a few [conditions for merging Pull Requests in Forgejo repositories](https://codeberg.org/forgejo/governance/src/branch/main/PullRequestsAgreement.md). You are also welcome to join the [Forgejo development chatroom](https://matrix.to/#/#forgejo-development:matrix.org). ### Tests Not applicable since there are no Go or JavaScript changes. - I added test coverage for Go changes... - [ ] in their respective `*_test.go` for unit tests. - [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I added test coverage for JavaScript changes... - [ ] in `web_src/js/*.test.js` if it can be unit tested. - [ ] in `tests/e2e/*.test.e2e.js` if it requires interactions with a live Forgejo server (see also the [developer guide for JavaScript testing](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/tests/e2e/README.md#end-to-end-tests)). ### Documentation Since this is only a change to the wording of the release notes, no user documentation is required for this. - [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change. - [x] I did not document these changes and I do not expect someone else to do it. ### Release notes This PR is certainly not worthy. - [x] I do not want this change to show in the release notes. - [ ] I want the title to show in the release notes with a link to this pull request. - [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8542 Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> Co-authored-by: Kumi <git@kumi.email> Co-committed-by: Kumi <git@kumi.email>
2025-07-18 07:19:15 +02:00
test "$(categorize)" = 'ZF Included for completeness but not user-facing (chores, etc.)'
test_payload_draft "fix(security)!: breaking security bug fix"
test "$(categorize)" = 'AA Breaking security bug fixes'
test_payload_draft "fix(security): security bug fix"
test "$(categorize)" = 'AB Security bug fixes'
test_payload_draft "feat!: breaking feature"
test "$(categorize)" = 'BA Breaking features'
test_payload_draft "fix!: breaking bug fix"
test "$(categorize)" = 'BB Breaking bug fixes'
test_payload_draft "feat: feature"
test "$(categorize)" = 'EA Features'
test_payload_draft "fix: bug fix"
test "$(categorize)" = 'EB Bug fixes'
test_payload_draft "something with no prefix"
test "$(categorize)" = 'ZE Other changes without a feature or bug label'
}
function main() {
cat >$payload
categorize
}
function categorize() {
#
# If this is a backport, refer to the original PR to figure
# out the classification.
#
if $(jq --raw-output .IsBackportedFrom <$payload); then
jq --raw-output '.BackportedFrom[0]' <$payload >$pr
else
jq --raw-output '.Pr' <$payload >$pr
fi
labels=$(jq --raw-output '.labels[].name' <$pr)
#
# Was this PR labeled `worth a release note`?
#
if echo "$labels" | grep --quiet $label_worth; then
worth=true
else
worth=false
fi
#
# If there was no release-notes/N.md file and it is not
chore: improve the wording of the "not worth a release note" category (#8542) Hi all, I believe that open source projects in general are under-appreciated. And no matter how big or small, every contribution matters, whether it's the implementation of a shiny new feature or just taking the time to make sure that a dependency is updated to its latest patch release. I don't usually contribute to Forgejo, but we run an instance, and highly appreciate all of the work everyone involved is doing. As such, it kinda pains me to see the "Included for completeness but __not worth__ a release note" line (emphasis mine) in the release notes every time. More often than not, when clicking on one of those PRs, you'll see that people actually do put some thought into the changes hidden down there, there may even be more or less heated discussions about them, and even though these changes may not directly influence the user experience, they are an important part of running a project like this. As such, I propose changing that line to "Included for completeness but not user facing (chores, etc.)" (courtesy of @earl-warren on Matrix). It's a really really small change, but I think it matters. ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. There also are a few [conditions for merging Pull Requests in Forgejo repositories](https://codeberg.org/forgejo/governance/src/branch/main/PullRequestsAgreement.md). You are also welcome to join the [Forgejo development chatroom](https://matrix.to/#/#forgejo-development:matrix.org). ### Tests Not applicable since there are no Go or JavaScript changes. - I added test coverage for Go changes... - [ ] in their respective `*_test.go` for unit tests. - [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I added test coverage for JavaScript changes... - [ ] in `web_src/js/*.test.js` if it can be unit tested. - [ ] in `tests/e2e/*.test.e2e.js` if it requires interactions with a live Forgejo server (see also the [developer guide for JavaScript testing](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/tests/e2e/README.md#end-to-end-tests)). ### Documentation Since this is only a change to the wording of the release notes, no user documentation is required for this. - [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change. - [x] I did not document these changes and I do not expect someone else to do it. ### Release notes This PR is certainly not worthy. - [x] I do not want this change to show in the release notes. - [ ] I want the title to show in the release notes with a link to this pull request. - [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8542 Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> Co-authored-by: Kumi <git@kumi.email> Co-committed-by: Kumi <git@kumi.email>
2025-07-18 07:19:15 +02:00
# directly user-facing, we include it in a separate section
# for completeness.
#
if test -z "$(jq --raw-output .Draft <$payload)"; then
if ! $worth; then
chore: improve the wording of the "not worth a release note" category (#8542) Hi all, I believe that open source projects in general are under-appreciated. And no matter how big or small, every contribution matters, whether it's the implementation of a shiny new feature or just taking the time to make sure that a dependency is updated to its latest patch release. I don't usually contribute to Forgejo, but we run an instance, and highly appreciate all of the work everyone involved is doing. As such, it kinda pains me to see the "Included for completeness but __not worth__ a release note" line (emphasis mine) in the release notes every time. More often than not, when clicking on one of those PRs, you'll see that people actually do put some thought into the changes hidden down there, there may even be more or less heated discussions about them, and even though these changes may not directly influence the user experience, they are an important part of running a project like this. As such, I propose changing that line to "Included for completeness but not user facing (chores, etc.)" (courtesy of @earl-warren on Matrix). It's a really really small change, but I think it matters. ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. There also are a few [conditions for merging Pull Requests in Forgejo repositories](https://codeberg.org/forgejo/governance/src/branch/main/PullRequestsAgreement.md). You are also welcome to join the [Forgejo development chatroom](https://matrix.to/#/#forgejo-development:matrix.org). ### Tests Not applicable since there are no Go or JavaScript changes. - I added test coverage for Go changes... - [ ] in their respective `*_test.go` for unit tests. - [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I added test coverage for JavaScript changes... - [ ] in `web_src/js/*.test.js` if it can be unit tested. - [ ] in `tests/e2e/*.test.e2e.js` if it requires interactions with a live Forgejo server (see also the [developer guide for JavaScript testing](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/tests/e2e/README.md#end-to-end-tests)). ### Documentation Since this is only a change to the wording of the release notes, no user documentation is required for this. - [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change. - [x] I did not document these changes and I do not expect someone else to do it. ### Release notes This PR is certainly not worthy. - [x] I do not want this change to show in the release notes. - [ ] I want the title to show in the release notes with a link to this pull request. - [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8542 Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> Co-authored-by: Kumi <git@kumi.email> Co-committed-by: Kumi <git@kumi.email>
2025-07-18 07:19:15 +02:00
echo -n ZF Included for completeness but not user-facing \(chores, etc.\)
exit 0
fi
fi
is_ui=false
is_bug=false
is_feature=false
is_localization=false
is_breaking=false
is_security=false
#
# first try to figure out the category from the labels
#
case "$labels" in
*$label_bug*)
is_bug=true
;;
*$label_feature*)
is_feature=true
;;
*$label_localization*)
is_localization=true
;;
esac
case "$labels" in
*$label_security*)
is_security=true
;;
esac
case "$labels" in
*$label_breaking*)
is_breaking=true
;;
esac
case "$labels" in
*$label_ui*)
is_ui=true
;;
esac
#
# then try the prefix of the release note
#
if ! $is_bug && ! $is_feature; then
draft="$(jq --raw-output .Draft <$payload)"
case "$draft" in
fix\(security\)!:*)
is_bug=true
is_breaking=true
is_security=true
;;
fix\(security\):*)
is_bug=true
is_security=true
;;
fix!:*)
is_bug=true
is_breaking=true
;;
fix:*)
is_bug=true
;;
feat!:*)
is_feature=true
is_breaking=true
;;
feat:*)
is_feature=true
;;
esac
fi
if $is_bug; then
if $(jq --raw-output .IsBackportedTo <$payload); then
#
# if it has been backported, it was in the release notes of an older stable release
# and does not need to be in this more recent release notes
#
echo -n ZG Already announced in the release notes of an older stable release
exit 0
fi
fi
if $is_security; then
if $is_bug; then
if $is_breaking; then
echo -n AA Breaking security bug fixes
else
echo -n AB Security bug fixes
fi
elif $is_feature; then
if $is_breaking; then
echo -n AC Breaking security features
else
echo -n AD Security features
fi
else
echo -n ZA Security changes without a feature or bug label
fi
elif $is_breaking; then
if $is_feature; then
echo -n BA Breaking features
elif $is_bug; then
echo -n BB Breaking bug fixes
else
echo -n ZB Breaking changes without a feature or bug label
fi
elif $is_ui; then
if $is_feature; then
echo -n CA User Interface features
elif $is_bug; then
echo -n CB User Interface bug fixes
else
echo -n ZC User Interface changes without a feature or bug label
fi
elif $is_localization; then
echo -n DA Localization
else
if $is_feature; then
echo -n EA Features
elif $is_bug; then
echo -n EB Bug fixes
else
echo -n ZE Other changes without a feature or bug label
fi
fi
}
function test_payload_labels() {
local label1="$1"
local label2="$2"
local label3="$3"
local label4="$4"
cat >$payload <<EOF
{
"Pr": {
"labels": [
{
"name": "$label1"
},
{
"name": "$label2"
},
{
"name": "$label3"
},
{
"name": "$label4"
}
]
},
"IsBackportedFrom": false,
"Draft": ""
}
EOF
}
function test_payload_draft() {
local draft="$1"
cat >$payload <<EOF
{
"Pr": {
"labels": [
{
"name": "$label_worth"
}
]
},
"IsBackportedFrom": false,
"Draft": "$draft"
}
EOF
}
"${@:-main}"