-
-
Notifications
You must be signed in to change notification settings - Fork 32.6k
gh-137242: Add Android CI job #137186
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.
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
gh-137242: Add Android CI job #137186
Changes from 12 commits
97ffb3e
bd7b642
1d8dc2f
51ee923
0d1b6d1
67c7af3
16f1230
563ca5a
bd876f4
6b9184c
55b91f7
56bed39
f7f9f44
4807047
b3daf4b
c9700e4
e8e2a9e
7e87375
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,77 @@ | ||
# This is coded as an action rather than a workflow so the release-tools | ||
# repository can load it from a dynamically-chosen commit. Cross-repository | ||
# workflow calls must have a Git reference hard-coded in the calling workflow, | ||
# but actions can be run dynamically from the runner's filesystem. | ||
|
||
name: Build and test (Android) | ||
description: Build and test (Android) | ||
|
||
inputs: | ||
triplet: | ||
description: Host triplet | ||
required: true | ||
|
||
runs: | ||
using: composite | ||
|
||
steps: | ||
# The steps of a composite action are not clearly divided in the GitHub | ||
# UI, so use a single step with ::group:: markers instead. | ||
- shell: bash | ||
env: | ||
triplet: ${{ inputs.triplet }} | ||
# The `name` of a composite action step doesn't appear anywhere in the | ||
# GitHub UI, so put it in a comment on the first line instead. | ||
run: | | ||
# Build and test (Android) | ||
echo "::group::Configure build Python" | ||
freakboy3742 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
./Android/android.py configure-build | ||
echo "::endgroup::" | ||
echo "::group::Compile build Python" | ||
mhsmith marked this conversation as resolved.
Show resolved
Hide resolved
|
||
./Android/android.py make-build | ||
echo "::endgroup::" | ||
echo "::group::Configure host Python" | ||
./Android/android.py configure-host $triplet | ||
echo "::endgroup::" | ||
echo "::group::Compile host Python" | ||
./Android/android.py make-host $triplet | ||
echo "::endgroup::" | ||
echo "::group::Make release package" | ||
./Android/android.py package $triplet | ||
echo "::endgroup::" | ||
if [ "$RUNNER_OS" = "Linux" ] && [ "$RUNNER_ARCH" = "X64" ]; then | ||
# https://github.blog/changelog/2024-04-02-github-actions-hardware-accelerated-android-virtualization-now-available/ | ||
echo "::group::Enable KVM for Android emulator" | ||
echo 'KERNEL=="kvm", GROUP="kvm", MODE="0666", OPTIONS+="static_node=kvm"' \ | ||
| sudo tee /etc/udev/rules.d/99-kvm4all.rules | ||
sudo udevadm control --reload-rules | ||
sudo udevadm trigger --name-match=kvm | ||
echo "::endgroup::" | ||
echo "::group::Unpack release artifact" | ||
mkdir $RUNNER_TEMP/android | ||
tar -C $RUNNER_TEMP/android -xf cross-build/$triplet/dist/* | ||
echo "::endgroup::" | ||
echo "::group::Tests" | ||
# Arguments are similar to --fast-ci, but in single-process mode. | ||
$RUNNER_TEMP/android/android.py test --managed maxVersion -v -- \ | ||
--single-process --fail-env-changed --rerun --slowest --verbose3 \ | ||
-u "all,-cpu" --timeout=600 | ||
echo "::endgroup::" | ||
else | ||
echo "Skipping test: GitHub Actions currently only supports the" \ | ||
"Android emulator on Linux x86_64." | ||
fi | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Regardless of the action vs reusable workflow discussion, it's best to move this entire script into a dedicated file ( There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So... we have that script already - it's the There's multiple invocations of the script because there are multiple "substeps" inside that script - and this script is calling each of those substeps individually so that the log has clear visibility on which step fails (if and when it fails). It's the need to visualise those individual workflow steps (vs the There's also one step - the KVM configuration - that is Github Actions specific. I guess one option would be to encode this sequence as a That said - given that we can't easily have a reusable workflow here, and a Makefile target with There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, kind of. This is something that I'm exploring in my Still, I've grown to like moving more things into the unified workflow tool that a give project has (tox/nox/make/whatever). This makes it possible to reuse things outside a single platform. It is possible to detect running under GHA (https://github.com/ansible/awx-plugins/blob/c4180cd/toxfile.py#L16). And this allows having grouping set up in the Python script that would also work locally (https://github.com/deadsnakes/action/blob/5344dcb/bin/install-python#L22-L33). So I wouldn't try to put There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Of course |
||
- uses: actions/upload-artifact@v4 | ||
with: | ||
name: ${{ inputs.triplet }} | ||
path: cross-build/${{ inputs.triplet }}/dist/* | ||
if-no-files-found: error |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes sense; but it also raises an eyebrow because this is something that no other platform has needed. I presume this is because no other platform that is generating binary artefacts is doing so with the tooling in
release-tools
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@webknjaz, do you have any thougts here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll take a look, thanks for tagging.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mhsmith so I've tried to understand the context and this justtification didn't make sense to me.
It is perfectly possible to call reusable workflows from other repositories (in fact, this is what I'm building my
reusable-tox.yml
ecosystem on).My understanding is that this is meant to be used in https://github.com/python/release-tools/blob/698deaf2ebff433a6ab9d4b5ded97a40fce109a1/.github/workflows/source-and-docs-release.yml, right?
In any case, I've been moving away from composite actions in favor of reusable workflows. This is because composite actions (or any actions for that matter) are represented as a single step in job runs. And it's rather difficult to inspect what actions are doing. So from the troubleshooting perspective, I'd strongly advise against composite actions.
It is important to make every step visible and transparent. And if you follow the practice I established with reusable workflows as modules in here, this is definitely possible.
I started with in-repo "modules" two years ago because I was solving the problem of making it possible to collect all the job statuses in a single check (for branch protection). This wasn't because it's somehow impossible to host them externally. This was just not something necessary for that purpose.
@encukou I've actually been meaning to ask if there's any workflows that are being duplicated in the python org. If yes, it'd make sense to host them in a shared repository. This could be a
.github
repo or even thatrelease-tools
one (although, I don't know if it makes semantic sense). This is a separate question, though.That said, if you've faced any confusion or need help adapting this to be a reusable workflow, just let me know where you're stuck. I can help you navigate this or just rewrite it for you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now,
release-tools
only creates source zips and docs artifacts. See https://github.com/python/release-tools/actions/runs/16450411678 for 3.14 RC2.The Windows artifacts are built in Azure Pipelines, here's RC2. And Ned builds the macOS artifacts. (
release-tools
later takes these Windows and macOS artifacts and signs and uploads them.)We're hoping to build the macOS artifacts using CI in the near future, so what we decide here may help inform how to do that to :)
Yes, see https://github.com/python/release-tools/pull/265/files#diff-4d14704b6b88fb06db888f96c03a8e9b3a5e07a4ee566d97d4111b2c05210e84R220.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One thing I'd like to see is CI in this repo to check Android builds okay, so we don't get caught ought on release day because we only build in
release-tools
.This happened in 3.14 RC1 with the plaintext docs, which had broken back in April or so, but RC1 is the first prerelease to build docs and we hadn't caught it here.
One deciding factor for whether we have stuff over here (via composite actions or something else) might be how much difference there'll be between different versions (3.14, 3.15, etc). If a lot, we might not want it all in
release-tools
and would benefit from versioning things in branches over here.On the other hand, the docs build is also versioned in branches here,
release-tools
CI calls amake dist
command in this repo.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's more or less the way I've been trying to suggest.