I use Phabricator for code review, but I can't delete a project once it was created. The only thing I can do is change the project status from active to archived. The other problem is Task, same to project, I can't delete a task once it was created.
Sometimes, people try to test Phabricator, maybe he or she creates some mock projects, it makes sense to delete them after testing.
It is possible, but only by using the command line administration tools.
Remove a task? ./phabricator/bin/remove destroy TASK-ID (ie: T1, T23)
Remove a project? ./phabricator/bin/remove destroy PHID-PROJ-6i6ofxwwz4xybdvg7oa5
Here is how to find the PHID: How do you find the PHID of a Phabricator object?
I've asked the Phabricator developer on IRC, user can't delete a project or task, this is designed on purpose, the only way to do it is archive project or close task. Refer to his reply as below:
We do not plan to add that feature, the feature would create a lot of problems. For example, some user could delete your stuff and you'd have no way to tell who did it. If a user closes or archives your stuff, it says "alincoln closed this task." Another problem is that a project may have thousands or millions of objects attached to it. If you delete the project, either all of those objects become attached to an empty/invalid project, or we need to run some sort of background cleanup process. And there's no way to undo deletion, so users who make mistakes can't recover from it.
Related
I've already deleted a local branch without deleting its upstream branch on a GitHub.
Is there a way to delete the remote branch in a GitAhead?
In Sourcetree you just right click on the remote branch and choose delete.
Unfortunately no, GitAhead doesn't have an easy way to push a delete except for the little convenience checkmark when you delete the local branch. You would have to resort to the command line or doing it on your remote host.
This is a major design flaw in Git (in my opinion). The branching concept in mercurial is much more sane (no detached heads, named branches, no ability to delete branches - at least not if it was published once).
think about it: it is a versioning control system. What you want is to preserve and document development history. Someone has created and published a branch for purpose. So even if git allows manipulation of the repository much more than mercurial (and here most abilities are disabled by default!), just do not use it. leave the branch! Its OK. Its the way it should be. Anyway, as git is lean here, its just a pointer (not a real named branch like in hg), it does not take much space.
I've come across this really strange scenario that I'm hoping that someone else has come across (best scenario) or perhaps that someone with a lot of CRM experience can perhaps point me in the direction of where to look for a possible solution. I cant seem to find anything online thats close to this issue.
We have 4 environments : DEV, DEV-IST, UAT and PreProd. We progress CRM deployments in the following order: DEV -> DEV-IST -> UAT -> PreProd. We havent gone live with our development and hence I've not included Production.
We progress CRM Deployments using the following steps.
Go to DEV.
Export any unmanaged solutions to managed solutions. We then copy those managed solutions into the 'PkgFolder' of the package deployer.
We then take a backup of the DEV-IST CRM (Organisation A) database and restore it to the DEV database server as (Organisation A). We then run the package deployer on Organisation A so that it now has all the changes that we'd made in development. Before we do anything further, we login to Organisation A and go to the following screen: Home -> Settings -> Customisations -> Customize the System. I can see under the Entities node all the custom entities.
I now backup Organisation A (which now includes my Dev updates) and copy the backup file to the DEV-IST database server.
I first go to Deployment Manager on DEV-IST and disable the organisation and then delete it.
Now I go to the SQL Database for DEV-IST and restore the backup from step 4 above and overwrite the Organisation A database.
I go back into Deployment Manager on DEV-IST and use the import organisation to reimport the organisation A and thus now have a organisation A now updated with my dev updates. The above process ensures that we deploy updates with very little downtime.
However, my issue is that after step 7 when I login to the organisation and go to Home -> Settings -> Customisations -> Customize the System... I cant see any of the custom entities!
Any ideas what might be causing this. Strangely I've noticed that I cant see custom entities in DEV-IST and PreProd but can see them in the DEV and UAT environments.
PS. I've already tried clicking the 'Publish all customizations' and it didnt have any effect.
Your deployment process is really complicated and I can't see any reason why are you doing customization transfer in so complex way. You should be simply transferring Solutions with your customizations from DEV environment to DEV-IST environment and then to UAT and PreProd.
Backing up your database on one environment and restoring it on another is for sure not faster way (because you stated that such process gives you short downtime of environment).
Also if you insist of doing deployment this way, you should not only remove your organization from Deployment Manager, but also database from the server (and restore the backed up database).
If you are simply customizing CRM for your client/company, you should not use managed solutions. Managed solutions are used to share some reusable customizations that you want to share or sell to the others. Please read this great post by Shan McArthur, that will make you better understand the problem:
https://community.adxstudio.com/blogs/shan/2014-01-17-converting-crm-solutions-from-managed-to-unmanaged/
And if you must use managed solutions - you should only do that on your final PROD environment, not on your staging environments (where you should have full control over customizations to provide hotfixes)
EDIT:
I would add it as a comment, but I cannot comment yet, so I have to edit my response instead. I replicated your process and I can see all the entities on all environments, so there must be something specific that you are doing which is causing this behaviour. Have you checked that after you restored the database all the custom entities exist in your restored database? (every entity is a separate table which has the same name as the entity). Also I would compare all the solution-related tables in database where you can see the custom entities vs the database where you cannot see custom entities (so that would be tables SolutionBase, SolutionComponenBase, MetadataSchema.Entity and all other MetadataSchema.* tables). Last experiment you can do is to save somewhere the db where you cannot see the custom entities, remove the managed solution, import the managed solution (standard way) and check if the entities are there. I bet that they would be there, so the next step would be to again compare the databases (all the metadata/solution tables) with some red-gate comparison tool, maybe that would point you to the right direction.
Basically the metadata in CRM is built this way - take everything from the default solution, then apply all the managed solutions in order they were imported and build the resulting metadata. Your case looks like CRM somehow "forgot" to apply the managed solutions over the default solution ( I believe that this might be an unknown bug of deployment manager, that should set something during organization import). I hope that you will discover this when you compare your database data between environments.
I understand that this is not a valid response and normally I would not write it as an answer but as a comment, but I cannot comment yet, unfortunately :(
I finally got to the bottom of this issue and thought I'd update it here for anyone else who comes along with the same issue. 'Someone' put a registry edit on the CRM server to get CRM to return only the top 250 records on any query. As custom entities are above this number, they weren't being shown. I've since reverted this change and I'm able to see the custom entities now.
Sorry, relative novice, but I have not been able to find specific example to address this. Working on a service that is using Git to store configuration documents. They would be worked on in branches until "published".
I've been able to do all the querying and fetching of documents from any branch in the local repository where the service would run, without having to "checkout" branch into working directory. I would like to do the same with a save operation.
I've found examples of using ObjectInserter, TreeFormatter and CommitBuilder to do this, but no explicit/explained example of doing this to specific branch that would produce the same results as switching, adding and committing with porcelain API.
I've played around with RefUpdate after the commit, and think I'm on the right track, but could use some help.
Thanks in advance
I'd like to make it so that a commit to our BitBucket repo (or S3 Bucket) automatically deploys code (using CodeDeploy) to our EC2 instances. I'm not clear what to use for the 'source' and 'destination' entry under the 'files' section in the appspec.yml file and also I am not cleared what to mention in BeforeInstall and AfterInstall under 'Hooks' section. I've found some examples on Google and AWs documentation but I am confused what to mention in above fields. The more I am exploring more I am getting confused.
Consider I am new to AWS Code Deploy.
Also it will be very helpful if someone can provide me step y step link how to configure and how to automate the CodeDeploy.
I was wondering if someone could help me out?
Thanks in advance for your help!
Thanks for using CodeDeploy. For new users, I'd like to recommend the following things to do:
Try to run First Run Wizard on console, it will should you the general process how the deployment goes. It also provide a default deployment bundle, also an appspec file included.
Once you want to try a deployment yourself, the Get Started doc is a great place to help you with some pre-requiste settings like IAM role
Then probably try some tutorials for a sample app too, which gives you some idea about deployment groups, deployment configuration, revision and so on.
The next step should be create a bundle for your own use cases, Appspec file doc would be a great place to refer. And for your concerns about BeforeInstall and AfterInstall, if your application doesn't need to do anything, the lifecycle events can be left as empty. BeforeInstall can be used to for for preinstall tasks, such as decrypting files and creating a backup of the current version, while AfterInstall can be used for tasks such as configuring your application or changing file permissions.
Now it comes to the fun part! This blog talks about details about how to integrate with Github(similar for Bitbucket). It's a little long, but really useful, and it also includes how to do automatically deployment once there is a new pushed commit. Currently Jenkins and CodePipline are really popular for auto-triggered deplyoments, but there are always a lot of other ways can achieve the same purpose like Lamda and so on
I'm trying to set up a deployment chain for some of our ASP.NET applications. The tool of choice is Web Deploy (msdeploy) - for now. Unfortunately I'm stuck on a problem.
A high level overview of the chain is thus:
Web developer creates the code and checks it in SVN;
Buildserver sees the update and builds the msdeploy .zip package of the website;
The .zip package is automatically put inside our installer and sent to various clients;
The clients run the installer on their webserver(-s);
The installer uses msdeploy internally to deploy the .zip package and create a new website or upgrade an existing one.
Msdeploy makes it easy to deploy a new instance, but I'm stumped about how to perform an "upgrade" install. The main problem is the web.config file. Each client will most certainly have made some customizations there to suit their specific environment. The installer itself offers to set some more critical parameters at the first-time installation (achieved by msdeploy's parameter mechanism), but they can do others by hand.
On the other hand, we developers also occasionally make changes to web.config, adding some new settings or removing obsolete ones. So I can't just tell msdeploy to ignore the file entirely. I need some kind of advanced XML modification mechanism. It could be a script that the developers maintain, but then it needs to be run ONLY at upgrades, not new installs.
I've no idea how to accomplish this.
Besides that, sometimes there's also some completely weird upgrade logic. For example, the application comes with our company logo, but some clients have replaced that .png file to show their own logo. Recently we needed to update the logo - but only for clients that hadn't replaced it with their own.
Similarly, there might be some cache folders that might need to be cleaned at SOME upgrades but not at others. Or folders with user content that may not be touched (but come with default content at the initial installation). Etc.
How do you normally achieve this dual behavior for msdeploy packages? Do I really need to create 2 distinct packages for every application?
Suggestion from personal experience:
Isolate customisations
Your customers should have the ability to customise their set up and the best way is to provide them with something like an override file. That way you install the new package and follow by superimposing your customer's customisations on top of your standard setup. If its a brand new install then there will be nothing to superimpose.
> top-level --
> standard files |
images | This will never be touched or changed by customer
settings.txt |
__
> customer files --
images | Customer hacks this to their heart's content
settings.txt_override |
--
Yes, this does mean that some kind of merging process needs to happen and there needs to be some script that does that but this approach has several advantages.
For settings that suddenly become redundant just issue a warning to that effect
If a customer has their own logo provide the ability to specify this in the override file
The message is clear to customers. Stay off standard files.
If customers request more customisable settings then write the default if it does not exist into the override file during upgrades.
Vilx, in answer to your question, the logic for knowing whether it is an upgrade or not must be contained in the script itself.
To run an upgrade script before installation
msdeploy -verb:sync -source:contentPath="C:\Test1" -dest:contentPath="C:\Test2" -preSync:runcommand="c:\UpgradeScript.bat"
Or to run an upgrade script after installation
msdeploy -verb:sync -source:contentPath="C:\Test1" -dest:contentPath="C:\Test2" -postSync:runcommand="c:\UpgradeScript.bat"
More info here
As to how you know its an upgrade your script could check for a text file called "version.txt" and if it exists the upgrade bat script will run. Version to be contained within the text file. Bit basic but it should work.
This also has the added advantage of giving you the ability of more elegantly merging customer's custom settings between versions as you know which properties could be overriden for that particular version.
There are some general suggestions (not specific to msdeploy), but I hope that helps:
I think you'll need to provide several installers anyway: for the initial setup and for each version-to-version upgrade.
I would suggest to let your clients to merge the config files themselves. You could just provide them either detailed desciption of waht was added/changed/removed, and/or include the utility that simplifies the merge. Maybe this and this links will give you some pointers.
as for merging the replaced logos, other client's customization, I think the best approach would be to support branding your application. I mean - move all branding details to the place where your new/upgrade installers won't touch that.
as for the rest of the adjustments made by your clients, they do that on their own risk, so the only help you could provide them is to include the detailed list of changes (maybe even the list of changed files since the previous version) and the How-To article about merging the sources with tools like Araxis Merge or similar
Or.. you could create a utility and include it to the installer, which will try to do all the tricky merging stuff on client's machine. I would not recommend this way as it requires a lot of efforts/resources to maintain.
One more thing: you could focus on backup-ing the previous client copy before upgrade. So even client will have troubles with upgrading - that will be always possible to roll back. The only thing here for you is to provide a good feedback channel which your clients can use to shoot their troubles. This feedback will allow you to figure out what the troubles your clients have and how to make their upgrade process more comfortable.
I would build on what the above have said, but I would do it with transformations, and strict documentation about who configures what. The way you have it now relies on customer intervention against a config that is mission critical to the app deploy process.
Create three config file areas. One for development, one for the "production generic" build, and one that is an empty template for the customer to edit.
The development instance should be self explanatory. This is the transform that takes the production generic template and creates a web config for your development server. (it sounds like you are shooting for a CI type process here)
The "production generic" transform should set the app up for a hypothetically perfect instance of the app. This is what the install would look like if the architect had his way.
The customer transform is used by the customers to set up the web config as required to meet their own needs. Write some documentation and see what happens. Edit the docs as you help customers through the process.
It that what you were looking for? Thoughts?