You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by GitBox <gi...@apache.org> on 2022/12/30 18:07:52 UTC
[GitHub] [airflow] eladkal opened a new pull request, #28651: Prepare docs for Jan 2023 wave of Providers
eladkal opened a new pull request, #28651:
URL: https://github.com/apache/airflow/pull/28651
<!--
Thank you for contributing! Please make sure that your code changes
are covered with tests. And in case of new features or big changes
remember to adjust the documentation.
Feel free to ping committers for the review!
In case of an existing issue, reference it using one of the following:
closes: #ISSUE
related: #ISSUE
How to write a good git commit message:
http://chris.beams.io/posts/git-commit/
-->
---
**^ Add meaningful description above**
Read the **[Pull Request Guidelines](https://github.com/apache/airflow/blob/main/CONTRIBUTING.rst#pull-request-guidelines)** for more information.
In case of fundamental code changes, an Airflow Improvement Proposal ([AIP](https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvement+Proposals)) is needed.
In case of a new dependency, check compliance with the [ASF 3rd Party License Policy](https://www.apache.org/legal/resolved.html#category-x).
In case of backwards incompatible changes please leave a note in a newsfragment file, named `{pr_number}.significant.rst` or `{issue_number}.significant.rst`, in [newsfragments](https://github.com/apache/airflow/tree/main/newsfragments).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] potiuk commented on a diff in pull request #28651: Prepare docs for Jan 2023 wave of Providers
Posted by GitBox <gi...@apache.org>.
potiuk commented on code in PR #28651:
URL: https://github.com/apache/airflow/pull/28651#discussion_r1059553691
##########
airflow/providers/imap/CHANGELOG.rst:
##########
@@ -24,6 +24,16 @@
Changelog
---------
+3.1.1
+.....
+
+Misc
+~~~~
+ * ``[misc] Get rid of 'pass' statement in conditions (#27775)``
Review Comment:
I personally would not remove it ferom the release.
I usually released all of the "actual" changes. If the release did not make any code modifications it could be marked as "doc only change" - which means that documentation would be updated but the package itself was not released.
With such "small" code changes, it's always on the fence and I think this is just a question of "do we want to mess arround with the same change next time when we release" or "should we release now and forget about it".
From the release manager point of view - I prefer to release any "potentially breaking changes" as soon as they are merged. Even if they are just "pass" statement removals. Because even smallest code changes might contain completely non-obvious bugs.
The mantra "release early, release often" is very much applicable here. What if you keep on doing it (not releasing this change), then not releasing next similar "innocent" refactor next month for the same provider, and so on. And then releasing 5 such changes in 5 months when there is a bigger change and finding out that one of those "innocent" changes broke something. But in 5 months you not only have to spend time finding out which one broke it but also the person who made the change will completely forgot on why and how or might be not available any more.
By releasing now (and adding the "Status" Issue - you add an extra "peer" pressure on the user who implemented it. It is fresh. The user still remembers it. And more often than not they will actually install the new provider RC and do some testing with it. And even if not, if someone else finds a bug in the newly released provider, you know immediately whom to ask for help. Do you think it will happen if you release 5 similar changes are released together in 5 months? I think it's far, far, far less likely.
I think not relasing now is optimizing the wront thing. By not realising we seem to optimize "number of releases in PyPI". Which is wrong optimization goal IMHO. There is virtually no overhead for maintainers nor for users to release it - because releases are all automated, and MOST users will just get the bundle together with new version of Airflow. And those users who actually care and install new providers when they are relased will actually appreciate if there are many smaller upgrades rather than than one bigger upgrade because it is easier to go back and investigating problem when it happens.
Release (and upgrade) early and often - as counter-intuitive as it is., it gives much better results than release less often.
##########
airflow/providers/imap/CHANGELOG.rst:
##########
@@ -24,6 +24,16 @@
Changelog
---------
+3.1.1
+.....
+
+Misc
+~~~~
+ * ``[misc] Get rid of 'pass' statement in conditions (#27775)``
Review Comment:
I personally would not remove it feom the release.
I usually released all of the "actual" changes. If the release did not make any code modifications it could be marked as "doc only change" - which means that documentation would be updated but the package itself was not released.
With such "small" code changes, it's always on the fence and I think this is just a question of "do we want to mess arround with the same change next time when we release" or "should we release now and forget about it".
From the release manager point of view - I prefer to release any "potentially breaking changes" as soon as they are merged. Even if they are just "pass" statement removals. Because even smallest code changes might contain completely non-obvious bugs.
The mantra "release early, release often" is very much applicable here. What if you keep on doing it (not releasing this change), then not releasing next similar "innocent" refactor next month for the same provider, and so on. And then releasing 5 such changes in 5 months when there is a bigger change and finding out that one of those "innocent" changes broke something. But in 5 months you not only have to spend time finding out which one broke it but also the person who made the change will completely forgot on why and how or might be not available any more.
By releasing now (and adding the "Status" Issue - you add an extra "peer" pressure on the user who implemented it. It is fresh. The user still remembers it. And more often than not they will actually install the new provider RC and do some testing with it. And even if not, if someone else finds a bug in the newly released provider, you know immediately whom to ask for help. Do you think it will happen if you release 5 similar changes are released together in 5 months? I think it's far, far, far less likely.
I think not relasing now is optimizing the wront thing. By not realising we seem to optimize "number of releases in PyPI". Which is wrong optimization goal IMHO. There is virtually no overhead for maintainers nor for users to release it - because releases are all automated, and MOST users will just get the bundle together with new version of Airflow. And those users who actually care and install new providers when they are relased will actually appreciate if there are many smaller upgrades rather than than one bigger upgrade because it is easier to go back and investigating problem when it happens.
Release (and upgrade) early and often - as counter-intuitive as it is., it gives much better results than release less often.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] potiuk commented on a diff in pull request #28651: Prepare docs for Jan 2023 wave of Providers
Posted by GitBox <gi...@apache.org>.
potiuk commented on code in PR #28651:
URL: https://github.com/apache/airflow/pull/28651#discussion_r1059672879
##########
docs/apache-airflow-providers-ftp/index.rst:
##########
@@ -35,6 +35,12 @@ Content
Operators <operators/index>
+.. toctree::
+ :hidden:
+ :caption: System tests
+
+ System Tests <_api/tests/system/providers/ftp/index>
+
Review Comment:
Ok. I know the reason.
https://github.com/apache/airflow/commit/39f501d4f4e87635c80d97bb599daf61096d23b8 added the TOC entry BUT in the section that is automatically generated and when you regenerated it, it was removed in your PR.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] eladkal commented on a diff in pull request #28651: Prepare docs for Jan 2023 wave of Providers
Posted by GitBox <gi...@apache.org>.
eladkal commented on code in PR #28651:
URL: https://github.com/apache/airflow/pull/28651#discussion_r1059654006
##########
docs/apache-airflow-providers-ftp/index.rst:
##########
@@ -35,6 +35,12 @@ Content
Operators <operators/index>
+.. toctree::
+ :hidden:
+ :caption: System tests
+
+ System Tests <_api/tests/system/providers/ftp/index>
+
Review Comment:
I'm not sure why the static tests fails on
```
Checking docs/apache-airflow-providers-ftp/index.rst
The docs/apache-airflow-providers-ftp/index.rst does not contain System Tests TOC.
Make sure to add those lines to docs/apache-airflow-providers-ftp/index.rst:
.. toctree::
:hidden:
:caption: System tests
System Tests <_api/tests/system/providers/ftp/index>
```
In this PR. I would expect this to present failure on the PR that added the system tests for the provider https://github.com/apache/airflow/pull/26974?
@potiuk is this expected?
in any case this commit should solve the problem
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] eladkal merged pull request #28651: Prepare docs for Jan 2023 wave of Providers
Posted by GitBox <gi...@apache.org>.
eladkal merged PR #28651:
URL: https://github.com/apache/airflow/pull/28651
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] eladkal commented on pull request #28651: Prepare docs for Jan 2023 wave of Providers
Posted by GitBox <gi...@apache.org>.
eladkal commented on PR #28651:
URL: https://github.com/apache/airflow/pull/28651#issuecomment-1368887036
Should be OK now
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] eladkal commented on a diff in pull request #28651: Prepare docs for Jan 2023 wave of Providers
Posted by GitBox <gi...@apache.org>.
eladkal commented on code in PR #28651:
URL: https://github.com/apache/airflow/pull/28651#discussion_r1059514820
##########
airflow/providers/imap/CHANGELOG.rst:
##########
@@ -24,6 +24,16 @@
Changelog
---------
+3.1.1
+.....
+
+Misc
+~~~~
+ * ``[misc] Get rid of 'pass' statement in conditions (#27775)``
Review Comment:
The PR changed several providers I think it's preferred to release all of it at the same wave?
##########
airflow/providers/sftp/CHANGELOG.rst:
##########
@@ -24,6 +24,18 @@
Changelog
---------
+4.2.1
+.....
+
+Misc
+~~~~
+
+* ``Update codespell and fix typos (#28568)``
+* ``[misc] Get rid of 'pass' statement in conditions (#27775)``
Review Comment:
same comment as above :)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] potiuk commented on pull request #28651: Prepare docs for Jan 2023 wave of Providers
Posted by GitBox <gi...@apache.org>.
potiuk commented on PR #28651:
URL: https://github.com/apache/airflow/pull/28651#issuecomment-1368133730
> I'm not sure it matters, I think it'd make more sense to have "meaningful" releases of any given provider.
> I think it is ultimately up to the release manager though.
Just one comment here as well. I think it's also the matter of an agreement and general approach between the release managers when there is more than one.
Because it is not only the decision impacting this single release, but it ALSO (and this is more important) impacts future releases of the same provider - i.e.. this change will have to be dealt with eventually. It could be done in the current release (by the current release manager) or in the future release (by the future one). I think any changes like that should be dealt with as soon as possible (for the reasons explained above - the more time passes, the more "accumulation" of potential problems occur, the less "blurry" the memory about the changes introduced is and the less likely the contributor of a given change will help.
The bad thing is - if you think about future self or future other relase manager is that the more we dely such release, the more difficult it might get to handle and you can either "face it" now or let you (or someone else) "face it" later.
There is another angle of it. When you say "we released all there is to relase" as a release manager you say "I've completed the job fully and the next release manager has to care only about future changes". Vs. "ok I let the future release manager (which might be you) handle that in the future.".
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] eladkal commented on a diff in pull request #28651: Prepare docs for Jan 2023 wave of Providers
Posted by GitBox <gi...@apache.org>.
eladkal commented on code in PR #28651:
URL: https://github.com/apache/airflow/pull/28651#discussion_r1059519942
##########
airflow/providers/imap/CHANGELOG.rst:
##########
@@ -24,6 +24,16 @@
Changelog
---------
+3.1.1
+.....
+
+Misc
+~~~~
+ * ``[misc] Get rid of 'pass' statement in conditions (#27775)``
Review Comment:
let me drop it from the release
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] eladkal commented on pull request #28651: Prepare docs for Jan 2023 wave of Providers
Posted by GitBox <gi...@apache.org>.
eladkal commented on PR #28651:
URL: https://github.com/apache/airflow/pull/28651#issuecomment-1368482172
@potiuk are we ok with the common.sql version? it's the last thing to resolve before proceeding
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] potiuk commented on a diff in pull request #28651: Prepare docs for Jan 2023 wave of Providers
Posted by GitBox <gi...@apache.org>.
potiuk commented on code in PR #28651:
URL: https://github.com/apache/airflow/pull/28651#discussion_r1059553934
##########
airflow/providers/sftp/CHANGELOG.rst:
##########
@@ -24,6 +24,18 @@
Changelog
---------
+4.2.1
+.....
+
+Misc
+~~~~
+
+* ``Update codespell and fix typos (#28568)``
+* ``[misc] Get rid of 'pass' statement in conditions (#27775)``
Review Comment:
Same comment as above. If there are code changes -> release. Early and often. This is the mantra I will keep on repeating, becaus I think avoiding releases is optimising the wrong thing.
The whole automation about releasing providers was built around that premise and mantra.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] potiuk commented on a diff in pull request #28651: Prepare docs for Jan 2023 wave of Providers
Posted by GitBox <gi...@apache.org>.
potiuk commented on code in PR #28651:
URL: https://github.com/apache/airflow/pull/28651#discussion_r1059671814
##########
docs/apache-airflow-providers-ftp/index.rst:
##########
@@ -35,6 +35,12 @@ Content
Operators <operators/index>
+.. toctree::
+ :hidden:
+ :caption: System tests
+
+ System Tests <_api/tests/system/providers/ftp/index>
+
Review Comment:
Do you happen to have a link to the job where it failed (it's green now)?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] potiuk commented on a diff in pull request #28651: Prepare docs for Jan 2023 wave of Providers
Posted by GitBox <gi...@apache.org>.
potiuk commented on code in PR #28651:
URL: https://github.com/apache/airflow/pull/28651#discussion_r1059791678
##########
docs/apache-airflow-providers-ftp/index.rst:
##########
@@ -35,6 +35,12 @@ Content
Operators <operators/index>
+.. toctree::
+ :hidden:
+ :caption: System tests
+
+ System Tests <_api/tests/system/providers/ftp/index>
+
Review Comment:
Not really. It was just added in a wrong place. But our automation should filter out those automatically added statements and maybe explain it better. PR in a moment.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] eladkal commented on a diff in pull request #28651: Prepare docs for Jan 2023 wave of Providers
Posted by GitBox <gi...@apache.org>.
eladkal commented on code in PR #28651:
URL: https://github.com/apache/airflow/pull/28651#discussion_r1059677961
##########
docs/apache-airflow-providers-ftp/index.rst:
##########
@@ -35,6 +35,12 @@ Content
Operators <operators/index>
+.. toctree::
+ :hidden:
+ :caption: System tests
+
+ System Tests <_api/tests/system/providers/ftp/index>
+
Review Comment:
so something is odd with the automation as it should have not been removed?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] jedcunningham commented on a diff in pull request #28651: Prepare docs for Jan 2023 wave of Providers
Posted by GitBox <gi...@apache.org>.
jedcunningham commented on code in PR #28651:
URL: https://github.com/apache/airflow/pull/28651#discussion_r1059508724
##########
airflow/providers/common/sql/CHANGELOG.rst:
##########
@@ -24,6 +24,25 @@
Changelog
---------
+1.3.2
+.....
+
+Misc
Review Comment:
Maybe flip this order, bugs first then misc?
##########
airflow/providers/imap/CHANGELOG.rst:
##########
@@ -24,6 +24,16 @@
Changelog
---------
+3.1.1
+.....
+
+Misc
+~~~~
+ * ``[misc] Get rid of 'pass' statement in conditions (#27775)``
Review Comment:
Is it worth a release just for this change?
##########
airflow/providers/cncf/kubernetes/CHANGELOG.rst:
##########
@@ -24,6 +24,37 @@
Changelog
---------
+5.1.0
+.....
+
+Breaking changes
+~~~~~~~~~~~~~~~~
+
+
Review Comment:
```suggestion
```
##########
airflow/providers/google/CHANGELOG.rst:
##########
@@ -23,6 +23,44 @@
Changelog
---------
+8.7.0
+.....
+
+Breaking changes
+~~~~~~~~~~~~~~~~
+
+
Review Comment:
```suggestion
```
##########
airflow/providers/sftp/CHANGELOG.rst:
##########
@@ -24,6 +24,18 @@
Changelog
---------
+4.2.1
+.....
+
+Misc
+~~~~
+
+* ``Update codespell and fix typos (#28568)``
+* ``[misc] Get rid of 'pass' statement in conditions (#27775)``
Review Comment:
We don't typically add typo commits to release notes, and not sure it's worth releasing this set of changes.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] potiuk commented on a diff in pull request #28651: Prepare docs for Jan 2023 wave of Providers
Posted by GitBox <gi...@apache.org>.
potiuk commented on code in PR #28651:
URL: https://github.com/apache/airflow/pull/28651#discussion_r1059553691
##########
airflow/providers/imap/CHANGELOG.rst:
##########
@@ -24,6 +24,16 @@
Changelog
---------
+3.1.1
+.....
+
+Misc
+~~~~
+ * ``[misc] Get rid of 'pass' statement in conditions (#27775)``
Review Comment:
I personally would not remove it feom the release.
I usually released all of the "actual" changes. If the release did not make any code modifications it could be marked as "doc only change" - which means that documentation would be updated but the package itself was not released.
With such "small" code changes, it's always on the fence and I think this is just a question of "do we want to mess arround with the same change next time when we release" or "should we release now and forget about it".
But from the release manager point of view - I prefer to release any "potentially breaking changes" as soon as they are merged. Even if they are just "pass" statement removals. Because even smallest code changes might contain completely non-obvious bugs.
The mantra "release early, release often" is very much applicable here. What if you keep on doing it (not releasing this change), then not releasing next similar "innocent" refactor next month for the same provider, and so on. And then releasing 5 such changes in 5 months when there is a bigger change and finding out that one of those "innocent" changes broke something. But in 5 months you not only have to spend time finding out which one broke it but also the person who made the change will completely forgot on why and how or might be not available any more.
By releasing now (and adding the "Status" Issue - you add an extra "peer" pressure on the user who implemented it. It is fresh. The user still remembers it. And more often than not they will actually install the new provider RC and do some testing with it. And even if not, if someone else finds a bug in the newly released provider, you know immediately whom to ask for help. Do you think it will happen if you release 5 similar changes are released together in 5 months? I think it's far, far, far less likely.
I think not relasing now is optimizing the wront thing. By not realising we seem to optimize "number of releases in PyPI". Which is wrong optimization goal IMHO. There is virtually no overhead for maintainers nor for users to release it - because releases are all automated, and MOST users will just get the bundle together with new version of Airflow. And those users who actually care and install new providers when they are relased will actually appreciate if there are many smaller upgrades rather than than one bigger upgrade because it is easier to go back and investigating problem when it happens.
Release (and upgrade) early and often - as counter-intuitive as it is., it gives much better results than release less often.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] potiuk commented on a diff in pull request #28651: Prepare docs for Jan 2023 wave of Providers
Posted by GitBox <gi...@apache.org>.
potiuk commented on code in PR #28651:
URL: https://github.com/apache/airflow/pull/28651#discussion_r1059671922
##########
docs/apache-airflow-providers-ftp/index.rst:
##########
@@ -35,6 +35,12 @@ Content
Operators <operators/index>
+.. toctree::
+ :hidden:
+ :caption: System tests
+
+ System Tests <_api/tests/system/providers/ftp/index>
+
Review Comment:
Found it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] jedcunningham commented on a diff in pull request #28651: Prepare docs for Jan 2023 wave of Providers
Posted by GitBox <gi...@apache.org>.
jedcunningham commented on code in PR #28651:
URL: https://github.com/apache/airflow/pull/28651#discussion_r1059518211
##########
airflow/providers/imap/CHANGELOG.rst:
##########
@@ -24,6 +24,16 @@
Changelog
---------
+3.1.1
+.....
+
+Misc
+~~~~
+ * ``[misc] Get rid of 'pass' statement in conditions (#27775)``
Review Comment:
I'm not sure it matters, I think it'd make more sense to have "meaningful" releases of any given provider.
I think it is ultimately up to the release manager though.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] eladkal commented on a diff in pull request #28651: Prepare docs for Jan 2023 wave of Providers
Posted by GitBox <gi...@apache.org>.
eladkal commented on code in PR #28651:
URL: https://github.com/apache/airflow/pull/28651#discussion_r1059654006
##########
docs/apache-airflow-providers-ftp/index.rst:
##########
@@ -35,6 +35,12 @@ Content
Operators <operators/index>
+.. toctree::
+ :hidden:
+ :caption: System tests
+
+ System Tests <_api/tests/system/providers/ftp/index>
+
Review Comment:
I'm not sure why the static tests fails on
```
Checking docs/apache-airflow-providers-ftp/index.rst
The docs/apache-airflow-providers-ftp/index.rst does not contain System Tests TOC.
Make sure to add those lines to docs/apache-airflow-providers-ftp/index.rst:
.. toctree::
:hidden:
:caption: System tests
System Tests <_api/tests/system/providers/ftp/index>
```
In this PR. I would expect this to present failure on the PR that added the system tests for the provider https://github.com/apache/airflow/pull/26974?
@potiuk is this expected?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org