Rather than cfx's --updateurl command, with jpm, we can simply place the updateURL in package.json. This URL points to a file called update.rdf, which tells self-hosted addons where to look for updates.
With cfx, that update.rdf file could be generated with the --updatelink, but that option has been removed from jpm. I can't figure out how to generate update.rdf using jpm. Any ideas?
I've made issue 288 for this, in the meantime you will need to follow these instructions to learn how to build the update.rdf yourself https://developer.mozilla.org/en-US/docs/Extension_Versioning,_Update_and_Compatibility#Update_RDF_Format
Related
I am playing around with Microsoft's Q# library, and I've gone through the install, however the build is failing and I am having a tough time figuring out the problem. My first suspicion is Microsoft.Quantum.Canon
EXEC : error QS1001: Assembly E:\Projects\Quantum\Microsoft.Quantum.Canon\bin\Debug\Microsoft.Quantum.Canon.dll not found
I also have noticed Microsoft.Quantum.Canon.nuspec is missing. I've tried to do a Nuget.exe restore on the solutions but that did not work.
Has anyone worked through this?
It's been reported on GitHub already, although it appears to be intentional. See the comments in the .gitignore file:
# These files are generated by bootstrap from a .v.template (version template).
# Any changes must be done to the corresponding the .v.template file directly
Microsoft.Quantum.Canon/Microsoft.Quantum.Canon.nuspec
I can't find any info on this .v.template file, probably it's part of internal Microsoft build tooling. You can copy the template file and fill in the missing parameters if you wish, but the file not existing doesn't make the build fail , does it?
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.
I wrote a plugin using FireBreath, VS2010, for Windows, all browsers.
In FireBreath documentation I saw that I have to install WiX. I installed it.
I created the project using the automatic fbgen tool so it autmatically created a WiX for me.
I couldn't understand from the doc is waht to do now:
Do I have to edit the generated WiX source file? If yes, what to change there?
What to write in the object tag that will trigger the installation of the msi created?
Or at least say to the user that installation is needed and link him to a download?
10x!
With the WiX Toolkit installed, re-run the prep__.bat file to regenerate the installer project along with the main plugin project. Build the plugin project, then build the installer project named something like {YourPlugin}_WiXInstaller. The msi will be placed in Firebreath's \build\bin\{YourPlugin}\{Configuration} dir ( {Configuration} is Debug, Release, etc).
It's not necessary to edit the WiX file unless you really want to change a specific setting. One thing I can think of is changing the default per-user install to all users. Per-user is usually better because it avoids UAC issues.
Deploying it to the user is a bit trickier. For most browsers, the user must save & run the msi. On IE you can declare an object in the HTML body and point the codebase to a URL containing the plugin:
<object id="pluginid" type="application/x-yourplugin" width="0" height="0" codebase="/YourPlugin.msi" >
<param name="onload" value="pluginLoaded" />
</object>
However IE9's security seems to block MSI's here. It does work if the plugin DLL is used (codebase="/YourPlugin.dll"). This auto-install method only works in IE with signed binaries (unless IE's security options are cranked way down).
Hopefully a discussion thread on the MSI security issue will yield some answers.
Update:
As hinted by Richard / taxilian, an MSI must be packaged within a CAB file in order for IE to install it. Getting the INF right and creating the CAB takes some additional steps as documented by RB. And to add yet another wrinkle, Vista/Win7 do not allow the INF to call any binary outside of the CAB file, so a stub launching app must be used (see this thread and example code posted by Roey towards the bottom).
I'm using Eclipse 3.5.2 and I've created a p2.inf with the following information:
instructions.install = \
chmod(targetDir:#artifact,targetFile:$os$/libfoo.so,permissions:755);
instructions.install.import= \
org.eclipse.equinox.p2.touchpoint.natives.chmod
I placed the p2.inf inside the META-INF folder of the fragment, but when I install the update site, libfoo.so does not have execute permissions.
After pulling my hair out, I tried a p2.inf referencing a non-existing *.so, but nothing seems to happen. No error messages, exceptions, or warnings of any kind to indicate the P2 touchpoint action failed...
What's the deal? Any ideas?
The import line should be org.eclipse.equinox.p2.touchpoint.eclipse.chmod (i.e. eclipse rather than natives), according to the following comment from org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.ChmodAction
// This basically a copy of the chmod action in the native touchpoint,
// only it provides #artifact support.
(For comparison, see the 'natives' chmod action)
I haven't checked about support for interpolating variables like 'os'.
In Eclipse 3.6 (don't know about previous versions), the variable to use instead of #artifact is ${artifact.location}. I had to dig into the p2 source code to find it, but using it in the targetDir parameter worked like a charm.
A couple of things I notice:
The "touchpoint.natives.chmod" action does not look like it supports #artifact. Try using org.eclipse.equinox.p2.touchpoint.eclipse.chmod instead.
os does not appear to be a parameter that is replaced at install time. Also, looking at the p2 source code, if "os" was a parameter, it seems the syntax would actually be ${os}. (See ParameterizedProvisioningAction#processVariables)
Note that the $version$ and `$qualifier$' parameters mentioned on the wiki are replaced at metadata generation/publishing time, not at install time.
So, I now know what to save from nightly builds. What about when I give something to customers?
For example, I probably want to save debugging information (e.g. PDB).
What else?
We use:
installers
binaries
pdbs
tag of source files
any other source files that might not be in svn - for example config.status
build log
You made me wonder if I'm missing anything important
Compiler and library version information (it may not be part of the build log). Somebody else mentioned the whole binaries.
Linker map file (it can sometimes help the remote debugging of a problem).
Unstripped executable (if on a Unix system you strip it the executable before making it available to clients).
For the SDK releases we do include:
PDB and XML for the libraries (packaged with the latest snapshot of the samples)
Packaged snapshot of sources from SVN (just because we can)
Link to the online documentation (docs are generated from the source automatically)
Trace messages don't necessarily need to be generated by default but the possibility to enable them can be very helpful.
Results and Information generated from ATPs that are run on the build (probably as part of the build process).