Liam AllenandClaude Sonnet 5
2d9e92e4cf
* Fix awx-operator molecule test timeout being too tight The inline `timeout 20m` wrapping the molecule test run in the "Run test deployment with awx-operator" step (separate from the never-binding outer `timeout-minutes: 60`) isn't currently causing failures on this repo's runners (recent successful devel runs take 9.4-10.8m), but it's the same line that downstream (ansible/tower) had to bump to `timeout 54m` after its runs started legitimately taking 15-19.5m and getting killed with as little as ~30s of margin under 20m. Since downstream syncs this workflow from here, leaving it at 20m risks a future sync silently reverting the downstream fix. Raise it to 54m to match, well ahead of any regression in this repo's own runtime. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Liam Allen <lallen@redhat.com> * Raise awx-operator job-level timeout to fit the 54m inner timeout Job-level timeout-minutes covers the whole job cumulatively (checkout, image build, the deployment step, log collection, artifact upload), not just the deployment step. With the inner `timeout 54m` from the previous commit, a worst-case run (setup of ~6-8m plus the full 54m before the inner timeout fires) totals ~60-62m, which can trip the job-level 60m limit first and hard-cancel the job before "Collect awx-operator logs on failure" or the timed_out=true write ever execute - losing exactly the debug output this timeout-marker pattern exists to preserve. Raise job-level timeout-minutes to 75 to give headroom past the worst-case inner timeout. No change to the timed_out=true or conditional log-collection logic. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Liam Allen <lallen@redhat.com> --------- Signed-off-by: Liam Allen <lallen@redhat.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
Caution
The last release of this repository was released on Jul 2, 2024. Releases of this project are now paused during a large scale refactoring. For more information, follow the Forum and - more specifically - see the various communications on the matter:
AWX provides a web-based user interface, REST API, and task engine built on top of Ansible. It is one of the upstream projects for Red Hat Ansible Automation Platform.
To install AWX, please view the Install guide.
To learn more about using AWX, view the AWX docs site.
The AWX Project Frequently Asked Questions can be found here.
The AWX logos and branding assets are covered by our trademark guidelines.
Contributing
- Refer to the Contributing guide to get started developing, testing, and building AWX.
- All code submissions are made through pull requests against the
develbranch. - All contributors must use
git commit --signofffor any commit to be merged and agree that usage of--signoffconstitutes agreement with the terms of DCO 1.1 - Take care to make sure no merge commits are in the submission, and use
git rebasevs.git mergefor this reason. - If submitting a large code change, it's a good idea to join discuss via the Ansible Forum. This helps everyone know what's going on, and it also helps save time and effort if the community decides some changes are needed.
Reporting Issues
If you're experiencing a problem that you feel is a bug in AWX or have ideas for improving AWX, we encourage you to open an issue and share your feedback. But before opening a new issue, we ask that you please take a look at our Issues guide.
Code of Conduct
We require all of our community members and contributors to adhere to the Ansible code of conduct. If you have questions or need assistance, please reach out to our community team at codeofconduct@ansible.com
Get Involved
We welcome your feedback and ideas via the Ansible Forum.
For a full list of all the ways to talk with the Ansible Community, see the AWX Communication guide.