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
Related
I am using this code: https://github.com/pradeepramakrishna/Lightning-Experience/tree/master/aura-components to compile on my org.
I have got one components as eventLib.lib and interactive.js in eventLib folder. I have put this folder in c:MyDevOrg\force-app\main\default\aura folder in the local machine and tried to deploy in the org using VSCode but it didn't work.
I tried creating folder in the Files tab and added the interactive.js in the folder but that is also not seeming to work with the Aura components.
How can I deploy this lib into the org as it is being used in some Aura components.
We don't know what you're trying to achieve. You asked a very technical question to which the answer is "you're probably doing it wrong". Instead try to write what business functionality you are trying to achieve and you might get better answers.
You shouldn't have to import ui:eventLib. It's supposed to be part of core Salesforce's Aura components framework. But.
You've referenced a repo that wasn't updated in a while, no promises this still compiles / is best way to do X.
This repo seems to rely on open source Aura framework which is well... dead in the water.
You might be able to reuse something from this repo in your app using SF's built-in tags - but whole ui: library has been deprecated. Announced in Winter'20 = almost 2 years ago, finally dead in May 2021.
I don't think eventLib was ever exposed, might be something needed just in open source version which complicates the matter more. The answer would be to not work with the really "decompiled" tags but with their higher abstracted versions like ui:inputDate.
So, back to my question. What exactly are you trying to achieve.
You want to build something on pure SF platform (use pure Aura/LWC).
Want to have an app written in Angular, React etc, pure JS, connecting to SF data via API? (build it, upload as static resourcethen import using lightning:container)
want to prettify an existing Java/PHP/.NET app, make it look more Lightning-ish and embed it as iframe? (look into https://www.lightningdesignsystem.com/ and connected apps + "canvas")
want to expose piece of SF as reusable element that can be embedded in another website but could even be an Outlook plugin? (search for "lightning out")
want to look at modern equivalent of that old open source Aura repo and decide what to do next? Check https://lwc.dev/ out.
I looked through Github search docs for repos and code and I am not sure if it is possible.
I want to find popular open source projects that use a specific library to see how they handle particular design patterns. In my case, I am looking for popular Android projects that use Dagger 2.
I tried using a code search for com.google.dagger:dagger-android-processor: in .gradle which gives me 14k+ results for mostly unpopular projects. I would basically just want to sort by forks/stars, which is not an option as far as I can see.
If this is not possible with Github's search I am happy with any alternative.
For projects that use one of the package managers which is supported by GitHub (RubyGemsm, NPM, PyPI, Maven, Nuget), you can use ghtopdep
Related issue
A Code search would not allow sorting through repository stars (as stated here)
Maybe:
using a BigQuery would allow using that criteria (like this one)
or using GraphQL
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
We're looking into setting up a proper deployment process.
From what I've read there seems to be 4 methods of doing this.
Copy & Paste -- We don't want to do this
Using the "Package" mechanism built into the Salesforce Web Interface
Eclipse Force IDE "Deploy to Server" option
Ant Script (haven't tried this one yet)
Does anyone have advice on the limitation of the various methods .
Can you include everything in a Web Interface package?
We're looking to deploy the following items:
Apex Classes
Apex Triggers
WorkFlows
Email Templates
MailMerge Templates -- Can't seem to find these in Eclipse
Custom Fields
Page Layout
RecordTypes (can't seem to find these in Website or Eclipse)
PickList items?
SControls
I recommend the Force.com Migration Tool.
For reference:
Force.com Migration Tool Documentation
Migration Tool Guide
The Migration Tool allows you to use ant targets to move your metadata between salesforce.com organzations.
I can speak to this from recent painful experience.
Packaging: this is a very old method that predates the metadata API on which both Ant and Eclipse rely. In our experience, packaging's only benefit is in defining your project. If you're using Eclipse (which we do, and I recommend), you can define your project as being based on a particular package. As long as you remember to add new components to your package, your project hangs together
One thing that baffled us for a while, btw, are the many uses of package. We've noted the following:
Installed packages: these come in managed and unmanaged flavors and are really, in the words of a recent post on the SFDC boards, for ISVs to deploy their stuff into various unknown orgs "out there". Both managed and unmanaged packages have limitations that make them unsuitable and unneeded for deployment from development to production within an org, or in any case where you're doing custom development and don't intend to distribute code to a large anonymous base.
Non-installed packages: this is what you see when you click "Packages" in the web UI. These, that we sometimes call "development packages", seem to be just a convenient way to keep a project definition together.
Anyway, the conclusion I'm coming toward is that our team (custom development, not an ISV) does not need packages in any form.
The other forms of deployment, both Eclipse and Ant, rely on the Metadata API. In theory they are capable of exactly the same things. In reality they appear to be complementary. The Force.com migration tool, built into the Force.com IDE for Eclipse, makes deployment as easy as it can be (which is not very) and gives you a nice look at what it intends to deploy. On the other hand, we've seen Ant do some things the IDE could not. So it's probably worthwhile to learn both.
The process we're leaning toward is to keep all our projects in SVN, and use the SVN structure as the project definition (Eclipse will work with this and respect it). And we use Eclipse and sometimes Ant for migration. No apparent need for packages anywhere.
By the way, one more thing to be aware of -- not all components are migratable. Some things must be reconfigured by hand in the target environment. One example would be time-based workflows. Queues and Groups also need to behand-created, I think. Likewise the metadata API can't directly process field deletions so if you deleted a field in your source, you need to delete it by hand in the target. There are other cases as well.
Hope that's useful --
-- Steve Lane
As of Spring '09, mail merge templates are not supported in metadata but record types are. You will find record types as an XML element in the file for the object they belong to. Everything else on your list is supported with a small exception. Picklist values for standard fields cannot be edited in Spring '09. Stay tuned for news on Summer '09 feature announcements.
Update: Standard picklists on standard objects are now metadata exposed (as of API v16):
http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_picklist.htm
Otherwise, Steve Lane's response is pretty accurate. The advantage of using unmanaged packages (what Steve calls non-installed packages) is that when you add metadata to a package, the metadata it depends on will automatically be added. So it's easier to grab a full set of metadata containing all its dependencies. If you are repeatedly moving metadata from one org (sandbox) to another (production), Steve's approach is probably the best way to go and certainly the most common today. I frequently use unmanaged "developer" packages to move something I've developed in one org to another unrelated org. For my purpose, I like to have the package defined in the org as opposed to an Eclipse project / SVN. But that probably doesn't make sense if you are doing team development across many dev/sandbox orgs and are using SVN already.
Jesper
Another option is to use Change Sets if you want to move meta data from a sandbox to production.
There are currently some limitations on how change sets can be used:
Sending a change set between two organizations requires a deployment
connection. Currently, change sets can only be sent between
organizations that are affiliated with a production organization, for
example, a production organization and a sandbox, or two sandboxes
created from the same organization.
From the docs:
A package must be managed for it to be published publicly on AppExchange, and for it to support upgrades. An organization can create a single managed package that can be downloaded and installed by many different organizations. They differ from unmanaged packages in that some components are locked, allowing the managed package to be upgraded later. Unmanaged packages do not include locked components and cannot be upgraded. In addition, managed packages obfuscate certain components (like Apex) on subscribing organizations, so as to protect the intellectual property of the developer.
Advantage to managed package would be that it allows you to easily version and distribute things across multiple SFDC organizations.
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/