I'm using AnyBadge
https://github.com/jongracecox/anybadge with GitHub Action.
But I cannot find a way to show the badge on README and cannot find any doc written in this repo.
I tried to save it in Artifacts. However, it's a zip file and without url, so I don't know how to show it on README.
Does anyone know how to display it on README?
Any doc regarding the use with ESLint?
Thanks!
Note: Our repo is private(organiztion)
https://github.com/anuraghazra/github-readme-stats
you can check this and just you have to copy some commands in your readme.MD file which is basically a special type of repository we use to show only introduction and details like these.
For Readme. MD
https://docs.github.com/en/github/setting-up-and-managing-your-github-profile/customizing-your-profile/managing-your-profile-readme
https://github.com/aleen42/badges
I have been trying to publish a Sphinx generated documentation for our repository on Github pages with the theme provided by readthedocs.org.
After a few attempts I managed to get it online by uploading the Sphinx generated HTML files in the gh-pages branch of the repository.
Obtaining this:
https://takeqontrol.github.io/qontrol_api/
Which is looking awful, erasing all the customization of the theme by Read the Docs.
Here is an example of what you see if you open the link:
But if I open those HTML files on my computer the pages looks exactly how I wanted them to look.
Here is an example of how exactly the same HTML looks locally:
Does anybody know what is going on? Or even point me somewhere where I can find an explanation?
All the code is available here: https://github.com/takeqontrol/qontrol_api
in the two branches.
I fought with this for 9 hours before figuring out that the underscore in the _static folder was causing the issue.
You need to by pass Jekyll on github pages.
To do this, add an empty .nojekyll to your gh-pages branch. (See example)
I was having a similar issue and then found this, which solved it for me:
Python Sphinx css not working on github pages
Looks like using underscores for the _sources + _static folder caused the issues. Need to rename the folders and paths using them in the html files accordingly.
I've been trying to figure this out by observing various README files on public repositories.
If seen stuff like encapsulating a function with ```cs on top and ``` on bottom.
Then in some places I've seen bash or diff instead of cs.
But I haven't been able to apply any of these options in my own README file and get them to produce the same colors.
Does it possibly have anything to do with the .gitattributes file?
When you have a JavaScript snippet you can highlight the content via:
```javascript
content
```
(Read more here: https://help.github.com/en/articles/creating-and-highlighting-code-blocks)
The .gitattributes file is not needed for the README.md. It is needed when GitHub (Linguist) highlights a whole file in a wrong syntax
Last but not least, syntax highlighting in GitHub is made possible by the GitHub project linguist.
I have a GitHub repository with a readme.md. How can I add a link in the readme.md to the new issue page on GitHub?
I could add in the readme.md:
[submit a new issue](https://github.com/[username]/[repo_name]/issues/new)
but I wonder whether I could instead have a relative link.
You can't -- at least, not reliably.
There are multiple URLs that your README.md will be visible at. It's primarily visible at the root of your repository, but it can also be viewed directly as a file (e.g, …/blob/master/README.md). If a user has forked the repository, it will also be visible in a set of analogous URLs in their fork.
Using a relative link will mean that only the first link works as intended -- the rest will be broken. Use an absolute link.
From the doc:
A relative link is a link that is relative to the current file. For example, if you have a README file in root of your repository, and you have another file in docs/CONTRIBUTING.md, the relative link to CONTRIBUTING.md in your README might look like this:
[Contribution guidelines for this project](docs/CONTRIBUTING.md)
Does the wiki that installs with a GitHub repo support directories? Our wiki is cluttered with pages, and we are looking for a way to organize them better.
We tried pulling the repo, creating local directories, and moving things around, but when committed back, the wiki didn't pick up the changes.
I was having the exact same issue and tried variants of what you tried. Nothing stuck. Asked GitHub support about it and received a reply that essentially said "No, but we'll let the developers know that people are interested in this feature."
So the short answer is "No", and the long answer is "No, but maybe in the future."
Actually, it looks like github added support for directories recently.
I was able to do the following:
Move an existing markdown file to a new directory.
Create a new markdown file in an existing directory (created in the former step).
Create a new markdown file in a new directory.
In all cases, the existing pages were still there and new pages were added.
The one constraint that remains is that your file names must be unique. If you have more than one file with the same name, only one of them will show up in the wiki (I'm not sure which.. ).
The GitHub wiki (aka Gollum) does use directories but not in the way you may expect.
The documentation on the Gollum wiki could use some work but this is what I have figured out mostly via testing.
All files appear in the root of the wiki no matter where they are placed in the repo.
_Header, _Footer and _Sidebar files are per-directory, but inherited if there is
none present in a child folder.
File links can be relative to the source file (keep your files with your content).
So, if you want directories for namespacing you are out of luck. Consider using the {namespace}-{page} scheme for namespacing.
It's not the an ideal solution but the workaround would be to create a custom sidebar where you create a table of contents with links to your pages. I find this to be better than folders anyway because it allows you to have a link to a single page under multiple hierarchies.
Actually, there is still a limitation. Yes, you can add 1 level (so, 1 subfolder). But that's it! I refactored my whole documentation layout, creating multiple levels of subfolders for organisation, but that was a no-go.
sigh
I must say: I'm appalled by this Gollum thing. I'm surprised Github even picked it up.
Well, that's a disappointing missing feature!
What I try to do is to actually have directories under a docs directory and in each one, a README.md file.
Not great...but works for documentation and organizes stuff.
If you want to go further, you can have a different branch only with these files.
Still no intention of adding this 9/2022.
https://github.com/orgs/community/discussions/23914