Repository navigation
Move Azure Pipelines CI to GitHub Actions #109408
Description
Activity
Hmm, and Azure Pipelines is only running for PRs to
main(not backports); and on the version branches after PRs have been merged, but not for3.12.There are two top-level Azure Pipelines config files:
Azure Pipelines CI
This runs on version branches, after a PR has been merged.
But when we forked 3.12 from
mainin May, we forgot to add'3.12'to the config, so it's not run on that branch at all:trigger: ['main', '3.11', '3.10', '3.9', '3.8', '3.7']
Azure Pipelines PR
This runs when PRs are opened. But it's only running for PRs against
main, not for any of the backport PRs. I'm not sure why.Example
To illustrate, this set of PRs only only had AP builds for
main(python/cpython#109360) and not3.12(
python/cpython#109361) or3.11(#109362).After merge, AP ran for
main(https://dev.azure.com/Python/cpython/_build/results?buildId=137654&view=results) and3.11(https://dev.azure.com/Python/cpython/_build/results?buildId=137657&view=results) but not3.12.For comparison, GitHub Actions runs for PRs for all branches, but not merged pushes to version branches.
I believe @zooba said there were some things being tested on Azure Pipelines that GitHub Actions didn't support?
Azure Pipelines is doing install layout testing using the APPX layout as a second step post-commit. While I'd most like to have the default build match the install layout, this has been a useful way to catch issues in tests that assume a source directory layout. These tests are templated at https://github.com/python/cpython/blob/main/.azure-pipelines/windows-layout-steps.yml and included a few times in
ci.yml.Looks like we could potentially remove the "Tests" step (and "Publish Test Results") from
windows-steps.ymlwithout affecting the layout testing? The main thing inwindows-steps.ymlbeing the CPython build.In addition to the APPX layout step, should we also keep the nuget and embed layout steps?
cpython/.azure-pipelines/ci.yml
Lines 103 to 115 in 3b9d10b
steps: - template: ./windows-steps.yml - template: ./windows-layout-steps.yml parameters: kind: nuget - template: ./windows-layout-steps.yml parameters: kind: embed - template: ./windows-layout-steps.yml parameters: kind: appx fulltest: true Yeah, that would work. But it's post-commit testing anyway, so it isn't holding anyone up. And knowing that the regular tests pass is incredibly valuable when something specific to one of the layouts fails.
I'm pretty sure people are only annoyed by the PR integration. If that goes away, nobody will care unless they're looking for it.
As for the different layouts, the nuget and embed layouts only do really quick tests. I'd keep them all, as it gives us early warning that something has broken them (e.g. a new DLL isn't being copied). Otherwise we won't find out until during the release process when the same tests are run.
Reacted by Hugo van KemenadeSounds good. I suggest we proceed as follows:
- Leave
ci.ymlbe, only changepr.yml - Remove duplicate CI tests from
pr.yml, keepingpatchcheckon AP - Move
patchcheckto GHA, either as is or equivalent lint checks - If necessary, disable "Azure Pipelines PR" via the web UI
- Remove
pr.yml
- Leave
Clarification on 1:
- Leave Windows testing in
ci.ymlbe, change Windows testing inpr.yml
Let's remove Ubuntu unit tests from both
ci.ymlandpr.yml, because they're run on GHA.That leaves only
patchcheckinpr.yml(it's skipped inci.ymlbecause it only makes sense for PRs).Please see PR #109452.
- Leave Windows testing in
- added a commit that references this issue
on Sep 15, 2023 - added a commit that references this issue
on Sep 17, 2023 - added a commit that references this issue
on Sep 18, 2023 26 remaining items
- added a commit that references this issue
on Oct 11, 2023 - addedbuildThe build process and cross-buildThe build process and cross-build
on Dec 1, 2023 - added 5 commits that reference this issue
on Sep 2, 2024 Closing, this is essentially done now.
The remaining Azure Pipelines config is for testing after merge, and can stay to help test packaging the Windows installers.
We've moved all the pre-merge, PR-level stuff into GitHub Actions.
#122333 is still open, but isn't directly about moving AP stuff into GHA.
Reacted by Ege AkmanReacted by Ege Akman
GitHub Actions is easier to use and maintain. For example, GitHub Actions is more popular and widely used, and so more familiar. It's easier to maintain a single system. Also core devs can restart failed GitHub Actions whereas they can't for Azure Pipelines. Both are owned by Microsoft and I believe they run on much the same infra.
There's a lot of duplication of tests between Azure Pipelines and GitHub Actions.
Let's remove the duplicated tests, and move the unique things over to GitHub Actions. For example,
patchcheckis only run on AP.We might not necessarily need to port things directly over, it may be possible to replicate equivalent checks in another way, possible with a pre-commit or Ruff lint rule. Let's evaluate these separately.
Related issues/PRs:
macOS CI TestsandUbuntu CI Tests (coverage)jobs are always skipped #109395Linked PRs
patchcheckin GitHub Actions #109459make linttarget #122333.azure-pipelines/pr.yml#122643