I have a GitHub repo and would like to use GitHub Actions to create a release with a generated file included:
push a commit with a tag
the GitHub Action starts
it runs yarn run build (generates dist/index.js)
release is created that includes the dist folder
So far, I have not been able to do this. I've been able to use "marvinpinto/action-automatic-releases#latest" action to package the dist folder as an additional asset, but that's not it.
I want the Source code (tar.gz) in the GitHub release to contain the dist folder.
What I'm trying to do is use this generated asset as a yarn dependency, which works if I use the Source Code (tar.gz) but not if I use the additional generated asset.
The entries your images show that are labeled “Source code (tar.gz)” and “Source code (zip)” are autogenerated from the contents of the repository and contain only and exactly what's in the repository. They can't be modified in any way because they aren't persisted: they may be regenerated in the future. That's also why they may change (so, for example, the hash of the contents need not be stable).
If you want to include additional dependencies in your tarball, simply upload your own source release that contains the generated files. Many projects do this for various reasons, and you can do it, too.
Related
Using GitHub via a browser, I am failing to create the Releases assets source code zip and tar.gz files that contain my src/filename.php files.
Syncing to Packagist appears to work OK, but Composer then not unexpectedly fails to load my source files into the usual vendor/packagename/src/ subdirectory.
I have tried loading the source files themselves into the main part of the repository into subdirectory /src using Add file. I have also added a zipped and a tarballed version into Releases file upload.
GitHub documentation is somewhat light on this, so could someone kindly explain exactly what I am doing wrong.
My finger trouble somewhere...
I was indeed incrementing the tag version, but it seems as if the php code additions I did to the main branch (with file upload) had for some unfathomable reason be made AFTER the new tag (release). Packagist then synched to the new tagged version but this was obviously missing the code additions.
My remedy was simply to methodically update the code again, check the json for tag version, and then finally release with an incremented tag.
Incidentally, there was no error message - just a total absence of php modules in my myvendor/mypackagename/src !
I have details of few public repositories on GitHub. Is there a way to write a script which downloads the source code of all those repositories on to my local machine? While downloading the source code I want all the previous versions of project to be downloaded.
Ex: Project RxJava has about 124 releases as shown here. I want to know if there is a way to write a program which downloads source code of all these 124 releases on to my machine. I don't want to click on download source code button on each of these releases.
The easiest is to:
clone the repo (that will give you the sources matching each tags)
do a git tag and for each tag, curl the release.
Actually, since the release is the source code, you don't have to curl anything.
To access the source code of a "release", simply checkout the tag matching the release.
cd /path/to/cloned/repo
git checkout 1.0.8
This is how I figured the solution:
Using the Repository Search API get the details of required the projects.
This gives you a JSON object which has the below property
"releases_url": "https://api.github.com/repos/ReactiveX/RxJava/releases",
Use the above url to get a JSON object which describes release details of project
The JSON obtained in step 3 has a property as given below for each version of project
"zipball_url": "https://api.github.com/repos/ReactiveX/RxJava/zipball/v1.0.8",
Now copy the content from above URL in to an output stream to fetch the required source code.
Sample source code is available here
I know I am seven years late, yet I think this solution might help people with the same prolem:
I developed a simple bash script that you can find in this GitHub Gist that allows you to download all versions from every file currently in the repository. The output data is located in subfolders matching the name of the file, containing all its versions. The original directory tree of the repository is kept.
Hope anyone finds this useful!
We recently moved from subversion to git, and then to Github, for several open source projects. Github was nice in that it provided a lot of functionality. One of the things I particularly like is the ability to download tags as zip or .tar.gz files.
Unfortunately Github recently discontinued downloads. That shouldn't be a problem because of the ability to download tags. However in the past we have not put a Makefile , configure script or any other autoconf-generated files into the repo because they get lots of conflicts when people merge.
What's the proper way to handle this?
Should I put autoconf and automake-generated files in the repo so people can download tags directly?
Or should there be a bootstrap.sh file and people are told to run that?
Or should I just do a make dist and put that into the repo?
Thanks
Publish the output of make dist via GitHub Releases
Your first option—putting the Autoconf- and Automake-generated files into the repository—is not a good idea. It's almost never beneficial to store generated files in source control. In this case, it's going to pollute your history with a lot of unnecessary and potentially conflicting commits, particularly if not all your contributors are using the same version of Autotools. Your third option—checking in the output of make dist—is a bad idea for exactly the same reasons as the first option.
Your second option—adding a "bootstrap" script that calls Autoconf and Automake to generate the configure scripts—is also a bad idea. This defeats the entire purpose of Autotools, which is to make your source portable across systems—including those for which Autotools is not available! (Consider what would happen if someone wanted to build and install your software on a machine on which they don't have root access, and where the GNU Build System is not installed. A bootstrap script is not going to help them because they'd first need to make a local installation of Autotools and possibly all its dependencies.)
The proper way of releasing code that uses Autotools is to produce a tarball with make dist (or better yet, make distcheck, since this will also run tests and do other sanity checks), and then publish this tarball somewhere other than the source repository.
Your original question, from April 2013, states that GitHub discontinued download pages. However, in July 2013, GitHub added a "Releases" feature that not only pre-packages your source tags, but also allows you to attach arbitrary files to each release. So on GitHub, the Releases page is where you should publish your make dist tarballs (and preferably also the detached GnuPG signatures of them).
Basic steps
When you are ready to make a release, tag it and push the tag to GitHub:
$ git tag 1.0 # Also use -s if desired
$ git push --tags
Use your Makefile to produce a tarball:
$ make dist # Alternatively, 'make distcheck'
Visit the GitHub page for your project and follow the "releases" link:
You will be taken to the Releases page for your project. The first time you visit, all you will see is a list of tags and automatically produced tarballs from the source tree:
Press the "Draft a new release" button.
You will then be presented with a form in which you should fill in the Git tag associated with the release and an optional title and description. Below this there is also a file selector labelled "Attach binaries by dropping them here or selecting them". Use this to upload the tarball you created in Step 2 (and maybe also a detached GnuPG signature of it).
When you're done, press the "Publish release" button.
Your project's Releases page will now display the release, including prominent download links for the attached files:
If you don't want to use GitHub Releases, then as pointed out in a previous answer, you should upload the tarballs somewhere else, such as your own website or FTP site. Add a link to this repository from your project's README.md so that users can find it.
The second is better: you want any user of your repo to be up and running as fast as possible, re-generating what he/she needs in order to build your program.
Since Git is very much a version control for text (as opposed to an artifact repo like Nexus), providing a way to generate the final binary is the way to go.
When you cut a release, upload the result of make distcheck to your project's download page: it's a makefile target that builds the tarball and verifies that it installs, uninstalls, passes tests and other sanity checks. Github being wrong-headed isn't an excuse: create a tree like this in your repo:
/
/source
/source/configure.ac
/source/Makefile.am
/source/...
/releases
/releases/foo-0.1.tar.gz
/releases/...
For developers, you should not have generated files in source control. Many modern autotooled projects bootstrap fine off an invocation of autoreconf -i.
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).
I've got a project in a git repository that uses some custom (and so far unversioned) setup scripts for the build environment etc. I'd like to put these under version control (hopefully git) but keep them versioned separate from the project itself, while still living in the base directory of the project - I've considered options like local branches but these seem to have the problem that switch back to master (or any other "real" branch) will throw away the working copies of the setup scripts.
I'm on Windows using msysgit so I've got a few tools to play with; does anyone have a recommendation or solution?
If you really need them separate from your main git repo while still living directly within it, you could try:
creating a new repo with those script within it
and:
adding that new repo as a submodule to your repo. Except:
a/ those scripts won't live directly in the base directory, but in a subfolder representing the submodule
b/ you need of course to not publish (push) that new repo, in order for other cloning your main repo to not get those setup files
or:
merging that new repo into your main repo (with the subtree project), but:
you need to split back your project to get rid of those files
for a project with a large history, and with frequent push, that step (the split) can be long and cumbersome.
I would consider a simpler solution, involving some evolution to your current setup files:
a private repo (as in "not pushed") with those setup files
environment variables with the path of your main git repo in order for your setup files (which would not be directly within the base directory of said main repo) to do their job in the right directory (like beginning for instance with a 'cd right_main_git_repo_dir').
I want to share an additional solution and some samples from which to start.
I've has a similar problem in attempting to build Mozilla Firefox with Buildbot -- I need to have some files in the root folder (namely the .mozconfig file and some helper scripts) and I wanted to version them separately.
My solution is as follow:
checkout the Firefox code from the Mercurial repository;
checkout an additional repository with the additional file I need;
before starting the build, I copy these file to the folder with the Firefox code.
This approach is implemented in the following repositories:
buildconfig-mozilla-central: it contains the Buildbot configuration, which
pulls both repositories
copies the files from the scripts repository
and start the build;
buildscripts-mozilla-central: the repository with the build configuration and helper scripts.
Please note that the code might not be well factored (for example the paths) but it should be a good starting point.
This procedure is tailored for Firefox, but it can be applied to any repository.