Chart: Add instructions to Update Helm Repo before upgrade

[kaxil]

This adds some docs to make this more visible. Also updates the step to remove old artifacts after a day or keep current + last artifact in release svn repo.

---

^ Add meaningful description above

Read the Pull Request Guidelines for more information.
In case of fundamental code change, Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in UPDATING.md.

[potiuk]

Just to explore it still @kaxil.

I am not convinced what is the best way. I still think we CAN publish index with .yaml with "archives", it's just important what is the timing of this publishing.

From what I saw, the delays of copying "downloads" to "archives" is small (I believe it is less than hour always from earlier discussions). In fact, the release policy of ASF specifically mentions: "downloads.apache.org is automatically archived. Therefore, a copy of an official release will already exist in the archives. To move a release to the archives, just delete the copy in your project's dist directory. Remember to update any links from the download page."

And I think it is in our hands to delay publishing the new index.yaml whenever we save chart to the repository. We have two options:

• we could wait with publishing the new index.yaml until "archives" copy is available (and make announcements an hour later).
• we could also make it a "stage" publishing - ie. publish "downloads" link together with SVN update, and automatically replace it with "archives" when the archive copy is available

I think both scenarios provide "uninterrupted" use of helm chart and we can fully automate both of those scenarios. And also the first case ("delay") prevents our users the surprises like https://apache-airflow.slack.com/archives/C027H098M1C/p1627440863116600 where it basically invalidates the old index you already have locally cached. The error message in this case is not telling too much and I think there is a benefit with having the "stable" links to download the charts.

[kaxil]

@jarek Potiuk The problem I have observed is it takes some more time to sync to archive.

we could wait with publishing the new index.yaml until "archives" copy is available (and make announcements an hour later).

I like this

[potiuk]

@jarek Potiuk The problem I have observed is it takes some more time to sync to archive.

Checking with infra

[potiuk]

I like this

We could even add a separate step in CI of airlfow-site - to wait until the artifacts are available - in case index.yml change (and send notification via mail or something when they are).

[potiuk]

All right. Case closed:

[github-actions]

The PR is likely OK to be merged with just subset of tests for default Python and Database versions without running the full matrix of tests, because it does not modify the core of Airflow. If the committers decide that the full tests matrix is needed, they will add the label 'full tests needed'. Then you should rebase to the latest main or amend the last commit of the PR, and push it with --force-with-lease.