I have setup the trigger to listen to the last pinned build artifacts:
<TEAMCITY URL>/repository/downloadAll/bt79/.lastPinned
However, the trigger keeps firing every 30 seconds which is the default Polling interval.
Am I missing something here? The url always gives me the same file.
UPDATE:
After upgrading to TeamCity 7.1 the problem still exists.
The answer to this question came from TeamCity support:
The reason of the described behaviour is the way TeamCity controller
returns data requested in downloadAll query. The .zip containing the
artifacts is actually different on each request and build is
triggered.
To workaround this issue try using
<TEAMCITY URL>/guestAuth/repository/download/bt79/.lastPinned/<some artifact> if possible.
this one worked for me.
Related
Working with Salesforce, org is authorised, everything works fine until it doesn't and there's no error code or anything.
In the morning I retrieved a few files I had to change, 10 minutes later when I needed to retrieve another one, it kept "Running SFDX: Retrieve Source from Org" for a few minutes and failed. Then again and again, whether I deploy something or retrieve, it just fails.
Closed, waited for it to sync, refreshed all lwcs, still the same problem.
You may have a sfdx-cli issue. There is a known issue right now with the version 7.150.0 reported here: https://github.com/salesforcecli/status
My team was having issues with our CI pipeline, and our fix was to use an older version. Once we updated our CI tool to grab https://developer.salesforce.com/media/salesforce-cli/sfdx/versions/7.149.1/3881a5a/sfdx-v7.149.1-3881a5a-linux-x64.tar.xz extract the binary, and run the tool, our deploys started working successfully.
Check your local and CI tool with the sfdx --version command. If you are using the broken one, roll it back to the version that you need.
I am working on a project that uses Codeship to deploy builds. I got up today and saw:
Normally a build takes ~2 minutes, but I have waited on this one for half an hour. Codeship does not show anything being run. Not a single command. And my integration does not show the new application version, either.
How can I fix the hanging build?
Fixed! I just had to stop and restart the build as well as reset the dependency cache. Thanks #mlocher for the help.
If anyone came here from a search engine or something else with the same problem, try to restart the build, restart after resetting the dependency cache, or making another commit with a trivial / no change. This should fix the problem. Otherwise, send codeship a ticket at helpdesk.codeship.com.
Using a powershell script to deploy a CRM Package works well, but I am running into some unexpected behavior.
The package has 1 unmanaged solution that it uploads. It works perfectly if the solution does not exist on the target CRM organization. However, if the solution does already exist on the organization and I try to deploy it again with some changes, it will not work. The changes are not uploaded and I do not get any errors.
If I change the version number in the solution (from 0.0.1 to 0.0.2, for example) then uploading it works as expected.
I would rather not change the version every time though, and since manually uploading an unmanaged solution with the same version number works perfectly I would expect the script to be able to do it as well.
I tried using the CRM Package Deployer method of importing a package to see if it would work as I expect or if it would show any error messages.
It's messages show:
Skipping solution MySolution. Version 0.0.2 of the solution is already loaded.
So it appears that if a solution with the same name and version number exists in the organization then it will be skipped entirely. This is sort of unfortunate.
It seems I'll have to implement a workaround. I see two options:
The DeployPackage script deletes the solution in the target CRM organization (if it exists) before attempting to upload.
My ExportSolution script changes the version number every time it runs.
I've installed the ghprbhook plugin to my jenkins system. It triggers when I send a PR but isn't setting the result text properly. The 'success' / 'failure' message is working but the rest is Build finished. No test results found.
The disconnect seems to be between the gradle build plugin and the ghprbhook service. In the ghprbhook source it's checking for hudson.tasks.junit.TestResultAction to be set and apparently it isn't.
Question:
Is it possible to have gradle set the appropriate values? If so, how?
Turns out that I was looking in the wrong place. The way to get useful values to show up in github is to add the Publish JUnit Test Result Report post-build step to your jenkins job. Assuming that you have gradle and junit outputting xml you should see the output in github when you build.
So, the key element here is hidden artefacts, also known as those that appear under .teamcity/ part of the build artifacts.
Some context:
We currently run dotCover over our NUnit Test step to report on our test coverage. This places a compilation of the results in a file named CoverageResults.xml under .teamcity/.NETCoverage/. This is the file I would like to accces so we can mine if for some data and send it to a gecko board.
Now, so far, we can successfully get at artifacts not in this part of the directory (such as the result of the build when we output it, etc) using the advised methodology. The problem only occurs when accessing this hidden directory.
The other odd things is the response: a 302 Temporarily Moved.
For reference, my link looks like: (in powershell btw)
"http://{0}:{1}#{2}/guestAuth/repository/download/{3}/.lastFinished/.teamcity/.NETCoverage/CoverageReport.xml" -f $serverURl, $gUName, $gPassword, $buildType
Does anyone have any advice on accessing hidden artifacts? Where else this data could be drawn from (we've found nothing on system variables for this)?
Note: We are already aware that these artifacts are not produced till the build step completes. We are doing this after the fact against a completed build, not during the Build Job itself.
If you add this in the Artifact Paths field it will attach the report as a build artifact once the build has completed
%system.teamcity.build.tempDir%\**\CoverageReport.xml
Hope this helps
Leaving the solution we came up with in case it can be help to anyone else:
In the end, we never got the nitty-gritty of the why but in short, using the in URL authentication with Powershell's Invoke-WebRequest does not work. It appears this is culled from the request created or some such but we went in another direction so I cannot comment much more on this.
What we did do was instead, use cURL. This does not do whatever Powershell does so we simply broke this down into two steps on the Team City Build. A command line step to use cURL to download the file and place it in a temporary directory and the a Powershell step afterwards to get the file and do what we wanted to do.