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

Do not set 'display: block' on all <table>s #42

Merged
merged 1 commit into from
Dec 10, 2021

Conversation

felixfontein
Copy link
Collaborator

@felixfontein felixfontein commented Dec 8, 2021

Currently the theme's CSS sets display: block for all <table> elements. There are multiple reasons why not to do it (see for example https://stackoverflow.com/a/7456216), and doing that breaks other uses, like ansible-community/antsibull-build#354 (comment). So please let's remove that faulty line :)

(That line was originally added to the theme in ansible/ansible@373b1dc#diff-9a54ec88f2695401d17b8ea9a48d9970c13279b8c01dc902367d00c70c4e31e2R420 and has been carried around ever since then. I have no idea what the original intention was, but I don't think it ever did anything good.)

@felixfontein
Copy link
Collaborator Author

@webknjaz is there something wrong with CI here? Nothing seems to be running (except the readthedocs test).

@webknjaz
Copy link
Member

@webknjaz is there something wrong with CI here? Nothing seems to be running (except the readthedocs test).

Sort of. Funny that I had to explain exactly this a few times recently :)

Basically, when there's no activity for 60 days, GH disables the cron workflows triggered on the schedule event. It really affects the whole workflow definition file, not just one trigger. So push and pull_request triggers become collateral damage if in the same workflow. If a workflow is disabled, no events will "wake it up". This won't happen to the workflows that don't have schedule, though (unless they are manually disabled by a human).
As a result, new PRs don't cause the workflow to be triggered and you only see the required checks listed 🤷‍♂️. I've probably missed the GH email about disabling (they usually give a chance to click a button to skip turning it off).

For now, I've re-enabled the workflow. But in the future, it may be reasonable to think about really moving out the cron trigger. This doesn't affect active projects as much so people often don't realize that this mechanics exists.

@webknjaz webknjaz closed this Dec 10, 2021
@webknjaz webknjaz reopened this Dec 10, 2021
@webknjaz
Copy link
Member

Re-opened this PR to trigger CI.

@webknjaz webknjaz merged commit 28efe08 into ansible-community:master Dec 10, 2021
@webknjaz
Copy link
Member

webknjaz commented Dec 10, 2021

@felixfontein thanks, https://github.com/ansible-community/sphinx_ansible_theme/actions/runs/1563168971 should make the v0.9.0 release happen in a minute.

@felixfontein felixfontein deleted the fix-tables branch December 10, 2021 11:51
@felixfontein
Copy link
Collaborator Author

@webknjaz thanks a lot! Yeah, I'm somewhat familiar with the 60 days inactivity timeout, this regularly happens for some of my private repos :)

@felixfontein
Copy link
Collaborator Author

BTW, do the GitHub releases (https://github.com/ansible-community/sphinx_ansible_theme/releases) need to be created manually?

@webknjaz
Copy link
Member

Yep, I didn't integrate GH releases autocreation in this repo. Will probably do that some other time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants