In a github repository I own most of the dependencies are rendered as links - but some of them, including one of my own Github repository dependencies (aor-component-factory), don't.
Is it because they are not that popular and they weren't indexed yet or there is some configuration/code that needs to be added to those repositories? Thanks!
One possible reason is for repo renamed (the OP confirms it wasn't).
Another reason is the path used to reference dependencies in the package.json
zifnab87/ra-component-factory
vs.
ra-component-factory
The former should work better.
Following this tweet, try and apply to your repo the jgamblin/GithubDependencyCheck tools to see if that particular dependency in gray is reported any differently.
From the OP Michail Michailidis's comment, it seems that was a GitHub bug that was since fixed (Dec. 2017).
Related
I have an open-source repo on GitHub called Gamgee. (It's a dinky little music queue bot built on Node.js, in case you're curious.) It's been around for not much more than a week and doesn't export anything useful as a package, yet GitHub already reports that this repo is "used by" another repository of the same name.
The referenced package is very small and doesn't seem to list any dependencies at its root package.json other than TypeScript. Is this a GitHub bug, or am I missing something here? If this is a GitHub bug, where might I report those?
Because we've done some rearranging of our documentation setup, I have two separate read the docs projects which I need to build from the same GitHub repo. One of them is brand new, and the other used to be pointed to the old repo.
I have set up a webhook on each project, and added both these webhooks to the repo.
The problem is that in the project that used to be pointed to the old repo, the stable build is still associated with the SHA of the latest release on the old repo, which does not exist in the new repo. This causes the stable build to fail.
One other thing I hope to solve, when activating some of the new versions (which used to exist in the old repo) an "_a" is added to then of the published version name, even though there are not multiple publishable versions with the same name.
I'm wondering: is it possible to completely refresh all of the RTD-detected versions and tags? I think doing so would solve both these issues.
I've tried "wiping" the builds but that doesn't help, I have read the RTD docs on versions many times, and I've triggered new push events from github (which are sent and received successfully) but still can't make any progress.
The best way to solve this turned out to be just recreating the RTD projects. If anyone else comes across this issue, you could check out the ticket I made on the RTD repo https://github.com/rtfd/readthedocs.org/issues/3763.
Trigger a Build on any of the existing versions that RTD knows about. After that build job starts the Versions list will be updated from the git repo.
Following page page points to Github's page where pre-build binaries are contained. If I have not found first mentioned page first then I would have not an idea that such page (with pre-build binaries) exists on Github. Is it usual to put some pre-build binaries under releases on GitHub (I've seen it also other times e.g. with gns3)? Is there any link on project's Github page which will point me to releases (maybe I can add releases to corresponding URL but I guess there must be some link which points to it)
The "release" pages is available on any GitHub project. You can access it quickly using the link on top of project (between branches and contributors):
GitHub release page is computed from Git repository tags. The maintainer of the project is free to use it or not, but it's a common practice to transform a git tag into a release, attaching a description (changelog, release note, etc) and/or some files (pre-build packages, setups, DMGs, etc.)
GitHub team wrote a blog post a few years ago to explain this feature.
Does anyone know how to figure out which commit in git corresponds to which Nuget version for Protobuf-net?
I use the Nuget version (2.0.0.668), but I have an error in my graph, and there is no good debug information without the source, so I would like to get a hint as to where the problem lies in my code.
The nuget package versions do not seem to be tagged in the repo I am using-
https://github.com/mgravell/protobuf-net.git
Any ideas?
Not sure this is really a stackoverflow question, but: I've added some tags to the git repo; however, the only interesting ones at the moment are r668 (aka 2.0.0.668) and v2.1.0-alpha-1 (the alpha core-clr release). I did not attempt to go back through all releases.
I'm editing one of my open-source projects on GitHub and I want to replace link (pointing to a demo) in README.md.
Do I have to update library version every time I introduce some minor changes to the README file or documentation (without any actual code changes)?
What is the community accepted practice?
If it's important, I'm using Bower to distribute my package and SemVer as a versioning system.
The README file is part of your codebase. It should describe the current (= in current commit) state of the code. A developer might read it outside GitHub's environment, e.g. from the node_modules directory on their hard drive, expecting it is up to date.
Therefore I would recommend to release a new version when the README changes.
It will usually result in just a patch number increase. But remember that when marking something as deprecated one must release a new minor version (paragraph 7 in SemVer v2.0.0).
If you plan to do really a lot of changes there are two ways to avoid releasing too often:
Make changes in a branch. Merge to master here and there, release a new patch version.
Move the documentation (or a part of it) somewhere else. GitHub Wiki or a simple webpage, e.g. using GitHub Pages, could come in handy.
You could include, as library version, the content of of git describe --all --long, as described in How can I get the Git build number and embed it in a file? (using git describe).
That way, you get the latest tag, plus the number of (small) commits you did since that tag.
That means:
you don't have to put a new tag if you don't want to
but you still keep an exact reference the the version of your repo which was used for delivering your app.