I'm trying to configure a phabricator instance, and I find that change the arcanist default template when we use arc diff can be very useful for the team.
Actually the template contains this text:
<<Replace this line with your Revision Title>>
Summary:
Test Plan:
Reviewers:
Subscribers:
# Tip: Write "Fixes T123" in your summary to automatically close the
# corresponding task when this change lands.
# NEW DIFFERENTIAL REVISION
# Describe the changes in this new revision.
#
# arc could not identify any existing revision in your working copy.
# If you intended to update an existing revision, use:
#
# $ arc diff --update <revision>
I'm googling to find any way to change this default template, but I can't find it...
There is any way to "personalize" this template?
As reported in Phabricator Task T12276 by a question from user #milianw, actually it seems there is not the ability to customize the commit message.
This is the official reason:
Please keep in mind Phabricator is an enterprise tool, and
the majority of installs (99%) are businesses who rely on the
accountability we've built into the software.
― chad, Feb 18 2017, 11:55 PM
Anyway I tried to explore the class DifferentialCommitMessageField and I've found this method producing the list of all available fields:
final public static function getAllFields() {
return id(new PhutilClassMapQuery())
->setAncestorClass(__CLASS__)
->setUniqueMethod('getCommitMessageFieldKey')
->setSortMethod('getFieldOrder')
->execute();
}
And look at all the class that are inheriting DifferentialCommitMessageField. Some of them:
DifferentialTagsCommitMessageField
DifferentialSubscribersCommitMessageField
DifferentialAuditorsCommitMessageField
DifferentialReviewedByCommitMessageField
DifferentialTestPlanCommitMessageField
DifferentialTitleCommitMessageField
DifferentialSummaryCommitMessageField
...
So maybe you can customize a field changing the related class. You can change some default values, or you can try disabling a field declaring this method in one of these classes:
/**
* This method is inherited from DifferentialCommitMessageField
*
* #override
*/
public function isFieldEnabled() {
// return true;
return false
}
In short you can try to extend Phabricator to do it. Currently this feature is not a priority for their general enterprise use cases.
Anyway, do not forgot that Phabricator is a Free/Libre and Open Source software. You have all the rights to play with the code and make some improvements. If you are really interested in this feature and you have the possibility to add this customization feature, some users may be interested in your patch, so you may also consider to propose your changes to upstream, if it works and does not introduce regressions.
Related
Lets say I have to patch few files of the core, example:
src/server/game/Handlers/MiscHandler.cpp
+code line 1
+code line 2
+code line 3
src/server/game/Handlers/ChatHandler.cpp
+code line 1
+code line 2
+code line 3
Can I implement these patches into a module? If it's possible, could you please post an example, how can be done, so I can get the idea?
Thank you!
Just to mention that I've already seen the module skeleton repo, I can see that there is a src/ folder with two files - loader.h and Player.cpp, but other than than, not sure how proceed.
Yes, it's possible. When writing a module you use the existing hooks that are available in AzerothCore. If you need a hook that is not existing yet, you can simply create it and send a PR to AzerothCore.
How to add new hooks: a practical example
I needed to create a very simple module that sends the player a warning whenever he/she leaves the BG queue after being invited to join.
This is the code of my module, very basic:
void OnBattlegroundDesertion(Player* player, const BattlegroundDesertionType type) override
{
if (sConfigMgr->GetBoolDefault(DESERTION_ENABLED_CONFIG, false))
{
switch (type)
{
case BG_DESERTION_TYPE_LEAVE_QUEUE:
case BG_DESERTION_TYPE_NO_ENTER_BUTTON:
ChatHandler(player->GetSession()).PSendSysMessage("%s", sConfigMgr->GetStringDefault(WARNING_TEXT_CONFIG, "").c_str());
break;
default:
break;
}
}
}
the full source code of the module is available here: https://github.com/azerothcore/mod-desertion-warnings
Looks very easy right? Especially if you had that OnBattlegroundDesertion method that gave me what I needed (the Player and the BattlegroundDesertionType).
There was only one problem... the hook OnBattlegroundDesertion didn't exist before!
But it's ok, I just had to implement it in the core, and this is the PR that does the job:
https://github.com/azerothcore/azerothcore-wotlk/pull/4619
As you can see it's just a matter of creating the method in ScriptMgr.h and ScriptMgr.cpp (the same way other hook-methods are created) and then call it around the core whenever I needed it.
I am new in wordpress developement, I have my own custom wordpress plugin which allows admin to click multiple author and save all meta tag in the database on post. It works fine. But i want to generate test case for that. I installed phpunit but I don't know how to write test case.
public function testOne()
{
$this->factory->post->create();
}
I tried this but not understand how it works.
It's not difficult but it's definitely not trivial. You'll need to set up a test Wordpress database just for PHPUnit to run tests
I found these guides really useful:
https://codesymphony.co/writing-wordpress-plugin-unit-tests/
https://engineering.hmn.md/guides/writing-code/writing-tests/
In order to get the files that PHPUnit needs to set up a WordPress testing environment, I had to get a new WordPress directory:
https://core.trac.wordpress.org/browser/trunk?order=name
And I was stymied for a while by MySQLi failing as soon as my unit tests started, but fixed it with a setting change after reading this:
https://core.trac.wordpress.org/ticket/39327
And now I can actually fix the bugs that the Unit Testing found :).
First of all, you should use the WordPress modules for Codeception, which includes the PHPunit WPTestCase and many other tools.
There are two basic approaches to testing something like this in WordPress:
You can test it with a browser. This is called an acceptance test. You list all the actions that prove the concept you are testing, and you run a browser [or browser simulator] to do the task step by step. You can look into the database for the artifacts you expect to see as a result, and prove it happens correctly. In your case, you might want to setup some posts, click the multiple authors, and then check the database for the meta tags you expect. It might look something like:
$I = /*am a */ new AcceptanceTester($scenario);
$I->loginAsAdmin();
$I->amOnPage("/wp-admin/post-new.php");
$I->fillField('#content', "lorum ipsum");
$I->click('#publish');
The other approach is to encapsulate your action in an OOP class, and test it using the WPUnit test tools. Codeception uses the same PHPUnit library the WordPress core teams uses, plus a bunch of other tools. The WPUnit approach loads a database into memory, and can do things like setup dummy posts for your plugin to work on. So in your case, you might have a class:
class SystemActionSaveMetaTags{
public function doSaveMetaTags()
}
You might have a test called
itShouldSaveMetaTags(){
$id = wp_insert_post();
$SystemActionSaveMetaTags = new SystemActionSaveMetaTags;
$SystemActionSaveMetaTags->doSaveMetaTags($id);
$this->assertTrue($this->checkForCorrectMetaTags($id));
}
Here is a tutorial on the subject, as it relates to WordPress:
https://wp-bdd.com/wp-codeception-tutorial/
While trying to understand why my view is not displaying, I noticed the following error in the log:
I do not think it is possible to delete the URL alias from Taxonomy terms. At least I cannot find how to do this.
I have, however gone through ALL of my taxonomy terms and removed the value for this field.
I have also done the following with Pathauto:
Also, I have checked the report located at admin/reports/fields and can confirm that there are no entities that use a field called URL alias.
I have gone through each content item and ensured that they have the following setting (anyone know how to do this in bulk?). But still the error remains.
Anyone know then how I can fix this strange error?
Im not entirely sure what this command does, but it fixed the error:
drush updb --entity-updates
Since https://www.drupal.org/node/2554097, the magic in Drupal core that took care of updating entity definitions is gone. drush updb --entiy-updates is an alternative to this but it is not a silver bullet. Instead, it is safer to write database updates.
Taking the screenshot at the top as an example, here is a database update that would delete those two field definitions:
/**
* Fix taxonomy and node field definitions.
*
*/
function mymodule_update_8101() {
$manager = \Drupal::entityDefinitionUpdateManager();
if ($field = $manager->getFieldStorageDefinition('alias', 'node')) {
$manager->uninstallFieldStorageDefinition($field);
}
if ($field = $manager->getFieldStorageDefinition('alias', 'term')) {
$manager->uninstallFieldStorageDefinition($field);
}
}
Have a look at the rest of the available methods at https://www.drupal.org/node/2554097 in order to write database updates for each scenario.
use the entity_update module or the devel_entity_updates module
What are the strategies to embed a unique version number in a Spring application?
I've got an app using Spring Boot and Spring Web.
Its matured enough that I want to version it and see it displayed on screen at run time.
I believe what you are looking for is generating this version number during build time (Usually by build tools like Ant, Maven or Gradle) as part of their build task chain.
I believe a quite common approach is to either put the version number into the Manifest.mf of the produced JAR and then read it, or create a file that is part of the produced JAR that can be read by your application.
Another solution would be just using Spring Boot's banner customization options described here: http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-spring-application.html#boot-features-banner
However, this will only allow you to change spring-boot banner.
I also believe that Spring Boot exposes product version that is set in Manifest.MF of your application. To achieve this you will need to make sure Implementation-Version attribute of the manifest is set.
Custom solution for access anywhere in the code
Lets assume you would like to have a version.properties file in your src/main/resources that contains your version information. It will contain placeholders instead of actual values so that these placeholders can be expanded during build time.
version=${prodVersion}
build=${prodBuild}
timestamp=${buildTimestamp}
Now that you have a file like this you need to fill it with actual data. I use Gradle so there I would make sure that processResources task which is automatically running for builds is expanding resources. Something like this should do the trick in the build.gradle file for Git-based code:
import org.codehaus.groovy.runtime.*
import org.eclipse.jgit.api.*
def getGitBranchCommit() {
try {
def git = Git.open(project.file(project.getRootProject().getProjectDir()));
def repo = git.getRepository();
def id = repo.resolve(repo.getFullBranch());
return id.abbreviate(7).name()
} catch (IOException ex) {
return "UNKNOWN"
}
}
processResources {
filesMatching("**/version.properties") {
expand (
"prodVersion": version,
"prodBuild": getGitBranchCommit(),
"buildTimestamp": DateGroovyMethods.format(new Date(), 'yyyy-MM-dd HH:mm')
)
}
}
processResources.outputs.upToDateWhen{ false }
In the code about the following is happening:
We defined a function that can take a build number out of the VCS
(in this case Git). The commit hash is limited to 7 characters.
We configure the processResources task to process
version.properties file and fill it with our variables.
prodVersion is taken from Gradle project version. It's usually set
as version in gradle.properties file (part of the general build
setup).
As a last step we ensure that it's always updated (Gradle
has some mechanics to detect if files ened to be processed
Considering you are on SVN, you will need to have a getSvnBranchCommit() method instead. You could for instance use SVNKit or similar for this.
The last thing that is missing now is reading of the file for use in your application.
This could be achieved by simply reading a classpath resource and parsing it into java.util.Properties. You could take it one step further and for instance create accessor methods specifically for each field, e.g getVersion(), getBuild(), etc.
Hope this helps a bit (even though may not be 100% applicable straight off)
Maven can be used to track the version number, e.g.:
<!-- pom.xml -->
<version>2.0.3</version>
Spring Boot can refer to the version, and expose it via REST using Actuator:
# application.properties
endpoints.info.enabled=true
info.app.version=#project.version#
Then use Ajax to render the version in the browser, for example using Polymer iron-ajax:
<!-- about-page.html -->
<iron-ajax auto url="/info" last-response="{{info}}"></iron-ajax>
Application version is: [[info.app.version]]
This will then show in the browser as:
Application version is: 2.0.3
I'm sure you've probably figured something out since this is an older question, but here's what I just did and it looks good. (Getting it into the banner requires you to duplicate a lot).
I'd recommend switching to git (it's a great SVN client too), and then using this in your build.gradle:
// https://github.com/n0mer/gradle-git-properties
plugins {
id "com.gorylenko.gradle-git-properties" version "1.4.17"
}
// http://docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html
springBoot {
buildInfo() // create META-INF/build-info.properties
}
bootRun.dependsOn = [assemble]
And this in your SpringBoot application:
#Resource
GitProperties props;
#Resource
BuildProperties props2;
Or this way to expose those properties into the standard spring environment:
#SpringBootApplication
#PropertySources({
#PropertySource("classpath:git.properties"),
#PropertySource("classpath:META-INF/build-info.properties")
})
public class MySpringBootApplication {
and then referencing the individual properties as needed.
#Value("${git.branch}")
String gitBranch;
#Value("${build.time}")
String buildTime;
Is there any way of preventing users being dropped when publishing a DACPAC using SqlPackage.exe, other than changing the setting below, which prevents all objects from being dropped if they're not in the DACPAC.
<DropObjectsNotInSource>True</DropObjectsNotInSource>
We deploy to a number of environments, each with different users. Current workarounds are to either:
Script the users for each environment to recreate them after deploying
Use /Action:Script and manually change the deployment script.
Neither of these are ideal though...
Use SqlPackage.exe parameters (since February 2015 release: New Advanced Publish Options to Specify Object Types to Exclude or Not Drop):
Here's the actual parameters we use in our deployment:
/p:DropObjectsNotInSource=True
/p:ExcludeObjectTypes=Users;Logins;RoleMembership;Permissions
The first line cleans all, but the next line further refines what not to drop. This combination proved the most effective with us to drop all unnecessary objects, yet retain the login mappings as they were.
Detailed documentation of all the parameters and their possible values can be found from MSDN - SqlPackage.exe
I ran into the same issue and used Pre/Post deployment scripts to reinsert users, permissions, roles, etc like the suggested blog post. However this became unmaintainable in the long run (users unable to authenticate during deployment, if the deployment fails permissions are not restored, security changes require going through source control and re-deployment).
Recently, I reevaluated the problem as we were migrating our deployment platform. With the DacFx API (and bug fixes) released, I was able to extend the deployment process in SSDT by creating a DeploymentPlanModifier. They provide an example for filtering objects on creation, with simple modifications I filter any drops for permission based object types (using /p:AdditionalDeploymentContributors argument).
[ExportDeploymentPlanModifier( UserMappingFilter.PlanFiltererContributorId, "1.0.0.0" )]
public class UserMappingFilter : DeploymentPlanModifier
{
public const string PlanFiltererContributorId = "Dac.UserMappingFilter";
protected override void OnExecute( DeploymentPlanContributorContext context )
{
DeploymentStep next = context.PlanHandle.Head;
while( next != null )
{
DeploymentStep current = next;
next = current.Next;
DropElementStep dropStep = current as DropElementStep;
if( dropStep != null && ShouldFilter( dropStep ) )
{
base.Remove( context.PlanHandle, dropStep );
}
}
}
private bool ShouldFilter( DropElementStep createStep )
{
TSqlObject target = createStep.TargetElement;
if( target.ObjectType.Name == "RoleMembership" || target.ObjectType.Name == "User" || target.ObjectType.Name == "Role" )
{
return true;
}
return false;
}
}
We handle this in post-deploy scripts. It's a bit harder to set up, but once set up allows you to configure a slightly different script for each environment. We use this in conjunction with Publish Profiles with a different profile per environment. Basically, you use Powershell to generate a bunch of scripts for users and permissions, add those scripts to your project(s), and then Include the files in the project. Add what is referred to in the blog post as "SecurityAdditionsWrapper.sql" to your post-deploy script, and you should be good. Just remove the other security from your project to ensure that it's set correctly.
http://schottsql.blogspot.com/2013/05/ssdt-setting-different-permissions-per.html
There are also options in SSDT for:
"Drop Permissions not in source" - False
"Drop role members not defined in source" - False
"Ignore permissions" - True
"Ignore role membership" - True
We use those, but if you need better control over your users/permissions by environment, I'd strongly recommend checking out that blog post. (With thanks to Jamie Thomson for the original idea.)