Replies: 8 comments
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
very informatics thanks for sharing |
Beta Was this translation helpful? Give feedback.
0 replies
This comment was marked as off-topic.
This comment was marked as off-topic.
-
Awesome. |
Beta Was this translation helpful? Give feedback.
0 replies
-
Thanks for the sum up, that was very useful! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
A release is a specific version of your software that can be downloaded and deployed. In this article we will walk through the steps of tagging and packaging a software release using GitHub's REST API.
On the surface, everything starts with a commit. The idea of tagging a commit and turning it into a release is that this particular set of changes is special and set aside from the rest of the events in a repository.
There are three steps to packaging a software release:
Tagging a Commit
A release is based on a git tag, which is a human readable name for a specific git commit that you can reference later. Tags can be divided into two groups to mark releases:
Lightweight Tags only include information on a commit. Lightweight tags only need one API call to Create a Reference.
Annotated Tags include information on the tagger, the date the commit was tagged, and also an annotation message. If you are using annotated tags, you have to first Create a Tag Object then Create a Reference.
In this example, we will be creating an annotated tag. To accomplish this, you must first make an API call to
/git/tags
to create the tag object.CREATE A TAG OBJECT
To create an annotated tag, you need to create a tag object. Annotated tags contain more information that a lightweight tag. Namely these tags answer the questions: who tagged this commit and why did they tag it. The following is an example API call that was made to the test organization Evil Corp. For tag objects, there are two elements:
tag
- the name of your tag, most often this is a version number (e.g., "v0.0.1")message
- additional information you would like to include with the tagobject
- the commit SHA of the commit you are taggingtype
- type of object you are tagging, a majority of the time this is a commit. However, you can also tag trees or blobstagger
- this is information regarding who tagged the commit, their email, and the date they specified for the tag.The response of this request should show
HTTP/2 201
if successful.Note: In this example we used a GitHub Personal Access Token which shows
x-ratelimit-remaining: 4995
this means we have successfully authenticated. If this value shows 60, then you have not successfully authenticated against this endpoint and need to try again.The response includes the following:
To create the reference, you need the tag object SHA. In this output, the object is
"sha": "925e06a1b16f55e866d70d85620314893146f440"
.CREATE A REFERENCE
A Reference is pointer to a commit SHA in a repository. It's a value that tells git how to locate objects. Once you have created a tag object, you need to create the reference so that git knows about the object you have just created. To do this, you will make the following API call to
/git/refs
:A
ref
is the name of the reference you are creating. Because we created an annotated tag, this should match your tag object.The
sha
needs to be your tag object you have created. If you are using a lightweight tag, then you will use the commit SHA.If successfull you will received a
HTTP/2 201
response.The response shows that an annotated git tag was created for the commit you have just made. This tag contains additional information that you inserted into your tag object.
Once you have created the tag, it will also appear in GitHub's UI.
Creating a Release
To turn your tag into a release, you need to make an API call to
/releases
.tag_name
- the name of your tag that you created in your reference.target_commitish
- the name of the branch where your tag is located.name
- The name of your release. This will appear in GitHub's UI.body
- Information about your release. This will also appear in GitHub's UI under your release information.There is an option to generate release notes as well as to do a pre-release. If successful, the header information will return
HTTP/2 201
.The following response contains all the information about the release you have just made. The release id
"id": 98122155
is important because we will use it to upload release assets in the next step. It is important to note that you can name your tag differently than your release name. In this example, our release is"name": "Hello World v1.2"
but our tag is simply"tag_name": "v1.2"
. Depending on the versioning requirements regarding tags within your organization, you can make additional adjustments as necessary.Finally, our release now appears in GitHub's UI.
Uploading a Release Asset
A release asset is an artifact that provides a rusable set of tools to be used during the creation, development, or delivery of software development. Release assets can include binary files, release notes, software licensing, and anything that should be packaged along with your software for the end user.
Before uploading a release asset, you need the release id. You will have received one in the output of the release you created. However, if you do not remember your release id, you can make an API call to the
/releases
endpoint.GET A RELEASE ID
To get your release id in order to upload a release asset, you need to make an API call to the
/releases
endpoint. For this example, because we are using the latest release we can make an API call to/releases/latest
:If this request was successful, your header information will return
HTTP/2 200
Your release id will appear in the return. In this example, our release id is
"id": 98122155
this id will allow you to upload release assets to your release version.UPLOAD A RELEASE ASSET
Once you have your release id, you can make an API call to
/releases/assets
. In this example, we have createdevil.zip
. This zip file contains the evil license and evil release notes. However, you can zip up anything you think people will need in order to use your software. For this API call, you are not going to useapi.github.com
like we have been using in the previous sections. Instead, you will upload throughuploads.github.com
. Additionally, you will need to enclose your URL in quotes for this to be effective.Once you have packaged your zip file, you can now upload your assets.
If successful, your header information should return
HTTP/2 201
.The response shows the details of your newly uploaded asset.
Finally, your release as well as your assets appear under your release version within GitHub's UI.
If you have made it to the end, congratulations on your software release. For other API functions within GitHub, please check out the list of REST API Endpoints.
Beta Was this translation helpful? Give feedback.
All reactions