Manually delete workflows from YouTrack server - workflow

For whatever range of poor reasons...a user schedule workflow has been uploaded to our YouTrack server instance that now automatically generates seemingly hundreds of new issues a minute.
As you might imagine, the web server is totally unresponsive, meaning that we cannot disable or detach the workflow from the project. The workflow editor's attempts to remove the workflow fail with connection timeouts.
How can the workflow be disabled without accessing the usual admin pages? Is there a workflow file somewhere in the server's directory that can be deleted (I can't find one) while the service is stopped? Is there a "run in safe-mode" option for YouTrack?
We're running YouTrack 5 fwiw.
Thanks in advance.

In YouTrack 6.0 we've implemented special Java start parameter (-Djetbrains.youtrack.workflow.detachModified=true), it will work starting from next bug fix release.
This option will detach all the workflows from all the projects on start, except the unmodified supplied ones.
Please, consider https://youtrack.jetbrains.com/issue/JT-27785, the Fix version of this issue will be changes as soon as we release next bug fix.

Workflows are stored inside YT db, so the best variant for you is to contact YT support. It'll be able to modify the db.

Related

I failed in IONOS deploy several times

I build several websites using react and have deployed them automatically to IONOS using Github workflow so far.
But since a few days ago, I haven't been able to deploy them because of this error;
Trigger creation of temporary user
Failed to create temporary user
I am not sure why this happens and very thankful if anybody could help me with the solution to this issue.
Shouldn't happen. It's our fault. I'm working for IONOS and I'm directly involved in Deploy Now.
So far we use a temporary FTP user for the deployment. Currently we're working on an extended worklflow. Besides we will replace the FTP user and switch to SSH. This will hopefully end such hiccups.
As workaround you can manually re-trigger your GitHub Action.
Sorry for the inconvenience.

unable to delete build completely

I have manually deleted a CI build that uses the MS Hosted ubuntu Agent as there was no Cancel option that was showing up. The elapsed time I think shows the build was deleted, but I see that the Hosted Agent continues to show that the build is in progress.
This is the first time I am running in to this situation. What is the best way to abort this build. I tried using the APIs here and here but that does not seem to help
Thanks
After investigation, there is a recently event of availability degradation of Azure DevOps, which affected these services and it has been resolved now.
If you want to know more information, please click here: https://status.dev.azure.com/_history.
Please check that your Cancel option is back to normal.

is there a deploy tool (or set of tools) that supports rollback of a deployment?

I'm learning FluentMigrator. The thing that I like about FM is that it supports the idea of Forward and Back for migrations (aka Up/Down). I'm finding that it's not ideal about this; there are some holes. Still, it's good.
This leads me to wonder if there are any deployment tools (nant, msbuild or other) that support this idea of rolling forward and back. The scenario that I'm using it in is the deployment of a web app with a related database.
Ideally I'd like to set up my deployment so that, should any part of it fail, it will revert to the previous known working configuration. With FM, this is pretty easy to do (but there are rough spots), so that covers the db. How about the files that make up the web app? Do any deploy tools have support for this?
Deploying to a Windows Server. Assume that I can't make any changes to the server.
I don't know of any Microsoft-centric, automated provisioning/deployment tools like Capistrano. Here are some tools I've heard of, but never used:
MSDeploy, for deploying web application.
Microsoft Deployment Services, for managing operating system configuration
Microsoft's System Center Configuration Manager
BladeLogic
HP's Operations Center
Up until about three months ago, we did our deployment/provisioning using custom MSBuild scripts. After a server is provisioned, deploys happen automatically using Robocopy to copy files to a share on the application server, updating changed application binaries and markup files. We've never had a need to rollback any of our deployments, but since our scripts are custom, we could write the logic if we needed to.
MSBuild is a terrible deployment/provisioning language. For the past three months, we've been writing all new scripts in, and porting existing ones to, PowerShell. It is wonderful. With version 2, there is support for running commands on remote servers, like SSH. We haven't used that functionality yet, but I'm looking forward to pushing setup scripts to remote server to provision and deploy at the same time.
We have been using Git to do our deploys for the last 6 months.
Here is the whole process:
CI server build the project
CI server checks it in to a local git repository
CI server pushes the changes to the centralised git repository
User creates an empty repository on the live server
User adds the central git repository to the remotes
User pulls the latest version over https (no need to open any ports)
It is a lot to setup in the beginning but once setup it works great. Deploys take seconds as only changed files get copied.
Another great thing about this method is that git keeps history of changes so rolling back is pretty simple. You can also roll back a few revisions and it's done straight on the live server. If something goes wrong reverting is super fast.
Also you can save some time if you use a hosted git service (github) for your central repository.
This is a very brief description but I can give you more info if you want.
Of course! My favorite is Capistrano. This was originally built for Ruby but I've found that it works just as well for other languages.
https://github.com/capistrano/capistrano

