Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix label warnings #2417

Open
wants to merge 2 commits into
base: devel
Choose a base branch
from
Open

fix label warnings #2417

wants to merge 2 commits into from

Conversation

samccann
Copy link
Contributor

Fixes #2358

@samccann samccann requested a review from a team as a code owner February 14, 2025 17:40
@ansible-documentation-bot ansible-documentation-bot bot added the sc_approval This PR requires approval from the Ansible Community Steering Committee label Feb 14, 2025
@samccann samccann requested a review from oraNod February 14, 2025 17:41
@gundalow
Copy link
Contributor

Why didn't #2358 fail CI?
We don't have to fix that in this PR, though it would be good to understand so we don't have similar errors in the future

@oraNod
Copy link
Contributor

oraNod commented Feb 14, 2025

Why didn't #2358 fail CI? We don't have to fix that in this PR, though it would be good to understand so we don't have similar errors in the future

As @felixfontein mentioned CI builds core docs only. Building package docs as part of CI would take a ton of resources and slow down PR checks considerably. It usually takes >30mins for that job to run.

Edit to say that I guess some of the files included in this PR are part of core docs. Anywhoo, there are loads of warnings in the build that would be nice to fix so we can switch on strict mode and fail on warning. That will be fun. I think there's an issue around here for that somewhere. And this is a good step in that direction.

Copy link
Contributor

@oraNod oraNod left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @samccann

@samccann
Copy link
Contributor Author

perhaps we need make ansible-rst option that builds just the rst files for the Ansible package. Then we can add a CI test for that and shouldn't take long (though would repeat 90% of the files that are in the core test).

* MUST NOT query information using special ``state`` option values like ``get``, ``list``, ``query``, or ``info`` -
create new ``_info`` or ``_facts`` modules instead (for more information, refer to the :ref:`Developing modules guidelines <creating-an-info-or-a-facts-module>`).
* ``check_mode`` MUST be supported by all ``*_info`` and ``*_facts`` modules (for more information, refer to the :ref:`Development conventions <#following-ansible-conventions>`).
create new ``_info`` or ``_facts`` modules instead (for more information, refer to the :ref:`Developing modules guidelines <creating_info_factse>`).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
create new ``_info`` or ``_facts`` modules instead (for more information, refer to the :ref:`Developing modules guidelines <creating_info_factse>`).
create new ``_info`` or ``_facts`` modules instead (for more information, refer to the :ref:`Developing modules guidelines <creating_info_facts>`).

Comment on lines +229 to 230
Documentation requirements
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be

Suggested change
Documentation requirements
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Documentation requirements
~~~~~~~~~~~~~~~~~~~~~~~~~~

instead?

@@ -1,3 +1,5 @@
.. _ansible_and_python_3:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this label should point to docs/docsite/rst/dev_guide/developing_python_3.rst (which already has the label developing_python_3) and not to this document.

@@ -326,7 +326,7 @@ Module naming
* Modules that only gather and return information MUST be named ``<something>_info``.
* Modules that gather and return ``ansible_facts`` MUST be named ``<something>_facts`` and MUST NOT return anything but facts.

For more information, refer to the :ref:`Developing modules guidelines <creating-an-info-or-a-facts-module>`.
For more information, refer to the :ref:`Developing modules guidelines <_creating_info_facts>`.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
For more information, refer to the :ref:`Developing modules guidelines <_creating_info_facts>`.
For more information, refer to the :ref:`Developing modules guidelines <creating_info_facts>`.

@gundalow
Copy link
Contributor

Edit to say that I guess some of the files included in this PR are part of core docs. Anywhoo, there are loads of warnings in the build that would be nice to fix so we can switch on strict mode and fail on warning. That will be fun. I think there's an issue around here for that somewhere. And this is a good step in that direction.

We could look at a scheduled daily build for this. Let's late that discussion to the other issue (or start a Forum post)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sc_approval This PR requires approval from the Ansible Community Steering Committee
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Fix label warnings that affect builds
4 participants