Readthedocs does not display the version of my github package.
It states latest, while I specified the version to be 0.1.1 in my conf.py file:
version = "0.1.1"
release = version
The thing is that when I compile locally through make html, I see the version properly displayed. When I push to remote, it does not display the version.
Make sure you have the readthedocs webhook added to your GitHub repository and set to active. You can also check it on readthedocs website in your project dashboard under Admin>Integrations.
That way whenever you make a change to your repository, readthedocs webhook would trigger a new build for your documentation and keep it up to date.
Related
I am working with GitHub Actions to build code on Windows, Linux, and MacOS. I use actions/commit#v3 #actions/checkout#v3 to download my repo to each server. However, I do not know where the repo gets downloaded. I have to curl other files and add them to the repo folder for the build to work.
Does anyone know where repos are downloaded on each server (Windows, Linux, and MacOS) with actions/commit#v3 #actions/checkout#v3? I'm having trouble finding anything in the documentation. If the path is set in an environment variable, I would prefer to use that instead of hard coding the path for each server.
The environment variable you're looking for is GITHUB_WORKSPACE.
The default working directory on the runner for steps, and the default location of your repository when using the checkout action. For example, /home/runner/work/my-repo-name/my-repo-name.
Source: https://docs.github.com/en/actions/learn-github-actions/environment-variables#default-environment-variables
I'm moving the Mercurial repositories for all my open-source projects to OSDN (OSDN.net) from Bitbucket because Bitbucket will soon drop support for Mercurial. However, OSDN only supports SSH, not HTTPS, as a file exchange protocol, and ReadTheDocs does not support SSH URLs. The ReadTheDocs public API allows builds to be triggered, but does not support any way to provide the source files with the build trigger.
Or any documented way, at least. Does anybody know of a way to either push document source files to RTD with a build trigger, or connect an OSDN repository to RTD so that RTD can clone the source files itself?
Thanks.
OSDN does support both SSH & HTTP(S), for "writing" the only option is ssh. However, read-the-docs needs only to 'read'; https is fine (And supported, although a bit hard to find).
On OSDN, toggle the "RO|r/w" button, to see the other-URL. It's not a button, nor trigger; but it looks like it --The UX/UI design isn't very great ...
Copy that RO value (again: ignore the UI-feedback. You can copy the https-URL. And past it on RTfD.
Note: for now, I could get webhooks/integration working. So, you have to go read-the-docs to rebuild, after a push. Or use the curl webhook from e.g a Makefile locally, see: https://docs.readthedocs.io/en/stable/webhooks.html#parameters
I have installed and configured a custom Laravel private repository hosted on bitbucket on minishift running on my laptop. I found that all the files were imported properly without any issues and the image is running.
However, now I want to make configuration changes in my repository for my application to work. How do I make it?
Will I have to import the image from VM on my laptop, work on them
and then push the changes back
Or will I be able to access the files or folder from within my editor or IDE?
I am new to Openshift origin and using it for the first time.
If you have your source code on Bitbucket, you would checkout the repository to your local laptop, make the changes, commit them, and push them back to the repository on Bitbucket. You would then tell OpenShift to rebuild the application by clicking on the Start Build button on the build configuration details in the web console, or by using oc start-build on the command line, supplying it the name of the build configuration to do the build for. The rebuilding of the image from the code when done will automatically trigger a new deployment. If you set up a webhook in Bitbucket, you can have it tell OpenShift when new changes have been pushed and that will trigger a build without you needing to do it manually.
If you are quite new, I would suggest you work through the interactive tutorials at:
https://learn.openshift.com
Also read the free eBook on OpenShift.
https://www.openshift.com/promotions/for-developers.html
I am writing draft blog posts using hexo. I am running the hexo server as follows:
hexo server --draft
This watches for changes in the draft folder and generates the draft posts which can be viewed at http://0.0.0.0:4000
The problem is I can't work out how to use live-reload while writing drafts.
With livereload I call
live-reload --port 9091 public/
And use use the javascript implementation with the browser
<script type="text/javascript" src="//localhost:9091"></script>
I can see why this doesn't work, live-reload is looking for changes to the public folder. With the server running in draft mode, I don't know what folder the html generated drafts are being stored in. I've searched my project structure and can't seem to see anything obvious. Any ideas?
Hexo can offer live-reload-like functionality via the'Browsersync-based' plugin, 'hexo-browsersync'.
There is actually also a hexo-livereload plugin, but the net, and hexo-browsersync's NPMJS rating, seem to favour the Browsersync Hexo plugin.
Christopher Martin's blog post 'Getting Started with the Hexo Blogging Framework', outlines the plugin's installation and usage, as well as many other helpful tips:
To install the hexo-browsersync plugin:
$ npm install hexo-browsersync --save
$ hexo server --draft --open #restart the server
This might possibly suit the OP's original question better than the accepted answer.
This is how I normally do this sort of thing:
hexo generate --draft --watch & live-server --port=4000 public
This generates the site in the public folder and watches for changes, whilst also serving said public folder with auto-updates.
Not exactly answering the specific question but maybe someone will find it useful.
Note: You will need to have live-server and hexo-cli installed globally, or locally if running via npm scripts.
hexo server serves the source version of the post not the public version. If you set livereload to watch the source folder livereload will work. I suggest setting livereload to use a 1 second or so delay before processing so the on the fly source generation to occur before reload is attempted.
Looking to the --draft option implementation at Github shows that it only extends the post processor to the _draft folder. So the place where it puts draft rendered files is the same it puts published posts.
However, hexo server does not save published posts in public directory as might be suggested by the question; public directory is populated by hexo generate command only. In fact hexo server does not save temporary files as it renders them on the fly.
I think live-reload will not work this way.
Need some help adding a blog for this client in Silver stripe CMS.
The client is http://arborwinsys.co.uk/
and the SilverStripe version is - 2.3.7
Would it work installing this module?
https://github.com/silverstripe/silverstripe-blog
The git master branch that you are looking at contains changes for SilverStripe 3. To make the blog work with your SilveStripe version you'll have to go back to the blog module 0.4 or 0.3 by switching the branches.
Steps to adding the blog module to silverstripe 2.3
Download the .zip from https://github.com/silverstripe/silverstripe-blog/tree/0.3
(later versions of the module require later versions of silverstripe)
Extract the contents of the .zip file (it may be within one directory in the .zip file) to a new folder called "blog" in your silverstripe install (it should be at the root level - that is, it should be in the same folder as your "mysite", "cms" and "sapphire" folders
Run a /dev/build on your silverstripe install
Run a ?flush=all on your silverstripe site
if you have any issues:
Ensure you downloaded the correct file (later versions of the module will not work unless you update your silverstripe install)
ensure that you have extracted the files correctly:
e.g. if your website is www,mysite,com and you can access your admin from www,mysite,com/admin - you should have your files in www,mysite,com/blog
ensure you have done a rebuild on your site
try doing a flush
if all else fails, post the error you're receiving back on here.
Good luck!