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.
Related
We have an in-house Azure DevOps 2019 server and I'm currently setting up a build for a new .Net6 solution whose projects reference various packages from both nuget.org and an in-house feed in our ADO server's "Artifacts" area.
With this being .Net6, I'm assuming I have to use the ".Net Core" restore task (black square icon), rather than the older "NuGet" restore task (blue icon)? I've therefore added the former, and configured the pertinent settings as seen below, where "NuGetPackages" is the name of our in-house feed:
When I run the build, this task is failing with the message
error NU1301: Unable to load the service index for source http://***/_packaging/2df3c440-07a5-4c01-8e5c-bfbd6e132f09/nuget/v3/index.json.
The URL of our in-house feed is:
http://***/_packaging/NuGetPackages/nuget/v3/index.json, so why has the feed name in the URL been replaced with a GUID as seen in the error message? Presumably this is why the restore fails.
Incidentally we have numerous .Net Framework 4.x solutions that reference the same packages and build fine. These use the older "NuGet" (blue icon) restore task, but the settings are identical to those in the above image, suggesting that the newer ".Net Core" task is doing something strange.
(As an aside, could someone explain the difference between the "NuGet" task and the ".Net Core" task? Could I still use the older task in my .Net6 build pipeline? I tried it briefly earlier but it complained that msbuild v17 isn't installed and didn't want to continue down that path for fear of breaking the 4.x builds).
Something that hasn't been mentioned here, but has been the source of my pain when trying to restore from a feed in a different project but the same organization was certain settings of the consuming project... (sic. https://developercommunity.visualstudio.com/t/restore-nuget-task-unable-to-load-the-service-inde/1337219)
After adding the pipeline permissions to the NuGet feed (as per https://learn.microsoft.com/en-us/azure/devops/artifacts/feeds/feed-permissions?view=azure-devops#pipelines-permissions), you need to update the Limit job authorization scope... settings in the project which is restoring the feed.
I just spent nearly two days fighting this same NU1301 error, and while my ADO instance is cloud-based and the "latest", i.e., not exactly analogous to your situation, maybe my experience will shed some light.
The tldr; is that there were permission issues for the ADO "project" build service account accessing the "organization" Artifact feed. The output from the DotNetCoreCLI#2 restore task didn't even hint in that direction, but when I dropped-back to using the NuGet restore task, the error messages were more informative and helped me discover the underlying issue.
This info doesn't shed light on the guid/name swap issue you ask, but maybe the guid is an internal ID that is first used to then resolve the name, and if a permissions issue prevents even querying the Artifacts endpoint ...
As for the msbuild v17 comment, I would heed very carefully this advice and your trepidation about messing with the existing builds. To paraphrase that old quip ... it's not really paranoia, if MS has a well-established history of breaking stuff that has worked just fine for a very long time! ;-}
HTH.
SC
Here are the steps that helped me fix this same issue in Visual Studio.
Make sure that you have Owner or Contributor permissions to the Feed in Azure DevOps. Something like this:
Then in Visual Studio make sure that you are signed in using the account that has the permissions from the previous step.
Finally rebuild the solution.
Hopefully this fix your issue too!
The company I work on recently purchased SonarQube Enterprise to improve code quality throughout all repositories. I found out that there is a feature that enables SonarQube to comment automatically on PRs targeting a specific branch, and I successfully managed to try that out.
Thing is:
That configuration is not scalable: I would need to manually configure every repo to follow that rule
That configuration needs a build pipeline to be defined "old school" on Azure DevOps to work, and we are moving into Pipeline as Code, starting of course with CI (where this takes place)
Anyone managed to get the PR commenting working in that scenario? Or, at least, solving the #1 problem?
Cheers
You can use REST APIs to do whatever configuration you need to do across your repositories. Refer to the REST API documentation.
Shouldn't matter, although I haven't tested it. The SonarQube tasks aren't aware of whether the build source is YAML or visual designer/classic/JSON builds. The underlying tasks and job running architecture is the same. As long as the build is hooked up to a branch policy, it should still work.
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 starting to delve into Octopus Deploy and setting up my first deployment but I've ran into a bit of a snag. I have tried to be as specific as possible in lieu of finding someone who has experienced this same problem more recently. "This is not a new problem. See -reseach"
The setup
Versions:
TeamCity 10.0.4
Octopus Deploy 3.10.1
My continuous integration stack is comprised of TFS, TeamCity and now Octopus. My deployment process:
TeamCity runs the .NET application build. (Scripts, tests, etc..)
TeamCity Octopus plugin successfully creates the versioned Nuget packages.
A TeamCity build step using "OctopusDeploy: Push packages" pushes the packages to the octopus server.
In Octopus an external feed was added an tested called "Octopus Local Packages" pointing to the default internal octopus package directory: C:\Octopus\Packages.
An octopus project was created with a single step using the "Deploy an IIS Web Site" template, where the package section is setup like this:
The problem
Research
This has happened in the past on versions prior to 3.0.7 where it was fixed. Link to bug thread 1.
Then it started happening again at some point prior to version 3.4.15 where it was fixed. Link to bug thread 2.
Any help, fix, or workaround will be greatly appropriated. If there is a detail that I'm missing I will be more than happy to clarify.
Update
This may very well be a rookie mistake when it comes to Octopus. The error shown in the question is in fact a result of the deployment package not being found. The following are findings through documentation and trial an error:
Octopus Server (built in) is a push feed only. Meaning that packages can be uploaded to this feed but not consumed.
To consume Octopus' server local packages, namely the packages previously pushed to Octopus Server (built in) from say TeamCity, you have to serve those packages yourself.
You can server those packages through Octopus by creating an external feed that points to the server's package default path: C:\Octopus\Packages
Most Importanly, and the fix to the error!
When changes are made to a deployment process step, a new release MUST BE created. Simply redeploying the previous release will try to redeploy with the previous step settings saved in a snapshot and not with the new step settings. This may come a a surprise to TeamCity users like myself based on TeamCity's behaviour.
I am attempting to create a manual build in Jenkins that will build a specific changeset of code from TFS for a deployment into a testing / production environment.
Currently I am only able to use TFS in Jenkins to pull everything up to the newest Changeset out of TFS.
I am running Jenkins version 1.471 with the TFS plugin version 1.20
Has anyone run into the problem, and do you know how to fix it?
Thanks in advance.
This feature is missing, but seems to be under way according to the comments of this Jira issue:
TFS Support to get labels
So, not specific changesets, but for me labels would be good enough as they can be applied at any time.