There is a Github release (with a tag v1.0) for a public repo associating with two assets (Auto-generated by Github) viz., sourcecode.zip and soucecode.tar.gz.
If release is deleted, then does this delete action also remove two assets from the repo?
I had a release (with tag v1.0) published in github with two assets Source Code(zip) and Source Code(tar.gz) which were auto-generated by Github.
I did some changes to README.md file and wanted to include the latest README.md into the existing release rather than creating a new one such as v1.1.
So I logged into github and deleted the release and it disappeared.
I freshly created a new release with same tag v1.0 and as usual the two assets Source Code(zip) and Source Code(tar.gz) appeared again.
I downloaded the zip file to my desktop and inspected the contents. To my surprise the README.md file among the zip files was older one and not the latest. I thought that I had made some mistake.
So I repeated the process. Every time I downloaded the zip and found out only the older README.md again and again.
I realized that my delete action on the release had removed it from github but not the two assets. This means the assets should have been associated with tag v1.0 rather than with release.
To confirm my findings, I issued the command git push --delete origin v1.0 from my desktop.
I visited github and again created the release with tag v1.0. I inspected zip file after downloading.
At last, I found out that the latest README.md was sitting among the ziped files! That was what I wanted!!
The lesson learnt was that git command issued from desktop not only removed the release but also the tag associated with release.
Thus, the removal of tag v1.0 also removed the two assets associated with it.
In fact, I wanted to share this experience and so this post.
Related
It my GitHub Pages page for my project, the only download options are for the .zip and the .tar.gz files (the standard ones including "See this on GitHub"). I want to have a link to download another file (a .exe file) without having to put it in my GitHub repository. How can I do this?
I'm not sure how GitHub Pages relates here (this likely depends on the theme you're using), but one good option for sharing pre-built versions of your software is to create a GitHub Release. This will prompt you to create a tag for the version of your source code you wish to release and let you upload additional files:
Optionally, to include binary files such as compiled programs in your release, drag and drop or select files manually in the binaries box.
This file won't be added to your Git repository. It's attached to the GitHub-specific Release, and it can then be downloaded from your repository's releases tab, just like source archives.
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.
I need to host the documentation of multiple versions of my project (say 1.0, 2.0 and 3.0) and all are active (documentation)branches and we shall keep on adding improvements to all of these.
Is it possible to use GitHub pages for this purpose?
Appreciate any help on this.
This is feasible using Github Actions along with a static site generator (SSG) of your choice such as VuePress, Gatsby, Jekyll etc.
In its simplest form, create a GH action to generate the static site folder of the branch/release, then push the folder to corresponding folder in the branch pointed to by GH pages, say gh-pages. One of the branches/releases should be pushed to root. GitHub Pages Deploy Action can be helpful. Lastly add a dropdown list of versions to your static website pointing to the matching folder. The list of items can be statically maintained or dynamically populated using GitHub API. The selected item depends on the current URL path.
Example:
To provide multi-version docs for software product NotifyBC,
input - docs folder of the product created by VuePress
output - gh-pages branch
GitHub action, with main branch pushed to root of gh-pages branch and releases pushed to version folder
dynamically populated dropdown list implemented in Vue component
rendered site powered by GH pages
You can have a look at gh-pages-multi.
It is a small nodejs tool I wrote to push different versions of docs to subdirectories in a gh-pages branch. It also generates a index.html file listing those subdirectories.
It is fairly easy to integrate in a CI workflow if you want to automate building and pushing the docs.
Also note the "--no-history" option that will prevent bloating the git repo if your docs contain some built files or binary assets.
These other answers over-complicate things. As #jhpratt suggests in the comment, you can just copy the code corresponding to a version of your site you want to deploy to a dir (labelled e.g. v1.0) within the dir that you deploy to gh-pages. You then access the version with https://your-name.github.io/your-repo/v1.0/.
Of course, depending on the type of site you're building you may have to worry about the content of <base href="..."> tag, etc., for each version, but you need to worry about this tag in any case since github pages do not deploy to the url root.
I am working inside a private repository, and collaborate with my friend, who are not very friendly with SCM and stuff. All he need is to monitor the latest release from my development, which is 1 single executable file.
I was wondering instead of cloning the whole repo each time he want to get the latest changes (sometimes my changeset can consists of several large binary files that only being used upon development, not testing). Can I bind the executable file into the Download section in BitBucket?. So that everytime I build my project, the executable file will appear in the Download section and he can download it right away.
For now all I can see from Bitbucket's download section is just the manual upload and Tag/Snapshot download, which I presume will pack a certain changesets into a compressed file. Is there any chance I can do this?.
Thanks.
If your executable file is checked into the repository, you can link to it at a specific revision:
https://staging.bitbucket.org/<username>/<repo>/raw/<revision>/file.exe
For example, this link will always give you the latest stable hg(1) man page from the Mercurial repository:
https://bitbucket.org/mirror/mercurial/raw/stable/doc/hg.1.txt
This would give you latest README on the default branch from the Django repository:
https://bitbucket.org/django/django/raw/default/README
If your executable isn't checked into the repository (some prefer not to check in build artifacts), you'll need to manually upload them in the downloads section of your repository. There isn't a REST API for creating project downloads at the moment.
Would giving your friend an archive of the tip work? Try this URL:
https://bitbucket.org/<username>/<project>/get/tip.tar.gz
#Idan's suggestion might already work for you, but if the archive is too big, you could set up an extra repository for binaries which automatically gets updated, committed and pushed by your build process. Then your fellow developer could download a comparatively small tip archive as suggested by Idan.
In addition to Idan's answer:
To fetch the latest version from the 'default' branch:
https://bitbucket.org/<username>/<project>/get/default.tar.gz
You can replace 'default' by any other branch name, tag name or changeset (if you know it).
How do you include a link to a compiled binary on Github?
You can link to a specific file in a GitHub repo using the URL http://github.com/<username>/<project>/blob/<branch>/<path/to/file>. So if you track your compiled binary, you can link to it that way.
Otherwise, you can upload the compiled binary to your project's download page, and distribute that URL.
Since 2d July 2013, you now can define a release.
Releases, a workflow for shipping software to end users.
Releases are first-class objects with changelogs and binary assets that present a full project history beyond Git artifacts. They're accessible from a repository's homepage:
Releases are accompanied by release notes and links to download the software or source code.
Following the conventions of many Git projects, releases are tied to Git tags. You can use an existing tag, or let releases create the tag when it's published.
You can also attach binary assets (such as compiled executables, minified scripts, documentation) to a release. Once published, the release details and assets are available to anyone that can view the repository.
That is what replaces the old binary upload service, which was removed in December 2012!