My goal is to publish a extension in vscode marketplace without manually interact. Can someone make me aware, whether I can use extension API for this or there is another way using curl option?
You can use the vsce CLI. With this you can publish and update an extension from command line. Therefore you should be capable to automate that process in a CI/CD pipeline. There is also an article in the docs that explains how to use the tool.
Optionally, you can take a look to one of my extensions. There I automatically create releases using azure pipelines.
Related
I have everyting automated with CloudBuild and additionally I'd like to create a GitHub release using the CloudBuild. In short, I prepare binary files and then I want to create a GitHub release using those files.
I cannot find any working example. What should the appropriate step look like?
Additionally, I'm not sure about the authentication between GitHub <-> CloudBuild.
You can refer to the Documentation (click GitHub cli tab) where
how to create a release using CLI is explained stepwise.
There is also a separated command Doc for how to add files to
the release.
To use Github Cli in cloud build , the best Practice would be to use
community builder , for more information how to use it you can refer
to the Documentation where Readme contains a more detailed
view.
For more information, you can visit to the Public Documentation where it is mentioned as :
This page explains how to use community-contributed builders and
custom builders in Cloud Build. The Cloud Build developer community
provides open-source builders that you can use to execute your
tasks. If the task you want to perform requires capabilities that are
not provided by an existing image, you can build your own custom image
and use it in a build step. To learn about the different types of
builders, see Cloud Builders.
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.
Specifically I need the yaml for the build definition. I already have Doxygen and Latex installed on the agent machine. Also, I can create Doxygen documentation for the C# Restful API manually using the tool.
Does anyone know how to use the Doxygen Tool in Azure DevOps?
To use the Doxygen Tool in Azure DevOps, we need to install required softwares on agent machine:
Doxygen tool should be installed on the Build agent machine
(download)
PdfLatex tool should be installed on the Build agent machine.
Then add the task Documentation (Doxygen) in the build pipeline to generate the documentation from source code in your repository. On successful generation, the task uploads the file as Build artifact so that it can be downloaded at later time:
Note: This extension doesn't works with Hosted build agent as of now. So, please use a locally configured build agent.
Besides, if you want to generate YAML documentation, you could try to use the extension YAML Documentation Generator.
Hope this helps.
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.
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.