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.
Related
I had 2 repos on Github: "RepoName" and "RepoName_old". I thought I was going to rebuild my project but changed my mind and have been improving "RepoName_old" ever since. I deleted "RepoName".
If I rename "RepoName_old" to "RepoName" (the deleted repository), will something go horribly wrong? The official documentation warns against trying to pull from a branch associated with the old name...I guess that's a different thing...will GitHub Desktop acknowledge the new name after I make the change?
I have terrible experience mismanaging my git repositories and I want to avoid another setback by being informed and careful.
GitHub Desktop is a local tool which should reflect the changes done on GitHub.
On GitHub side, if you have deleted RemoName, you should be able to rename "RepoName_old" to RepoName.
Check first that it works on github.com.
Then try and clone it in command line, and, with GitHub Desktop, add it from your local folder. That should force GitHub Desktop to recognize RepoName with its new origin URL.
UEFITool on Github has 3 branches (master, new engine & legacy). Am I correct to assume the released version is only based on the master branch? Would I have to compile the new engine version myself? Anyone here willing to help do that? I can't even figure out how to download the Qt5 library.
https://github.com/LongSoft/UEFITool
Thanks!
Main author here: there are 2 branches that get release versions, from master you get UEFITool 0.xx.yy and UEFIPatch (because master is the only branch that can actually edit images), and from new_engine you get UEFITool NE Axx and UEFIExtract (new_engine branch have a lot of new parsers and overall much better internal design, but lacks editing support).
As for compiling new versions yourself: it's up to you, sometimes you want the absolute latest state of the both branches, so build it yourself using the same commands CI does, or use releases tab to get latest release from.
I also think such questions should belong to the project's issue tracker.
I created an Angular project using angular-cli and pushed it to GitHub. I then created a new branch and updated packages, installed standard-version and ran npm run release -- --first-release as instructed. I then pushed the whole into a new branch on GitHub, created a pull request, squashed and merged onto master, pulled back into local master, and ran standard-version again finally followed by git push --follow-tags origin master. Here's the state on GitHub:
All notes that I wrote in the pull request body are not visible in the changelog file, and they are obviously not in the chore(release) generated by standard-version. Why?
They are also not written within the Releases tabs at all, even though I can see the released tags there.
Should I have made the version 1.0.0 in packages.json before starting in order to adhere to semantic versioning?
What am I doing wrong?
You're not doing anything wrong. chore doesn't show up in CHANGELOG.md (see: https://github.com/conventional-changelog/standard-version/issues/135)
To have release notes uploaded, you will to use something like https://github.com/conventional-changelog/conventional-github-releaser
It's up to you where to start. Generally, when labeled 0.x, the project is still unstable and will go through vast API changes. When the project becomes stable, bump the major to 1.x and adhere to semver.
I have my own PHP/Composer repo on GitHub and have it published on packagist.org. Everything is fine so far. The Webservice is correctly configured and several versions have already been published.
But now I have the problem that when I try to publish a new version, it does not "end up" on packagist. Interestingly, packagist shows me (among older versions/tags) a version/tag "dev-master". After I pushed my latest changes to GitHub, created a tag/release on GitHub, and used "update" on the Packagist interface, this "dev-master" points to the latest commit on GitHub, but the new tag does not show up. Hence, when using ./composer update in a project, nothing is updated at all.
Here is step-by-step what I do:
Update and test my code.
push it to the master branch of the repo at GitHub (master is the only branch here a.t.m.)
update composer.json's "version" attribute to reflect the tag I am going to use for the next release
create a new tag via the "draft new release" function in github (e.g. "5.6.7")
go to packagist and click "update" in the repo.
Funny thing is, sometimes it works, sometimes not.
PS: Seems NOT to be an issue of delay. WHEN it worked, the new version was visible and installable within seconds. Otherwise, also waiting for several hours didnt fix the problem. Also, the hash of the latest commit from github is visible for "dev-master" immediately after I use "update" in Packagist.
Can anyone please tell be what I am doing wrong here?
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.