Is it possible to release on GitHub through the command line with an attached file that is not pushed to a repository?
I have a file over 1GB that I easily attached through a web GitHub release page, but I want to automate that using bash.
You can from command-line, using gh: cli/cli/
create a relase
gh release create <tag> [<files>...] [flags]
upload a file to that release
gh release upload <tag> <files>... [flags]
And since Github CLI 2.4.0 (Dec. 2021), you have:
the non-interactive flag --generate-notes, which allows you to skip the editor phase.
an interactive mode to choose a tag name
There's a REST API that can be used for this purpose. It's used to upload a release asset if you know the ID for the release (which you can get by querying the release itself). You can also get the upload URL by querying the release using a GET request; that returns the upload_url attribute.
If you want an example of how to do this from the command line with curl, Git LFS has a script that it uses to do releases and upload assets which you could look at. It's a little complex, but it is reasonably comprehensive.
In addition to the gh tool and directly using the REST API (as mentioned in other answers), there are several command-line tools which let you create and manipulate GitHub releases. These are likely to be much simpler to use than directly using the REST API.
There is only one* I could identify that I could unreservedly recommend, however: github-release, which is written in Go. Binaries can be downloaded from the project's Releases page, it "dogfoods (transparently uses its own tool), and is actively maintained (as at January 2022).
Some others are:
Another Go app called github-release, released by BuildKite. However, this seems to be less actively maintained, and it doesn't transparently "dogfood" (viewing its CI results require an account with BuildKite).
For Haskell developers, there's yet another tool called github-release, created by Taylor Fausak. It seems to be actively maintained; however, no downloadable executables are provided, so you must build it yourself using a Haskell compiler and build tools.
For node.js developers, there's release-it; but as a node project, it doesn't provide executable binaries that could be invoked from Bash at all.
*If there are others that I've missed, feel free to add them in comments.
Related
I have a GitHub worflow which builds and deploys a snapshot version of a library as a GitHub package, e.g., mycompany.mytool.1.0.0-SNAPSHOT.jar. Whenever I make a new build and deploy, a new asset is created, like, e.g., mycompany.mytool.1.0.0-20210723.145233-1.jar instead which is then somehow associated with the SNAPSHOT tag. This all seems to work and I can access mycompany.mytool.1.0.0-SNAPSHOT.jar without problem.
My question now is, how can I get rid of all these older versions of this jar? Actually I just want to keep the latest version. I can delete them manually via the web-interface but that is a more than awkward task. I would somehow like to automate this too.
This is not possible as of this writing. GitHub staff member Jamie Cansdale wrote this in their community forum:
SNAPSHOT versions are exposed as artifacts inside a regular versions. There isn’t an API for cleaning up artifacts, only whole versions.
(source)
Which means that a single SNAPSHOT version (like 1.0.0-SNAPSHOT) will accumulate all builds you make, and all artifacts will show up on the Assets list to the right of the web page.
The only practical solution I can think of, is that you delete the whole version from a script, before publishing each build's artifacts. Then you'd have the effect of having a single set of artifacts stored as part of the 1.0.0-SNAPSHOT version name.
However this solution is not ideal: public package versions cannot be deleted if they are popular enough (probably to avoid squatting attacks):
If the package is public and the package version has more than 5,000 downloads, you cannot delete the package version. In this scenario, contact GitHub support for further assistance.
I am using Desktop Bridge with a c# Winforms application to make a package to publish to the store.
If I make my package locally using Desktop Bridge then I can upload it to the windows store successfully.
I am also now able to build and create the package artifact using a pipeline and I can see it in the Artifacts explorer.
I am having trouble following the docs on how to get the package into the store.
It mentions
ps
$(Build.ArtifactStagingDirectory)\
AppxPackages\MyUWPApp__$(AppxVersion)_x86_x64_ARM_bundle.appxupload
Does ps mean powershell?
How do I get the YAML?
Or am I meant to build a release pipeline?
I tried looking at the release tasks but could not find anything that mentioned the Store.
This is a great article on how to build your package and deploy it to Hockey App (now App Center) but can be used to deploy to the store as well. I'm not sure exactly how you would convert it to YAML, but it shouldn't be too difficult.
https://mobilefirstcloudfirst.net/2016/02/continuous-deployment-of-windows-10-uwp-apps-to-hockeyapp-using-vsts/
Once you have the package built following the instructions in the article (It sound's like you already have), skip the Hockey App steps and instead publish to the store with this Azure DevOps extension task step: https://marketplace.visualstudio.com/items?itemName=MS-RDX-MRO.windows-store-publish
Instructions to use the extension are on the extensions web page. You'll have to have an Azure Active Directory account. If you don't have one, it's easy to set up and it's free!
To answer your questions
Does ps mean powershell? - I just browsed down through the article and I don't think so. Usually it's saying you need to give this value in a property in the build step.
YAML is pretty new, and there is not, as far as I know, an easy way to convert it to YAML.
You'll probably want to do this in two steps: 1) Build the package and upload the artifact. 2) Download and release the package. Step 1 should be done in a build, step 2 should be done in a release. I find splitting these steps into two very helpful when only the release fails. Then I don't have to rebuild the package to try again, I can just redeploy the release.
I am new to Octopus deploy but what I am after is a way to get the jira ticket numbers into the release notes in octopus deploy. I would like to know the fixes/features related to the build number.
I have written a Powershell step for TeamCity that queries the JIRA API to get all issues with the Fixed In version equivalent to the version number that TeamCity is building, and then querying the JIRA API again to get the issue details so that I can then build the release notes in Markdown, which then gets passed into Octopack to embed in the Nuget package. Then when I go into Octopus, I can see all the included ticket numbers and summaries, grouped by issue type (bug fix, new feature, improvement etc).
Given that it is very straightforward to create an Octopus step using Powershell, and the ease of use of the JIRA API, you ought to be able to do something similar from Octopus, but if possible, I would recommend making it part of your build process rather than your deployment process.
After installing Release Management client and connecting to my Visual Studio Online account I only see 4 actions.
Online I see that other people have a lot more actions in their toolbox:
What you are seeing is correct since in VSO you do pretty much everything in PowerShell using the Deploy Using PS/DSC action. I have a blog post series on Continuous Delivery with VSO here that might be of use in understanding how to get going.
As Graham pointed out what you are seeing is correct. On VSO RM only supports the DSC/PowerShell (vNext) pipelines. But the on premises product also supports the Agent based solution which is where you see all the additional actions and can add our own.
If you look at how the Agent based actions are created most are PowerShell and you can modify the PowerShell to work in a vNext pipeline. Here is an example of making a script work in both. That would require that the PowerShell be a part of your project so RM would be able to execute it during your release. Not as nice a solution as the Agent based but the next version of RM will address both of your concerns. There will be a way to establish a secure connection with Azure and a way for you to add custom actions or “Tasks”.
Keep an eye on DonovanBrown.com or follow me #DonovanBrown, I have blog post ready that I can’t post until the new RM is released. Before anyone asks I don’t have a date.
The project that I am working on is a jQuery plugin. I have managed to get Travis CI to build a test project using Gulp/NodeJS successfully. Now I am trying to work out what workflow to use to bump the version number.
In TeamCity and MyGet there is a setting in the CI server to form a version number pattern that auto increments on each build, which can be used by the build script to update versions in the deployment files and to label the Git repo. However, in the free version of Travis CI, there doesn't seem to be an option for versioning at all.
I have read several articles on continuous deployment with Travis CI, here, here, and here, but none of them even broach the topic of versioning. Obviously, the version needs to be changed for the release. So what am I missing here?
Another problem I noted when going through the documentation is that it mentioned that Travis CI is not able to update the GitHub repository. Doesn't that basically mean it won't be able to create a Git tag?
If there is no way to version from Travis CI, then what is the typical workflow for the release process for such a plugin? Is the versioning always done manually? If so, how could there be "continuous deployment"?
Before it starts running the instructions in your .travis.yml file, Travis will set a bunch of environment variables (in the VM that is building your project) with various bits of information about your build, such as what branch is being built and so on.
You probably want one of these:
TRAVIS_BUILD_NUMBER: The number of the current build (for example, “4”).
TRAVIS_JOB_NUMBER: The number of the current job (for example, “4.1”).
But it's going to be very difficult to do anything sensible if you don't have control of the repository, because you'll need to upload a .travis.yml file into the root of your source code folder, otherwise Travis won't know what to do.
Use bumped for release versioning. When you're satisfied with the changes in master, run:
bumped release <major|minor|patch>
After you push the changes, either directly or through a release PR, you can check for the presence of new tags in Travis CI and publish the package to the registry automatically.
If you consider that every PR must end up to your enduser without thinking of the impact of such changes, then your version numbers have no meaning.
You don't give your user a way to know if it is a major change that break compatibility or a bug fix. You don't allow him to get update without worrying about backward compatibility.
Currently, the commit id is your version number.
If you want to give meaning to your version numbers then you have to think of the impact of your pull requests on the enduser (http://semver.org/). You have to choose a version number for a specific PR or a group of PR.
So basically, since you have to 'think' of a certain version number for a specific version that you want to deliver, you can't automate this process.
Release/tag creation is the way to go : )
You can accomplish this by setting up a script that would create a ~/.netrc file to access the repository. In this file you can specify something like:
machine https://github.com/xxx/yyy.git
login <blah>
And instead of putting in your credentials, you can pass an github access token. You can use the travis encrypt to register it in the .travis.yml file, and export the variable for your script's use. From there in your script, you can issue regular git commands such as:
git add <some file>
git commit -m "This is $TRAVIS_BUILD_NUMBER"
git push origin <branch>