diff --git a/.github/workflows/basic-tests.yml b/.github/workflows/basic-tests.yml index c12468cab1e8b..730c750b083c6 100644 --- a/.github/workflows/basic-tests.yml +++ b/.github/workflows/basic-tests.yml @@ -352,8 +352,8 @@ jobs: --answer yes --dry-run - name: "Test providers metadata generation" run: | - git remote add apache https://github.com/apache/airflow.git - git fetch apache --tags + git remote add upstream https://github.com/apache/airflow.git + git fetch upstream --tags breeze release-management generate-providers-metadata --refresh-constraints-and-airflow-releases env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} diff --git a/AGENTS.md b/AGENTS.md index c1a5007bffaa1..eff2211559818 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -150,18 +150,75 @@ Add a newsfragment for user-visible changes: - NEVER add Co-Authored-By with yourself as co-author of the commit. Agents cannot be authors, humans can be, Agents are assistants. +### Git remote naming conventions + +Airflow standardises on two git remote names, and the rest of this file, the +contributing docs, and the release docs all assume them: + +- **`upstream`** — the canonical `apache/airflow` repository (fetch from here). +- **`origin`** — the contributor's fork of `apache/airflow` (push PR branches here). + +Always push branches to `origin`. Never push directly to `upstream` (and never +push directly to `main` on either remote). + +**Before running any remote-based command, run `git remote -v` and verify the +names match this convention.** If they do not — for example, the upstream remote +is called `apache`, or `origin` points at `apache/airflow` with the fork under a +different name like `fork` — **do not silently go along with the existing +names**. Surface the mismatch to the user and propose the exact rename commands +to bring the checkout in line with the convention, then ask the user to confirm +before running them. Examples: + +- Upstream is named `apache`, fork is `origin` (common legacy layout): + + ```bash + git remote rename apache upstream + ``` + +- `origin` points at `apache/airflow` and the fork is named `fork` (release-manager + / "cloned upstream directly" layout): + + ```bash + git remote rename origin upstream + git remote rename fork origin + ``` + +- Upstream is missing entirely: + + ```bash + git remote add upstream https://github.com/apache/airflow.git + # or, for SSH: + git remote add upstream git@github.com:apache/airflow.git + ``` + +- Fork is missing entirely: + + ```bash + gh repo fork apache/airflow --remote --remote-name origin + ``` + +After any rename/add, re-run `git remote -v` to confirm the new state before +continuing with commands that assume `upstream` / `origin`. + +If a doc, script, or command you're about to run uses the old `apache` name (or +any other variant), **translate it to the `upstream` convention** in what you +propose to the user, rather than perpetuating the old name. Flag the stale +documentation so it can be fixed in a follow-up. + ### Creating Pull Requests -**Always push to the user's fork**, not to the upstream `apache/airflow` repo. Never push -directly to `main`. +**Always push to the user's fork (`origin`)**, not to `upstream` (`apache/airflow`). +Never push directly to `main`. + +Before pushing, confirm the remote setup matches the conventions above +(`upstream` → `apache/airflow`, `origin` → your fork). Run `git remote -v` and, +if the names don't match, propose renames as described in "Git remote naming +conventions" — ask the user to confirm before running them. -Before pushing, determine the fork remote. Check `git remote -v` — if `origin` does **not** -point to `apache/airflow`, use `origin` (it's the user's fork). If `origin` points to -`apache/airflow`, look for another remote that points to the user's fork. If no fork remote -exists, create one: +If the fork remote does not exist at all, create one: ```bash -gh repo fork apache/airflow --remote --remote-name fork +gh repo fork apache/airflow --remote --remote-name origin ``` Before pushing, perform a self-review of your changes following the Gen-AI review guidelines @@ -186,18 +243,18 @@ Before pushing, always rebase your branch onto the latest target branch (usually to avoid merge conflicts and ensure CI runs against up-to-date code: ```bash -git fetch -git rebase / +git fetch upstream +git rebase upstream/ ``` If there are conflicts, resolve them and continue the rebase. If the rebase is too complex, ask the user for guidance. -Then push the branch to the fork remote and open the PR creation page in the browser +Then push the branch to your fork (`origin`) and open the PR creation page in the browser with the body pre-filled (including the generative AI disclosure already checked): ```bash -git push -u +git push -u origin gh pr create --web --title "Short title (under 70 chars)" --body "$(cat <<'EOF' Brief description of the changes. diff --git a/contributing-docs/10_working_with_git.rst b/contributing-docs/10_working_with_git.rst index 9a95afbd490a3..82e97a4111e13 100644 --- a/contributing-docs/10_working_with_git.rst +++ b/contributing-docs/10_working_with_git.rst @@ -26,6 +26,44 @@ that we are using rebase workflow. It also explains how to sync your fork with t :depth: 2 :local: +Git remote naming conventions +============================= + +Airflow documentation, helper scripts (``dev/sync_fork.sh``), release tooling and +agent instructions (``AGENTS.md``) all assume the following two remote names, and +you should configure your local checkout to match: + +* ``upstream`` — the canonical ``apache/airflow`` repository (where you fetch from). +* ``origin`` — your personal fork of ``apache/airflow`` (where you push branches + for PRs). + +Always push PR branches to ``origin``; don't push to ``upstream`` (the branch +protection on ``apache/airflow`` will reject it anyway). Working on dedicated +branches is recommended, though developing directly on your fork's ``main`` is +tolerated — see `Contribution Workflow `_. + +If your existing checkout uses different names (for example ``apache`` for the +Apache remote, or ``origin`` pointing at ``apache/airflow`` with your fork under +another name), rename them to match the convention. Common migrations: + +.. code-block:: bash + + # Case 1: upstream is currently named "apache" + git remote rename apache upstream + + # Case 2: "origin" points at apache/airflow and your fork is named "fork" + git remote rename origin upstream + git remote rename fork origin + + # Case 3: upstream is missing entirely + git remote add upstream https://github.com/apache/airflow.git + # ... or via SSH: + git remote add upstream git@github.com:apache/airflow.git + +Then confirm with ``git remote -v``. Ad-hoc remote names still work for one-off +commands, but the helper scripts and documented workflows below all assume +``upstream`` / ``origin``. + Airflow Git Branches ==================== @@ -68,7 +106,7 @@ How to sync your fork When you have your fork, you should periodically synchronize the main of your fork with the Apache Airflow main. In order to do that you can ``git pull --rebase`` to your local git repository from -apache remote and push the main (often with ``--force`` to your fork). There is also an easy +the ``upstream`` remote and push the main (often with ``--force`` to your fork). There is also an easy way to sync your fork in GitHub's web UI with the `Fetch upstream feature `_. @@ -139,30 +177,30 @@ First of all, we suggest you read about the rebase workflow here: `Merging vs. rebasing `_. This is an excellent article that describes all the ins/outs of the rebase workflow. I recommend keeping it for future reference. -The goal of rebasing your PR on top of ``apache/main`` is to "transplant" your change on top of +The goal of rebasing your PR on top of ``upstream/main`` is to "transplant" your change on top of the latest changes that are merged by others. It also allows you to fix all the conflicts -that arise as a result of other people changing the same files as you and merging the changes to ``apache/main``. +that arise as a result of other people changing the same files as you and merging the changes to ``upstream/main``. Here is how rebase looks in practice (you can find a summary below these detailed steps): 1. You first need to add the Apache project remote to your git repository. This is only necessary once, -so if it's not the first time you are following this tutorial you can skip this step. In this example, -we will be adding the remote as "apache" so you can refer to it easily + so if it's not the first time you are following this tutorial you can skip this step. Per the + `Git remote naming conventions`_ we add it as ``upstream``: -* If you use ssh: ``git remote add apache git@github.com:apache/airflow.git`` -* If you use https: ``git remote add apache https://github.com/apache/airflow.git`` + * If you use ssh: ``git remote add upstream git@github.com:apache/airflow.git`` + * If you use https: ``git remote add upstream https://github.com/apache/airflow.git`` -2. You then need to make sure that you have the latest main fetched from the ``apache`` repository. You can do this +2. You then need to make sure that you have the latest main fetched from the ``upstream`` repository. You can do this via - ``git fetch apache`` (to fetch apache remote) + ``git fetch upstream`` (to fetch upstream remote) ``git fetch --all`` (to fetch all remotes) 3. Assuming that your feature is in a branch in your repository called ``my-branch`` you can easily check what is the base commit you should rebase from via - ``git merge-base my-branch apache/main`` + ``git merge-base my-branch upstream/main`` This will print the HASH of the base commit which you should use to rebase your feature from. For example: ``5abce471e0690c6b8d06ca25685b0845c5fd270f``. Copy that HASH and go to the next step. @@ -201,11 +239,11 @@ we will be adding the remote as "apache" so you can refer to it easily 6. Rebase - ``git rebase HASH --onto apache/main`` + ``git rebase HASH --onto upstream/main`` For example: - ``git rebase 5abce471e0690c6b8d06ca25685b0845c5fd270f --onto apache/main`` + ``git rebase 5abce471e0690c6b8d06ca25685b0845c5fd270f --onto upstream/main`` Rebasing is a good practice recommended to follow for all code changes. @@ -249,9 +287,9 @@ Useful when you understand the flow but don't remember the steps and want a quic git fetch --all git add . git commit - git merge-base my-branch apache/main + git merge-base my-branch upstream/main git checkout my-branch - git rebase HASH --onto apache/main + git rebase HASH --onto upstream/main git push --force-with-lease ------- diff --git a/contributing-docs/18_contribution_workflow.rst b/contributing-docs/18_contribution_workflow.rst index 5a4e8d524cfab..e217154e950a5 100644 --- a/contributing-docs/18_contribution_workflow.rst +++ b/contributing-docs/18_contribution_workflow.rst @@ -165,15 +165,18 @@ Step 4: Prepare PR `How to sync your fork <10_working_with_git.rst#how-to-sync-your-fork>`_ for details. * Create a local branch for your development. Make sure to use latest - ``apache/main`` as base for the branch. See `How to Rebase PR `_ for some details - on setting up the ``apache`` remote. Note, some people develop their changes directly in their own - ``main`` branches - this is OK and you can make PR from your main to ``apache/main`` but we + ``upstream/main`` as base for the branch. See `How to Rebase PR `_ for details + on setting up the ``upstream`` remote (Airflow standardises on ``upstream`` → + ``apache/airflow`` and ``origin`` → your fork — see + `Git remote naming conventions `_). + Note, some people develop their changes directly in their own + ``main`` branches - this is OK and you can make PR from your main to ``upstream/main`` but we recommend to always create a local branch for your development. This allows you to easily compare changes, have several changes that you work on at the same time and many more. - If you have ``apache`` set as remote then you can make sure that you have latest changes in your main - by ``git pull apache main`` when you are in the local ``main`` branch. If you have conflicts and + With ``upstream`` configured you can make sure that you have the latest changes in your main + by ``git pull upstream main`` when you are in the local ``main`` branch. If you have conflicts and want to override your locally changed main you can override your local changes with - ``git fetch apache; git reset --hard apache/main``. + ``git fetch upstream; git reset --hard upstream/main``. * Modify the class and add necessary code and unit tests. diff --git a/dev/MANUALLY_GENERATING_IMAGE_CACHE_AND_CONSTRAINTS.md b/dev/MANUALLY_GENERATING_IMAGE_CACHE_AND_CONSTRAINTS.md index 1d34276d43845..68104fee02d33 100644 --- a/dev/MANUALLY_GENERATING_IMAGE_CACHE_AND_CONSTRAINTS.md +++ b/dev/MANUALLY_GENERATING_IMAGE_CACHE_AND_CONSTRAINTS.md @@ -279,13 +279,15 @@ This is a step-by-step instruction on how to use it: 1. You need to have "airflow" repository checked out separately from the repository you are working on. For example in `/home/myuser/airflow-constraints` folder. 2. You need to checkout `constraints-main` branch in this repository. By default the command expects that - there is a remote named "apache" pointing to the official Apache repository. You can override this - by passing `--remote-name` option to the command. -3. You need to run `breeze release-management update-constraints` command. The `breeze` command comes usually - from another clone of airflow repository - usually from the `main` branch. You should pass those options to + there is a remote named "upstream" pointing to the `apache/airflow` repository (the standard remote + naming convention — see + [`contributing-docs/10_working_with_git.rst`](../contributing-docs/10_working_with_git.rst#git-remote-naming-conventions)). + You can override this by passing `--remote-name` option to the command. +3. You need to run `breeze release-management update-constraints` command. Typically, `breeze` is run + from a separate clone of the Airflow repository, on the `main` branch. You should pass those options to the command: * path to the "constraints" repository - * remote name where the constraints should be pushed (optionally - default "apache") + * remote name where the constraints should be pushed (optionally - default "upstream") * list of airflow versions to update constraints for * list of constraints to update in the form of "package==version" (you can specify it multiple times) * message to be used in the commit message diff --git a/dev/README_RELEASE_AIRFLOW.md b/dev/README_RELEASE_AIRFLOW.md index 6d0b92e510e2b..5d87e5bcdb14c 100644 --- a/dev/README_RELEASE_AIRFLOW.md +++ b/dev/README_RELEASE_AIRFLOW.md @@ -297,9 +297,9 @@ You are likely want to cherry-pick some of the latest doc changes in order to br explanations added to the documentation. Usually you can see the list of such changes via: ```shell -git fetch apache -git log --oneline apache/v3-2-test | sed -n 's/.*\((#[0-9]*)\)$/\1/p' > /tmp/merged -git log --oneline --decorate apache/v2-2-stable..apache/main -- docs/apache-airflow docs/docker-stack/ | grep -vf /tmp/merged +git fetch upstream +git log --oneline upstream/v3-2-test | sed -n 's/.*\((#[0-9]*)\)$/\1/p' > /tmp/merged +git log --oneline --decorate upstream/v2-2-stable..upstream/main -- docs/apache-airflow docs/docker-stack/ | grep -vf /tmp/merged ``` Those changes that are "doc-only" changes should be marked with `type:doc-only` label so that they @@ -307,8 +307,22 @@ land in documentation part of the changelog. The tool to review and assign the l ## Making the cherry picking -It is recommended to clone Airflow upstream (not your fork) and run the commands on -the relevant test branch in this clone. That way origin points to the upstream repo. +It is recommended to clone Airflow from `apache/airflow` directly (not your fork) into a +dedicated release-manager checkout and run the commands on the relevant test branch there. +This repo follows the standard convention that `upstream` → `apache/airflow` and `origin` +→ your fork (see +[`contributing-docs/10_working_with_git.rst`](../contributing-docs/10_working_with_git.rst#git-remote-naming-conventions)), +so in this release-manager clone add `apache/airflow` as `upstream`: + +```shell +git remote add upstream https://github.com/apache/airflow.git +git fetch upstream +``` + +All the commands in this document assume `upstream` is the remote that tracks +`apache/airflow`. If you previously set this up under a different name (e.g. `apache`), +either rename it with `git remote rename apache upstream` or pass the alternative name +via the `--remote-name` option where the commands accept it. To see cherry picking candidates (unmerged PR with the appropriate milestone), from the test branch you can run: @@ -344,7 +358,7 @@ We have the tool that allows to review cherry-picked PRs and assign the labels It allows to manually review and assign milestones and labels to cherry-picked PRs: ```shell -./dev/assign_cherry_picked_prs_with_milestone.py assign-prs --previous-release v2-2-stable --current-release apache/v2-2-test --milestone-number 48 +./dev/assign_cherry_picked_prs_with_milestone.py assign-prs --previous-release v2-2-stable --current-release upstream/v2-2-test --milestone-number 48 ``` It summarises the state of each cherry-picked PR including information whether it is going to be @@ -360,7 +374,7 @@ assumes the `--skip-assigned` flag, so that the summary can be produced without ```shell ./dev/assign_cherry_picked_prs_with_milestone.py assign-prs --previous-release v2-2-stable \ - --current-release apache/v2-2-test --milestone-number 48 --skip-assigned --assume-yes --print-summary \ + --current-release upstream/v2-2-test --milestone-number 48 --skip-assigned --assume-yes --print-summary \ --output-folder /tmp ``` @@ -386,13 +400,13 @@ git show --format=tformat:"" --stat --name-only $(cat /tmp/doc-only-changes.txt) Then if you see suspicious file (example airflow/sensors/base.py) you can find details on where they came from: ```shell -git log apache/v3-2-test --format="%H" -- airflow/sensors/base.py | grep -f /tmp/doc-only-changes.txt | xargs git show +git log upstream/v3-2-test --format="%H" -- airflow/sensors/base.py | grep -f /tmp/doc-only-changes.txt | xargs git show ``` And the URL to the PR it comes from: ```shell -git log apache/v3-2-test --format="%H" -- airflow/sensors/base.py | grep -f /tmp/doc-only-changes.txt | \ +git log upstream/v3-2-test --format="%H" -- airflow/sensors/base.py | grep -f /tmp/doc-only-changes.txt | \ xargs -n 1 git log --oneline --max-count=1 | \ sed s'/.*(#\([0-9]*\))$/https:\/\/github.com\/apache\/airflow\/pull\/\1/' ``` @@ -484,7 +498,7 @@ uv tool install -e ./dev/breeze ```shell script git checkout v${VERSION_BRANCH}-test - git reset --hard origin/v${VERSION_BRANCH}-test + git reset --hard upstream/v${VERSION_BRANCH}-test ``` - Create a new branch from v${VERSION_BRANCH}-test @@ -635,13 +649,14 @@ uv tool install -e ./dev/breeze Before running the actual release command, you can safely test it using: ```shell script - # Test with dry-run (shows what would be executed without doing it) + # Test with dry-run (shows what would be executed without doing it). + # --remote-name defaults to "upstream" per the project convention, so only + # pass it explicitly if you set apache/airflow up under a different name. breeze release-management start-rc-process \ --version ${VERSION_RC} \ --previous-version ${PREVIOUS_VERSION} \ --task-sdk-version ${TASK_SDK_VERSION_RC} \ --sync-branch ${SYNC_BRANCH} \ - --remote-name upstream \ --dry-run ``` @@ -899,7 +914,7 @@ VERSION_SUFFIX=rc1 VERSION_RC=${VERSION}${VERSION_SUFFIX} TASK_SDK_VERSION=X.Y.Z TASK_SDK_VERSION_RC=${TASK_SDK_VERSION}${VERSION_SUFFIX} -git fetch apache --tags +git fetch upstream --tags git checkout ${VERSION_RC} export AIRFLOW_REPO_ROOT=$(pwd) rm -rf dist/* diff --git a/dev/README_RELEASE_AIRFLOWCTL.md b/dev/README_RELEASE_AIRFLOWCTL.md index c643b278d442b..5259f756b4f15 100644 --- a/dev/README_RELEASE_AIRFLOWCTL.md +++ b/dev/README_RELEASE_AIRFLOWCTL.md @@ -167,11 +167,11 @@ export CTL_VERSION_BRANCH=0-2 # most recently released X.Y.Z, e.g. v3-2-stable. export AIRFLOW_STABLE_BRANCH=v3-2-stable -git fetch apache -git checkout -b "airflow-ctl/v${CTL_VERSION_BRANCH}-test" "apache/${AIRFLOW_STABLE_BRANCH}" -git push apache "airflow-ctl/v${CTL_VERSION_BRANCH}-test" +git fetch upstream +git checkout -b "airflow-ctl/v${CTL_VERSION_BRANCH}-test" "upstream/${AIRFLOW_STABLE_BRANCH}" +git push upstream "airflow-ctl/v${CTL_VERSION_BRANCH}-test" git checkout -b "airflow-ctl/v${CTL_VERSION_BRANCH}-stable" "airflow-ctl/v${CTL_VERSION_BRANCH}-test" -git push apache "airflow-ctl/v${CTL_VERSION_BRANCH}-stable" +git push upstream "airflow-ctl/v${CTL_VERSION_BRANCH}-stable" ``` ## Add branch protection for the new stable branch @@ -242,14 +242,14 @@ branch is what you expect: ```shell script # airflow-ctl commits on the test branch since the previous release. git log --oneline \ - "airflow-ctl/${PREVIOUS_VERSION}..apache/airflow-ctl/v${CTL_VERSION_BRANCH}-test" -- airflow-ctl/ + "airflow-ctl/${PREVIOUS_VERSION}..upstream/airflow-ctl/v${CTL_VERSION_BRANCH}-test" -- airflow-ctl/ # Compare against main to spot commits that have NOT yet been cherry-picked. git log --oneline \ - "airflow-ctl/${PREVIOUS_VERSION}..apache/main" -- airflow-ctl/ + "airflow-ctl/${PREVIOUS_VERSION}..upstream/main" -- airflow-ctl/ ``` Everywhere below that mentions "the release branch", substitute -`apache/airflow-ctl/v${CTL_VERSION_BRANCH}-stable` (or `-test` under the +`upstream/airflow-ctl/v${CTL_VERSION_BRANCH}-stable` (or `-test` under the first-RC shortcut). In particular: - The release-prep PR (`Commit the version bump and release notes via a @@ -280,9 +280,9 @@ Wait for CI to pass and for the PR to be merged. After merge, pull release-prep PR also targets `airflow-ctl/vX-Y-stable`. ```shell script -git fetch apache +git fetch upstream git checkout "airflow-ctl/v${CTL_VERSION_BRANCH}-stable" -git reset --hard "apache/airflow-ctl/v${CTL_VERSION_BRANCH}-stable" +git reset --hard "upstream/airflow-ctl/v${CTL_VERSION_BRANCH}-stable" ``` # Airflow-ctl versioning @@ -389,7 +389,7 @@ git add airflow-ctl/src/airflowctl/__init__.py airflow-ctl/RELEASE_NOTES.rst # Also `git rm` any stale newsfragments you cleaned up git commit -m "Prepare airflow-ctl ${VERSION_RC} release" -# Push to your fork (NOT to apache) +# Push to your fork (origin), NOT to upstream (apache/airflow) git push -u origin "prepare-airflow-ctl-${VERSION_RC}" # Open the PR in the browser, pre-filled. Adjust --base to the release branch. @@ -410,7 +410,7 @@ your local `HEAD` matches the commit you are about to tag: # Substitute the branch you are releasing from. RELEASE_BRANCH="airflow-ctl/v${CTL_VERSION_BRANCH}-stable" # or -test under the first-RC shortcut git checkout "${RELEASE_BRANCH}" -git pull apache "${RELEASE_BRANCH}" +git pull upstream "${RELEASE_BRANCH}" ``` ## Build airflow-ctl distributions for SVN apache upload @@ -489,8 +489,9 @@ rm -rf ${AIRFLOW_REPO_ROOT}/dist/* ## Add tags in git -Assume that your remote for apache repository is called `apache` you should now -set tags for the airflow-ctl in the repo. +These instructions assume the standard remote naming convention +(`upstream` → `apache/airflow`, `origin` → your fork). Set tags for airflow-ctl +in the repo. **Prerequisite:** the version-bump + release-notes PR from "Commit the version bump and release notes via a merged PR" must already be merged, and your local @@ -502,7 +503,7 @@ and lead to annoying errors. The default behaviour would be to clean such local ```shell script git tag -s "airflow-ctl/${VERSION_RC}" -git push apache "airflow-ctl/${VERSION_RC}" +git push upstream "airflow-ctl/${VERSION_RC}" ``` * Release candidate packages. **Default to the Docker build** per the @@ -917,7 +918,7 @@ Choose the tag you used for release: ```shell cd "${AIRFLOW_REPO_ROOT}" -git fetch apache --tags --force +git fetch upstream --tags --force git checkout airflow-ctl/${VERSION_RC} ``` @@ -1297,8 +1298,9 @@ Copy links to updated package and save it on the side. You will need it for the ## Add the final release tag in git -Assume that your remote for apache repository is called `apache` you should now -set tags for airflow-ctl in the repo. +These instructions assume the standard remote naming convention +(`upstream` → `apache/airflow`, `origin` → your fork). Set tags for airflow-ctl +in the repo. Sometimes in cases when there is a connectivity issue to GitHub, it might be possible that local tags get created and lead to annoying errors. The default behaviour would be to clean such local tags up. @@ -1307,7 +1309,7 @@ If you want to disable this behaviour, set the env **CLEAN_LOCAL_TAGS** to false ```shell script git tag -s airflow-ctl/${VERSION} -git push apache airflow-ctl/${VERSION} +git push upstream airflow-ctl/${VERSION} ``` ## Publish documentation diff --git a/dev/README_RELEASE_HELM_CHART.md b/dev/README_RELEASE_HELM_CHART.md index e5e32495dc175..8f95290c62e62 100644 --- a/dev/README_RELEASE_HELM_CHART.md +++ b/dev/README_RELEASE_HELM_CHART.md @@ -214,12 +214,15 @@ the same between voted release candidate and final release. Because of this the version in the built artifacts that will become the official Apache releases must not include the rcN suffix. -Make sure you have `apache` remote set up pointing to the apache git repo. +Make sure you have the `upstream` remote set up pointing to the apache git repo +(per the standard convention `upstream` → `apache/airflow`, `origin` → your fork — +see +[`contributing-docs/10_working_with_git.rst`](../contributing-docs/10_working_with_git.rst#git-remote-naming-conventions)). If needed, add it with: ```shell -git remote add apache git@github.com:apache/airflow.git -git fetch apache +git remote add upstream git@github.com:apache/airflow.git +git fetch upstream ``` - We currently release Helm Chart from `main` branch: @@ -233,7 +236,7 @@ git checkout apache/chart/v1-2x-test For releasing 2.x.x and onwards ```shell -git checkout apache/main +git checkout upstream/main ``` - Clean the checkout: (note that this step will also clean any IDE settings you might have so better to @@ -359,7 +362,7 @@ popd ```shell cd ${AIRFLOW_REPO_ROOT} - git push apache tag helm-chart/${VERSION}${VERSION_SUFFIX} + git push upstream tag helm-chart/${VERSION}${VERSION_SUFFIX} ``` ## Publish rc documentation @@ -863,7 +866,7 @@ Create and push the release tag: cd "${AIRFLOW_REPO_ROOT}" git checkout helm-chart/${VERSION}${VERSION_SUFFIX} git tag -s helm-chart/${VERSION} -m "Apache Airflow Helm Chart ${VERSION}" -git push apache helm-chart/${VERSION} +git push upstream helm-chart/${VERSION} ``` ## Publish final documentation diff --git a/dev/README_RELEASE_PROVIDERS.md b/dev/README_RELEASE_PROVIDERS.md index d274c400dff07..b1c6e23f6602f 100644 --- a/dev/README_RELEASE_PROVIDERS.md +++ b/dev/README_RELEASE_PROVIDERS.md @@ -401,14 +401,16 @@ rm -rf ${AIRFLOW_REPO_ROOT}/dist/* * Release candidate packages: -Assume that your remote for apache repository is called `apache` you should now -set tags for the providers in the repo. +These instructions assume the standard remote naming convention +(`upstream` → `apache/airflow`, `origin` → your fork — see +[`contributing-docs/10_working_with_git.rst`](../contributing-docs/10_working_with_git.rst#git-remote-naming-conventions)). +Set tags for the providers in the repo. ```shell script echo "Tagging with providers/${RELEASE_DATE}" git tag -s providers/${RELEASE_DATE} -m "Tag providers for ${RELEASE_DATE}" --force -git push apache providers/${RELEASE_DATE} +git push upstream providers/${RELEASE_DATE} breeze release-management prepare-provider-distributions --include-removed-providers --distribution-format both breeze release-management prepare-tarball --tarball-type apache_airflow_providers --version "${RELEASE_DATE}" ``` @@ -421,7 +423,7 @@ if you only build few packages, run: ```shell script echo "Tagging with providers/${RELEASE_DATE}" git tag -s providers/${RELEASE_DATE} -m "Tag providers for ${RELEASE_DATE}" --force -git push apache providers/${RELEASE_DATE} +git push upstream providers/${RELEASE_DATE} breeze release-management prepare-provider-distributions --include-removed-providers --distribution-format both PACKAGE PACKAGE .... breeze release-management prepare-tarball --tarball-type apache_airflow_providers --version "${RELEASE_DATE}" @@ -853,7 +855,7 @@ cd "$AIRFLOW_REPO_ROOT" ```shell cd "$AIRFLOW_REPO_ROOT" -git fetch apache --tags +git fetch upstream --tags git checkout providers/${RELEASE_DATE} ``` @@ -1390,8 +1392,13 @@ Copy links to updated packages, sort it alphabetically and save it on the side. ## Add the final release tag in git -Assume that your remote for apache repository is called `apache` you should now -set tags for the providers in the repository. +These instructions assume the standard remote naming convention +(`upstream` → `apache/airflow`, `origin` → your fork — see +[`contributing-docs/10_working_with_git.rst`](../contributing-docs/10_working_with_git.rst#git-remote-naming-conventions)). +`breeze release-management tag-providers` auto-detects which of your remotes points +at `apache/airflow`, so it also works for release-manager setups where the +apache/airflow clone is configured as `origin`. Set tags for the providers in the +repository. Sometimes in cases when there is a connectivity issue to GitHub, it might be possible that local tags get created and lead to annoying errors. The default behavior would be to clean such local tags up. @@ -1468,7 +1475,7 @@ Create PR and open it to be merged: ```shell script cd "$AIRFLOW_REPO_ROOT" git checkout main -git pull apache main +git pull upstream main current_date=$(date '+%Y-%m-%d%n') branch="update-providers-metadata-${current_date}" git checkout -b "${branch}" diff --git a/dev/README_RELEASE_PYTHON_CLIENT.md b/dev/README_RELEASE_PYTHON_CLIENT.md index bcecb64157228..5735358aa1530 100644 --- a/dev/README_RELEASE_PYTHON_CLIENT.md +++ b/dev/README_RELEASE_PYTHON_CLIENT.md @@ -181,7 +181,7 @@ git diff HEAD git checkout -b release-${VERSION} git add . git commit -m "Update Python Client to ${VERSION_RC}" -git push apache release-${VERSION} +git push upstream release-${VERSION} ``` Then open a PR and merge it into main. @@ -195,10 +195,10 @@ Then open a PR and merge it into main. ```shell script cd ${AIRFLOW_REPO_ROOT} git tag -s python-client/${VERSION_RC} -m "Airflow Python Client ${VERSION_RC}" -git push apache python-client/${VERSION_RC} +git push upstream python-client/${VERSION_RC} cd ${CLIENT_REPO_ROOT} git tag -s ${VERSION_RC} -m "Airflow Python Client ${VERSION_RC}" -git push apache tag ${VERSION_RC} +git push upstream tag ${VERSION_RC} ``` - Build the source package after the above tags have been pushed: @@ -492,11 +492,14 @@ binary-reproduced when built from the sources. cd "${AIRFLOW_REPO_ROOT}" ``` -2) Check out the ``python-client`` tag (assume apache is the remote name of the repository): +2) Check out the ``python-client`` tag (the commands below assume the standard + remote naming convention `upstream` → `apache/airflow`, `origin` → your fork — + see + [`contributing-docs/10_working_with_git.rst`](../contributing-docs/10_working_with_git.rst#git-remote-naming-conventions)): ```shell cd "${AIRFLOW_REPO_ROOT}" -git fetch apache --tags +git fetch upstream --tags git checkout python-client/${VERSION_RC} ``` @@ -880,7 +883,7 @@ twine upload -r pypi *${VERSION}.tar.gz *.whl cd ${AIRFLOW_REPO_ROOT} git checkout python-client/${VERSION}${VERSION_SUFFIX} git tag -s python-client/${VERSION} -m "Airflow Python Client ${VERSION}" -git push apache tag python-client/${VERSION} +git push upstream tag python-client/${VERSION} cd ${CLIENT_REPO_ROOT} git checkout ${VERSION}${VERSION_SUFFIX} git tag -s ${VERSION} -m ${VERSION} diff --git a/dev/breeze/doc/adr/0003-bootstrapping-virtual-environment.md b/dev/breeze/doc/adr/0003-bootstrapping-virtual-environment.md index a2788b57c4f0f..bd8173a4e3313 100644 --- a/dev/breeze/doc/adr/0003-bootstrapping-virtual-environment.md +++ b/dev/breeze/doc/adr/0003-bootstrapping-virtual-environment.md @@ -68,7 +68,7 @@ of the user who is developing Airflow. ./Breeze should use the version of Breeze that is available in this version -* git rebase --onto apache/main +* git rebase --onto upstream/main ./Breeze should be automatically updated to the latest version available in main (including dependencies) diff --git a/dev/breeze/doc/images/output_release-management_start-rc-process.svg b/dev/breeze/doc/images/output_release-management_start-rc-process.svg index e5862980106e9..19f8f94d5d31f 100644 --- a/dev/breeze/doc/images/output_release-management_start-rc-process.svg +++ b/dev/breeze/doc/images/output_release-management_start-rc-process.svg @@ -1,4 +1,4 @@ - +