update-release | Github release smartly , with a freshly built asset | Continous Integration library
kandi X-RAY | update-release Summary
kandi X-RAY | update-release Summary
This Github action allows you, and anyone you choose, to easily get access to files created as part of your continuous integration on Github runners. If you use Github to build digital assets such as zip files or executables, this action makes accessing your build products easy for everyone involved with your project. Github has a very walled-garden, hands-on philosophy about what a "release" should be. According to Github, a release must be tagged by a human; release artifacts must be built by a human; and then specific binary assets must be uploaded by a human into that release. This update-release action breaks down those expectations. Any branch, tag, or indeed any Github checkin at all, can now be continuously integrated via Github runners, with its build products continuously accessible to you, your team, or the world, via Github releases. With this action, Github runners can build, test, and package artifacts on any Github ref, branch, or tag. This action continuously creates and updates the necessary Github tags and releases with these artifacts. This update-release action makes sane choices all the way along this process, but it lets you override those choices easily. Every time a Github runner builds your source code, update-release creates or updates a Github release for your assets, and then uploads the freshly built assets into your release. Existing releases are reused, and existing assets with the same names are replaced. Because this action is written in TypeScript and executes in node.js, it runs on all Github's supported build runner platforms. These include Windows, MacOS, and Ubuntu as of this writing.
Support
Quality
Security
License
Reuse
Top functions reviewed by kandi - BETA
Currently covering the most popular Java, JavaScript and Python libraries. See a Sample of update-release
update-release Key Features
update-release Examples and Code Snippets
Community Discussions
Trending Discussions on update-release
QUESTION
I'm using Azure DevOps Services REST API 5.0 to update a pipeline release.
I have a release with a stage DEV that have two tasks in a 'Run on agent' job:
- Deploy plataform 1
- Deploy plataform 2
I want to add a new task 'Deploy plataform 3' using the update method from the Azure DevOps Services REST API.
But when I try to UPDATE have the error:
Tasks with versions 'Deploy Plataform 3:1.*' are not valid for deploy job 'Run on agent' in stage DEV.
I get the release definition using the url:
https://vsrm.dev.azure.com/organizationname/projectname/_apis/release/definitions/5?api-version=5.0
I add a new task in the object environments[0].deployPhases[0].workflowTasks
.
Workflowtasks
object with my new task:
ANSWER
Answered 2019-May-27 at 13:19I found the problem.
The new WorkflowTask
I add has a field taskId
that I was trying to generate. But this taskId
field corresponds to the azure pipeline task type I want to use. In my case, I need to set the azure function app task id, 501dd25d-1785-43e4-b4e5-a5c78ccc0573
.
The documentation for WorkflowTask is not complete, we only have: TaskId: string
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install update-release
The ${{ secrets.GITHUB_TOKEN }} is valid for exactly an hour from the time your build starts. If your build requires longer than an hour to run, you will need to create your own access token with repo admin access, store it as a secret in your own repository, and reference that secret token in your build:.
Because no existing Github action implements all of what is needed to do continuous releasing on Github. Github's new actions system permits a user to perform a build on Windows, MacOS, or Ubuntu. Classically, the result of a build is usually a zip file or some other distribution file that developers would like to download and distribute. But getting a file result out of any Github action build process is harder than it ought to be. Sure, you could upload the file to your own server at build completion, but then you'd be ignoring Github's own file distribution and release architecture. You'll have to check for the existence of any release before you create it, and you'll have to check for the existence of any asset already in a release with the same name, and delete it, before you upload the newly built asset. Or, you could just use this Github action, update-release, which does all that in one step. As of this writing, no other continuous integration plugin makes sane choices for all these steps.
Support
Reuse Trending Solutions
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesStay Updated
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page