What is a typical workflow to put my local MVC3 project on to a "live server"?

I develop on my local machine with VS2010 and SQL Server. Naturally, my web.config points to my local SQL Server and I can debug/development and all is well. Unfortunately, I am not entirely sure on how to go about deploying my code to a live server.
Currently, my live server consists of a virtual machine (my site is accessible from the internet). When I'm ready to put my changes on the live server I publish my app (right click on solution explorer -> publish). Then I go to the directory it publishes to and dump all the files into a network share that goes to my site on the live server. On the initial copy over, I have to manually edit the web.config so that the connection string points to the SQL Server on the live server instead of my local machine. So this is my first stumbling block. How can I easily manage development settings and "live" settings in the web.config?
Now, I also use version control (Kiln). Can I possibly tag a changeset and have it automatically deployed to my live server somehow? Let's say someone submits a bug and I fix it. I push my changeset and now Kiln has the latest version of my code with the bug fix. What's the best way to get these changes on to a live server?
I'm unable to find any documentation that covers the entire workflow but I feel like there has go to be a better way. Surely, something like this can be accomplished without having to manually edit the web.config everytime I publish and pray to the computer Gods that I didn't miss something in the connection string.
It's just me so I have complete control over all of my environments, including the server and what's accessible via the internet, and anything is possible if only I knew what to do.
How can I easily manage development settings and "live" settings in the web.config?
Re: With VS 2010 web.config transformations, it is quite easy. Please take a look at this blog:
http://blogs.msdn.com/b/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx
For VS 2008 or older, we used to have multiple config file based on environment and we used to create Debug/Release/DevTest/UAT/PROD release configuration and then in the post build event we used to replace the web.config with the release configuration based config. For example - if you build the project using "Prod" release configuration then we copy the PROD web.config to the publishing folder.
Now, I also use version control (Kiln).
Can I possibly tag a changeset and have it automatically deployed to my live server somehow? Let's say someone submits a bug and I fix it. I push my changeset and now Kiln has the latest version of my code with the bug fix. What's the best way to get these changes on to a live server?
Re: Source control and publishing to live server are two different things. The first question you are asking here related to how you manage multiple releases and have control over bug fixes for each release. The way I would do it is I will have PROD branch in my source control which will be the first release and for every major release I will sub branch it to have more control over e-fixes.
For the other question about how to get it to live server, it depends on your environment. We do it differently based on how customer environment is setup. If they have given us the FTP, we use that or otherwise we package the application into an MSI and then deploy it to UAT.. Until UAT signoff is done, we keep on updating the MSI. Once signoff received, the MSI goes to PROD.
Hope this helps.

Deploy with rsync(or svn, git, cvs) and ignore inconsistent state during deployment?

We are currently talking about deploying a website via rsync. However, during rsyncing the application is left in an inconsistent state, as some files may already be synced while others still are left with the old version right? How do people deal with this issue? I guess the same problem exists when deploying via svn/git/cvs. Should I just close the site, rsync, and open up again? Or do people simply ignore this inconsistency problem?
Use a two-step deployment. rsync to a test directory, ideally test it, then swap the production and test deployments around. The first time you do this, you might not have a ready-to-go test directory, but you can fix this by simply rsync-ing from production to test.