I'd like the date when the doc was built and a version number to be appended to the footer of all Sandcastle builds.
I use the SHFB gui to create the project file and then automate the build using TeamCity. Is there a way to get the build date and the TeamCity build # into the output?
Update:
I tried entering the footer text like Jeff suggested, but it does not add that to any page that I've seen.
Not sure about the TeamCity build number, but I was able to get the build date by adding this nonsense to the "Additional footer content" field in the Help File properties:
Documentation built {#BuildDate:yyyy\-MM\-dd}.
You can add replacement tags for the build date and time, like Jeff indicated. See
Customizing the build process for more options.
The documentation itself has no version, but you can display the Framework version, but that's probably not what you want.
Related
Is it possible to embed code coverage results (stored in SonarQube) into Github projects as one of those embeddable icon gadgets (not sure what their name is; it would be great if somebody to tell me that as well)...? I'm referring to the ones that show the build status, for example.
The only thing currently available is this under-development plugin, which was first discussed in this Google Group thread. Note that this project appears to be in its infancy.
EDIT
This plugin has since been released, and can be installed directly from the Update Center
EDIT 2
With SonarQube 7.1, badges become a native feature.
Using a plugin in no longer needed, as some new APIs are now added that will do what you want. You can use this snippet in your .md files:
[](https://{domain}/component_measures/metric/coverage/list?id={projectName})
Note that you have to replace parameters inside {}s with your own values. If you are using on-premise version, the domain will be your own domain and if you are using cloud version, it will be sonarcloud.io.
Also note that this will work only for public projects. For private ones, I could not find any solution.
And finally as a side note, the metric parameter takes some values other than coverage and gives other fantastic badges that you may find helpful:
bugs, code_smells, coverage, duplicated_lines_density, ncloc, sqale_rating, alert_status, reliability_rating, security_rating, sqale_index, vulnerabilities
I'm using modernizr in my ASP.net MVC application, and I'd like to use the inputformaction detect added in Modernizr v3. The latest version available on nuget is 2.8.3. So that means I need to add it independently from nuget. There doesn't seem to be any official full build.
The only thing I can find on their website is Download, which prompts me to create a custom build. If I select the features I'm using now, then I'll need to come back to this website every time I want a new detect, and remember all the options I chose last time. That's not really practical. I've also found that you can make custom builds using a node package and a .json definition file. I don't really feel like installing node just for this if I can avoid it.
All I want is a complete build of modernizr. Is there any way to do it other than writing a script to check all the checkboxes on their download page?
There is no such thing as a "complete" build of Modernizr. While it may be a minor inconvenience for you to rebuild when you need new detects, it can cost your users tons of time and money downloading and running javascript that is completely unneeded. There are a bunch of tools that will automate the custom build for you (bower, npm, grunt-modernizr, gulp-modernizr).
If you want a build that contains all of the options - which again is huge and horrible on perf, you can use https://modernizr.com/download?do_not_use_in_production
I have done a lot of googling but cant seem to find an exact solution to get the TeamCity build number into my AssemblyInfo files. Would appreciate a full solution for my requirements...
1 Get the build number into a Nant variable. I believe that this code will accomplish this..
PropertyGroup
Version$(BUILD_NUMBER)/Version
/PropertyGroup
(repoduced as best as possible in SO).
2 Now I need a way to update the revision component of my version numbers so I get something like 1.0.0.[build number].
3 Ideally I need the whole thing in a re-usable Nant target so that I can just call it passing in the path to the assembly info file that i want to update.
I would respectfully request that if you can help me that a full solution is posted here with explanation as opposed to links to other sites. Ive looked at a lot of online examples but cant seem to find one that fits what I need - therefore I request the knowledge of the omnipotent SO community!
Thanks in advance.
First of all, the code snippet in your question is MSBuild syntax, not NAnt. Assuming that NAnt is your build tool, there is a good explanation of how to update AssemblyInfo files with Cruise Control.NET here. That applies to TeamCity as well, just replace "CCNetLabel" with "build.number" and you will be fine.
To get a version number like 1.0.0.[build number], you can accomplish that in the TeamCity build configuration. On the first configuration page (General Settings). Change the "Build Number Format" from "{0}" to "1.0.0.{0}". See the online help for more options.
I know you asked for an NAnt reusable task, but this is too cool.
TeamCity has a new feature tailor-made for this purpose (AssemblyInfo Patcher).
You don't have to change anything in the (NAnt) build. Just add the "Additional Build Feature" for AssemblyInfo patcher in the Build Steps configuration for the build. You can also set the format for the version there.
I fired up Sandcastle Help File Builder today to generate documentation for my solution, which has around a dozen projects in it. Since I only want to generate documentation for, and run Sandcastle after, a Release build (which excludes all my test projects), I selected "Release" at the top of the window, just like in VS. Sandcastle appropriately looks for the gen'd XML files in my \bin\release subfolders for each project. However, it errors out when it cannot find DLL's for my test projects. It apparently sees those projects in the solution file, but doesn't realize I don't have builds for them in Release. I tried de-selecting them in the "API Filter" property, but this doesn't change anything.
How can I get Sandcastle to ignore those projects?
SHFB is nice, I've been using it recently. It turns out that there are a number of ways you can specify documentation sources. One way is by selecting the solution, as you seem to have done. You can also choose the project files for just the projects you are interested in documenting. You can even choose the resulting assemblies as sources.
Try changing the docu source from the solution to just the projects you are interested in. It doesn't quite answer your question, but it is a workaround, since you fairly likely have no need to document your test projects.
I am using Eclipse 3.4 (ganymede official, not the service pack).
I have an update site that organizes features into categories; everything looks great in the editor and in the XML.
Once the site is online, accessing it in the usual manner tells me that all the features are "uncategorized". I've tried from multiple computers running 3.4 and the same problem persists.
What is curious is that I used Eclipse 3.3, and it saw the categories well, though of course it wasn't able to instlal the plugins which are made from 3.4.
Am I doing something wrong or is this a known problem?
It appears to be a known problem, due to the new 'p2' provisioning system.
See this discussion, and this bug. What it seems to say is... "stay put until 3.5M3, and then try it again".
This solution works for me:
Use the PDE update site project to create the site.xml and build your plugins. Make sure you set the category here.
Delete the artifacts.xml and content.xml created by the update site build.
Use the P2 Metadata Generator to generate your artifacts and content files. I use the compress option so I'm getting jars.
The update site should include: the site.xml, content & artifacts jars, features and plugins folders.
If you follow this procedure, it will work just fine in Eclipse 3.3 and 3.4. Naturally, you should automate this process with Ant.
Important notes:
I never got the metadata generator Ant task to work, so I invoke it in its' Java form (the second example in the link above).
Make sure you clear the artifacts and content xmls before the generation
Inputs: site.xml and built plugins/features folders
Specify the metadataRepositoryName which is the update site title (shown to the user in some cases)
I'll do my best to blog about it soon...
Let me know if you have any questions.
What seems to work for me is to put the tag, defining the category in the site.xml, before the tag including the other category tag. If you add the category with eclipse's editor after adding the feature, it'll have messed that up...
A no-brainer for most..but it can be a problem for newbies on Eclipse update sites: be sure to add your feauture as a child under the category:
See http://ekkescorner.wordpress.com/2010/04/18/who-eats-the-categories-from-update-sites/