I have quite a complex TeamCity-Solution.
Configuration "tcBuild" builds and creates nuget-packages, as well as it modifies the version number of the assembly.
Configuration "tcDeploy" depends on "tcBuild", takes the nuget-packages and send it using octopus.
tcBuild just works fine and also creates the wanted packages.
tcDeploy throws the following error for each package:
2014-01-28 14:50:05.5826 ERROR Unable to download package:
Octopus.Platform.Deployment.ControlledFailureException: Could not find package Packagename 1.1.0.903 in feed: 'http://localhost/httpAuth/app/nuget/v1/FeedService.svc/'
at Octopus.Shared.Packages.PackageDownloader.FindPackage(Int32 attempt, PackageMetadata packageMetadata, IFeed feed, IActivity log) in c:\TeamCity\buildAgent\work\1116bd9da9e239fd\source\Octopus.Shared\Packages\PackageDownloader.cs:line 155
at Octopus.Shared.Packages.PackageDownloader.AttemptToFindAndDownloadPackage(Int32 attempt, PackageMetadata packageMetadata, IFeed feed, IActivity log, String cacheDirectory, IPackage& downloadedPackage, String& path) in c:\TeamCity\buildAgent\work\1116bd9da9e239fd\source\Octopus.Shared\Packages\PackageDownloader.cs:line 130
at Octopus.Shared.Packages.PackageDownloader.AttemptToDownload(PackageMetadata metadata, IFeed feed, IActivity log) in c:\TeamCity\buildAgent\work\1116bd9da9e239fd\source\Octopus.Shared\Packages\PackageDownloader.cs:line 89
2014-01-28 14:50:05.5826 ERROR Error in DownloadAndPushToTentaclesOrchestrator-OCw-lDdz+eWP#SQ-PESY0002-F9FA8F1A while receiving bedf70c1-1f30-496f-91ca-aba6cc956042
(where "packagename" is the name of the package)
The version number of the error message is the same as of the nuget packages' "core-properties"-folder.
Other, quite similar builds on that machine work just fine. Tell me if I need to provide more information.
You can try to create one tc project to package which triggers another project to deploy. We ended up with this approach so that we can deploy the latest build to octopus. Good luck.
Related
I've been unable to query my existing contract recently due to Unable to create Enum via index 128, in Alive, Tombstone when using api.query.contracts.contractInfoOf. I get this error both on the command line and in the polkadot-js apps explorer.
These are the steps I took:
Deploy a contract with a salt
Retrieve the contract deployedAddress
Use contractInfoOf
const contractInfo = await api.query.contracts.contractInfoOf(deployedAddress);
I've tried downgrading ink! to 3.0-rc5, 3.0-rc4, 3.0-rc3 and then compiling but it doesn't seem to make any difference. Whenever my contract is built it references rc6 at the top:
{"metadataVersion":"0.1.0","source":{"hash":"0x...","language":"ink! 3.0.0-rc6","compiler":"rustc 1.58.0-nightly",
Which suggests its ignoring my .toml and using rc6 to compile the contract.
I changed my cargo-contract version to 0.14 but that causes polkadot-js to fail at reading the contract abi.
I've tried using the substrate-contracts-node using the latest commit from master and also using the v0.1.0 release. Same error in both cases.
> rustup info
stable-x86_64-unknown-linux-gnu (default)
rustc 1.56.1 (59eed8a2a 2021-11-01)
There are more details in an issue on polkadot-js.
Any pointers on how to get a working setup would be very helpful!
The problem here was substrate-contracts-node using an old version of the metadata.
I was able to check out the repo before the metadata merge was reverted and build locally (cargo build).
So checkout 8d91b8e to get the node to work with versions 7.7.1 and 6.6.1 of polkadot-js packages.
> git checkout 8d91b8e578065a7c06433cbd41ac059bf478a0bd
> cargo build
> ./target/debug/substrate-contracts-node --dev --tmp --version
substrate-contracts-node 0.1.0-8d91b8e-x86_64-linux-gnu
Hello to all i'm currently using the client of socket.io (https://github.com/socketio/socket.io-client-swift) with the new package manager of XCODE13 when i try to add the package using the package manager, i paste the URL of the repository(https://github.com/socketio/socket.io-client-swift) into the search bar, the package appears, then i do click into 'Add Package' button, but i get this Error (see the image):
If i use the 'Add Anyway' option in order to add the package the line import SocketIO into my view file doesn't find the package gives me an error, and i have the same result importing the package via 'Add Local' option, i get the same error.
Thank you and sorry for the English
Am i doing something wrong?
I also have problems with socket.io using Carthage in Xcode 13 and Monterey
Building scheme "SocketIO" in Socket.IO-Client-Swift.xcodeproj
Build Failed: …
…
This usually indicates that project itself failed to compile.
Edit: I fixed my issue replacing the 1200 by 1300 in the carthage workaround script
I'm using Salt to install a windows only software called Alteryx.
I've created an /srv/salt/alteryx/alteryx.sls as follows:
alteryx:
'2018.3.4':
installer: 'salt://win/repo/alteryx/Rinstaller_2018.3.4.51585.exe'
full_name: Alteryx Designer 2018.3.4
reboot: False
installer_flags: '/S /l="C:\temp\alteryxInstall.log'
My saltstatck file is in /srv/salt/alteryx/init.sls is simply
alteryx:
- pkg.installed
When I try to apply this state (salt -G 'roles:alteryx' state.apply) I get the following error:
hostname
Data failed to compile:
--------
ID alteryx in SLS alteryx is not a dictionary
I've tried placing the alteryx file in /srv/win/repo-ng/salt-winrep-ng/. But I get the same error.
What else do I need to do to get this package installed?
First of, if you have a look at sample package definition sls file, there is no installer_flags argument. It should be install_flags instead.
Second, Salt doesn't distribute SLS file for windows packages itself, you need to sync them across manually every time a change is made.
From your Saltmaster run,
salt-run winrepo.update_git_repos
Run pkg.refresh_db on each of your Windows minions to synchronize the package repository.
salt -G 'os:windows' pkg.refresh_db
Please have a read at this as well.
I'm using VS2013, Xamarin.Android 4.12.4.20.
Build is successful.
I'm getting error from title whenever I try to deploy in debug mode or package.
It started to happened today it work fine before.
I've restarted VS, device, PC - none helped.
Stack trace:
Xamarin.AndroidTools.AndroidDeploymentException: InternalError ---> System.ArgumentException: An item with the same key has already been added.
at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
at Mono.AndroidTools.Adb.AdbSyncDirectory.Add(AdbSyncItem entry)
at Xamarin.AndroidTools.AndroidDeploySession.InstallAssemblies(String destinationPath, CancellationToken token)
at Xamarin.AndroidTools.AndroidDeploySession.FastDev()
at Xamarin.AndroidTools.AndroidDeploySession.Run(CancellationToken token)
at Xamarin.AndroidTools.AndroidDeploySession.RunLogged(CancellationToken token)
--- End of inner exception stack trace ---
at Xamarin.AndroidTools.AndroidDeploySession.RunLogged(CancellationToken token)
at Xamarin.AndroidTools.AndroidDeploySession.Start(CancellationToken token)
Build output:
3>Build succeeded.
3>Waiting for device..
3>Detecting installed packages
3>Detecting installed packages...
3>
3>Removing previous version of application
3>Removing previous version of application...
3>
3>Installing application on device
3>Copying application to device...
3>
3>Getting installation path...
I've figured it out. Make sure that you don't have different versions of the same dll referenced!!
Let me describe my set up a bit more that will help with explaining why exception happened.
I've got two projects
Domain - library with code shared between all platforms
Android - android specific code
Both have nuget references to the same library. At some point android (only in this project) nuget references have been updated which resulted in two versions of the same library required by the application (Domain project still referenced old nuget).
When I tried to package solution I would get warning like :
Consider app.config remapping of assembly "{Library}" from Version "5.6.0.0" [] to Version "5.6.1.0" [{Path}] to solve conflict and get rid of warning.
Once I've update Domain's nuget everything worked.
I am using Marmalade to build a PlayBook app, but I think my question applies to PlayBook apps in general. I have successfully created a debugtoken.bar file and have installed it on my device. When I go to try to install a built application.bar file on the device, I get:
[execute] "blackberry-deploy.bat -device 192.168.1.114 -password ******* -installApp -package deployments\default\playbook\release\Quote Unquote.bar"
Info: Sending request: Install
Info: Action: Install
Info: File size: 6400334
Info: Installing ...
Info: Processing 6400334 bytes
actual_dname::
actual_id::
actual_version::
result::failure 881 required signatures missing (RDK, AUTHOR)
ERROR: error running blackberry-deploy
***ERROR***
Note that this is the Marmalade deploy tool running the standard PlayBook installer.
What I don't understand is: I thought the point of using a debugtoken.bar file was that you could install unsigned apps. I have in fact successfully deployed these unsigned apps using the Marmalade deploy tool just like this. But I was having problems signing the app for distribution, so I went back and did everything from scratch, requested new code signing keys from RIM, made a new debugtoken.bar file and installed it, etc. And now I'm worse off than I was before because I can't even install to the device now.
So again: My understanding is that the point of debugtoken.bar was to be able to deploy to the device before actually signing the application.bar for distribution. So what does this error message even mean?
To answer my own question:
For deploying a "debug" build to a device, it's critical to have
Application-Development-Mode: true
in the MANIFEST.MF within the .bar file.
A stupid mistake, but I'll leave this up in case it helps anyone...
Taking a look to the QNX deployment plugin "C:\Marmalade\6.1\s3e\deploy\plugins\qnx\qnx.py" I found that 'FOR DEVELOPMENT' option is false if the 'playbook_keystore' is given so I just cleared the signing section on the Marmalade System Deployment Tool and it is not longer trying to sign it