Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ICU-23056 Add workflow to generate commit checker report #3413

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

ICU-23056 Add workflow to generate commit checker report #3413

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
99b3abe
ICU-23056 Add workflow to generate commit checker report
echeran Feb 21, 2025
2a41dbd
ICU-23056 Use GH secrets instead of workflow dispatch text field inputs
echeran Feb 26, 2025
48d8ac2
ICU-23056 Remove unneeded workflow dispatch text field inputs
echeran Feb 26, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
64 changes: 64 additions & 0 deletions .github/workflows/brs-commit-checker.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,64 @@
name: BRS Commit Checker Report
on:
workflow_dispatch:
inputs:
fix_version:
type: string
required: true
description: The ICU Jira "Fix Version" semver
from_git_ref:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this to be so flexible, from git-ref to git-ref?
Working with tags would be a lot easier and more readable
(think from release-76-1 to release-77-rc)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This derives from how git works. When you issue a command (ex: checkout, reset, etc.), what you provide as an argument is called a git ref. If "ref" is an interface/supertype, then concrete types of a ref include tags, commit hashes, and branch names.

As you know, with git, the implementation is the specification. So I presume the flexibility comes from git.

I also personally don't think the the flexibility is a problem in the first place.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it mean that I can use release-76-rc?
And that's a git-ref in GitHub lingo?

In fact in git a tag is basically an alias to a ref, or a pointer to a ref (however you want to look at it)

So maybe it's not really a GitHub lingo, but a git one :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, release-76-rc is a git tag, which is concrete type of a git ref, so it will work. And yes, that's an underlying git thing, not a Github-specific thing.

type: string
required: true
description: The git ref start of comparison range. Prefix branches with `origin/`.
end_git_ref:
type: string
required: true
description: The git ref end of comparison range. Must be descendant of `from_git_ref`. Prefix branches with `origin/`.
# Jira user name & API token is used for processing sensitive tickets comes from Github Secrets
# stored in the repository

jobs:
commit-report:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-tags: true
fetch-depth: 0
# workaround for bug in checkout action. this step should be redundant.
# https://github.com/actions/checkout/issues/1471
# https://github.com/actions/checkout/issues/1781
# https://github.com/actions/checkout/issues/701#issuecomment-1133937950
- name: Fetch all tags
run: |
git fetch --tags origin
- name: Fetch all branches
run: |
git fetch origin
- name: Setup Python
uses: actions/setup-python@v5
with:
python-version: '3.12.8'
cache: 'pipenv'
cache-dependency-path: |
tools/commit-checker/Pipfile
tools/commit-checker/Pipfile.lock
- name: Install pipenv
run: |
sudo pip3 install pipenv
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't venv do the same kind of things (out of the box, no need to install anything)

I did a very quick scan of several articles and there seems to be agreement that pipenv is more powerful.

But I've also seen several recommendations to start with venv, get familiar with virtual environments, and when/if you need more power switch to pipenv.

More power often means added complexity :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I considered that out of scope. This is just automating the existing instructions.

I also don't know enough about either to comment, but I would be interested to learn more, assuming that this topic is orthogonal to the objective of the PR.

Copy link
Member

@sffc sffc Feb 22, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wrote this script and chose pipenv due to its simplicity and reproducibility. It behaves more like a modern package manager. I've tried many ways to install Python dependencies and this is by far my favorite.

I don't like venv because you make a profile global to the system user. Pipenv makes a profile local to the project directory, as it should be. (I think it uses venv under the hood but what's surfaced to the user is a project-local environment.)

- name: Generate report
env:
JIRA_USERNAME: ${{ secrets.COMMIT_CHECKER_JIRA_EMAIL }}
JIRA_PASSWORD: ${{ secrets.COMMIT_CHECKER_JIRA_TOKEN }}
run: |
pushd ./tools/commit-checker
pipenv install
pipenv run python3 check.py \
--jira-query "project=ICU AND fixVersion=${{ inputs.fix_version }}" \
--rev-range "${{ inputs.from_git_ref }}..${{ inputs.end_git_ref }}" > REPORT.md
popd
# https://github.blog/news-insights/product-news/supercharging-github-actions-with-job-summaries/
- name: Reproduce report as workflow job summary
run: |
cat ./tools/commit-checker/REPORT.md >> $GITHUB_STEP_SUMMARY
echo "View the Summary page of this GHA Workflow instance to view the rendered Markdown of this report."
25 changes: 23 additions & 2 deletions docs/processes/release/tasks/miscellaneous.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -57,13 +57,34 @@ merging post RC fixes from trunk and others.
Every commit being shipped in the next ICU release should be labeled with a Jira
ticket that is marked as fixed with the correct fix version. Further, there
should be no Jira tickets marked as fixed with the current fixVersion that do
not have commits. To check this, run the following tool:
not have commits.

### Run locally

To check this, run the following tool:

<https://github.com/unicode-org/icu/tree/main/tools/commit-checker>

Follow the instructions in the README file to generate the report and send it
Follow the instructions in the README file to generate the report locally and send it
for review.

### Run via CI

Alternatively, you can run the "BRS Commit Checker Report" workflow directly from the project page CI
by:

1. Go to the [Actions tab](https://github.com/unicode-org/icu/actions)
1. Click on the "BRS Commit Checker Report" workflow name on the left hand list of workflows
1. Click the "Run workflow" dropdown.

The dropdown should reveal an input form in which to provide inputs

1. Provide the same inputs in the form as you would for a local run of the tool,
as described in the tool's Readme in the instructions above.

The only difference from the local run instructions is that git branch names in the
Actions workflow input form should be prefixed with `origin/`.

---

## Fix Mis-ticketted commits
Expand Down