Still waiting :( On Mon, Nov 10, 2025 at 11:27 PM Jarek Potiuk <[email protected]> wrote:
> One more binding vote would be cool :) > > On Sat, Nov 8, 2025 at 10:40 PM Buğra Öztürk <[email protected]> > wrote: > > > > Thanks, Jens! Exactly, we have issues (will have sub-issues to handle > > multiple use cases) to address these and evolve airflowctl until 1.0. We > > may have even more. > > > > To make it visible if anyone wants to follow up :) We will approach in > two > > categories. Improve validation and better user-friendly errors and help > > text, rather than API responses and robotic help text, and console > outputs. > > First is to add generic validation, such as asking for required fields or > > type checks and warn users accordingly [1]. We will make some parameters > > path parameters according to Pydantic fields, meaning they will be called > > `airflowctl <command> --param=value`, and they will be `airflowctl > > <command> <value>`. This will include another proper validation and error > > handling for path parameters [2]. On the other hand, we will integrate > > auto-generated commands to be able to add proper help texts and inject > > custom error messages simply updating configuration files [3] [4]. > > > > [1] https://github.com/apache/airflow/issues/57633 > > [2] https://github.com/apache/airflow/issues/57634 > > [3] https://github.com/apache/airflow/issues/57632 > > [4] https://github.com/apache/airflow/issues/57721 > > > > > > Thanks for the process improvements, Jarek! > > > > On Sat, Nov 8, 2025 at 7:08 PM Jarek Potiuk <[email protected]> wrote: > > > > > > > > > > Just found the minor diff that locally the source package was named > > > > apache_airflow_ctl-0.1.0rc2-source.tar.gz and SVN had it named > > > > apache_airflow_ctl-0.1.0-source.tar.gz but besides the "rc2" name, > the > > > > files had the same content except there is rc2 in the source folder > of > > > > the TAR when expanding. Not blocking release in my view > > > > > > > > > > > Not blocking indeed, but I think it also might be an artifact of us > pushing > > > the tag twice and lack of proper reproducibility instructions. You > likely > > > used locally the tag that Bugra pushed first. I then re-pushed it. > Also I > > > noticed that "prepare tarball" step was missing in the reproducibility > > > check. Previously (before my last fixes from Friday) the tarballs were > > > automatically prepared when --tag was used with: > > > > > > breeze release-management prepare-airflow-ctl-distributions > > > > > > You could see it when you run `git fetch apache --tags`. When I did it > now > > > on another machine I got this: > > > > > > ! [rejected] airflow-ctl/1.0.0rc2 -> > > > airflow-ctl/1.0.0rc2 (would clobber existing tag) > > > ! [rejected] constraints-3.1.2 -> > constraints-3.1.2 > > > (would clobber existing tag) > > > ! [rejected] constraints-latest -> > constraints-latest > > > (would clobber existing tag) > > > > > > Now it needs a separate step (and this step is now properly > implemented - > > > i.e. it uses both VERSION_RC an VERSION - VERSION_RC is used to > checkout > > > the right tag, where VERSION is used to build the source tarball (we > should > > > never have -rcN suffix in source tarball - it's always considered as > ready > > > to be promoted to "final" without renaming or rebuilding. > > > > > > I added a PR that fixes the instructions, and adds `--force` flag to > get > > > the local old tag overwritten by the new one pushed with --force > (which I > > > did). > > > > > > https://github.com/apache/airflow/pull/58077 > > > > > > Once you follow instructions from this PR - you should get reproducible > > > tarball (I did). > > > > > > J. > > > > > > > > > -- > > Bugra Ozturk >
