Cloudformation stack won't update after template change - aws-cloudformation

I tried to update a cloudformation stack after I changed the parameters.
The change I did for some parameters is added NoEcho: true property in order to not present the secret parameters in the meta data of the stack.
When I upload the new template I see the changes in the parameters but when I try to apply the changes I get an error saying that there were no changes.
I understand that no change was made in one of the resources itself, but I need to change this stack without destroying it and re-creating, just updating it.
Does anyone have a proper solution for this problem?
Thank you!

Make some arbitrary changes to the stack. For example, create a new resource, deploy it, then remove it and deploy again.

It is a bit tedious. If you want to do an update to an existing stack in Cloudformation by changing the value of a parameter (e.g. using them as variables), Cloudformation doesn't detect it as a change. You have to change something in the Resources section.
Cloudformation is great if you don't need to go back and change existing stacks, not so great if you need to make updates routinely.

Related

Azure DevOps Migration - Moving Project to Another Org

I'm looking to migrate a project from one org to another in Azure DevOps. We've ended up with two or three orgs, and this project that I'm looking to move has all sorts of weird and wonderful work items created and custom fields added. What I'm looking to do is move the project and then see if I can persuade the powers that be that certain things can be dropped but I have an immediate need to move as-is so that reporting and other work isn't impacted.
I have tried to get this to work with the migration tools (and tried to follow the videos) but have hit a dead-end. I think there are two issues potentially. One being the ReflectedWorkItemId. It says that it's not found in User Stories but I'm not sure how to resolve this? Do I go into user stories and add a field called 'ReflectedWorkItemId' and populate it with the work item number and/or add the same field in the destination org process?
It also mentions in the info that it can't find one of the Work Item Types - Processes. There are a few other custom work item types that have been created too but I assume it's given up on the first one. Do I have to create all of the work item types and the custom fields for each work item type in the destination org? Or am I getting the wrong end of the stick with this?
To provide sync as well as migration it is important that the tools knows which items have already been migrated. This is the purpose of the ReflectedWorkItemId field.
The field is not required in either case, however... if you don't have
the field then the system cant be re-run as it will re-copy all
completed work items. If you add the field to the target then it will
only copy those items it cant find. If you add the field to the source
(yes it needs to be the same refname), and set UpdateSoureReflectedId
to true then you can also filter the source, using a query and limit
what you load.
The former prevents duplicates, and the latter allows you to filter
the data load...
This is mentioned in this document. Here is a similar issue you can refer to.
TF201077 that usually happens when the target Project does not have a work item of that name. You can refer to this issue on github for help.

Create task automatically when creating bug in Azure Devops Server

We are using Azure Devops Server. When a bug is created, I would like to create a child task automatically. The task does not need to have any particular properties, it just need to be created with default values and have a default name like "Placeholder" or something like that.
I have already encountered some different ways of doing it, but neither of them seems to be well suited for me:
The extension 1-click-child-links could be used to create a child task by clicking a button in the context menu after creating the bug. This will of course work, but it would be even better if it could be done in the background ensuring the task to be created even if the user forgets to click the button.
As I understand it, using the Microsoft Flow software tasks can be created in the background when creating a bug which would be exactly what I'm looking for, but it would be nice to find a simpler way of doing it without installing a complete software tool.
I've learned that it is possible to hook into different events by using service hooks (https://learn.microsoft.com/en-us/azure/devops/service-hooks/events?view=azure-devops). There are a couple of standard integrations, but neither of them can be used to solve my case. So using this method, I guess I need to develop a custom service creating the task?
Is there a simpler solution to achieve my gool or do I need to stick with one of the solutions above?
As a workaround , we can set Azure Logic App, select When a work item is created"as trigger, and then select Create a work item as action.
Make sure to set the Link URL to the “When a work item is created” URL and set the Link Type to Hierarchy-reverse to create the Task as a child of the Bug item. Please refer to the settings below:
Save the Logic Apps Designer, and then when the bug item is created, the child task named Placeholder will be automatically created.

Grafana dashboard custom variable as a json object

We are using grafana to visualize our metrics and very glad to use it.
For one dashboard I need to create custom variable to show host name. For example, we have the first variable: host with query collectd.localhost.ping.ping-* and regexp /ping-(.*)/. It returns a list of hosts that we ping. Now I want to add showing title depends on selected host. I think need to add another custom variable title like map host1:Title1;host2:Title2 and in the panel's title write something like Proxy ${title:json}.${host} in result get Proxy TitleN.
How to do it? We use 7.2.1 grafana version.
Thank you!
I'm not sure if this is a great answer, but given it's been nearly two years without any answer, I'll proffer it. Having just commented how I was surprised no one had in fact answered, I kept poking around. Eventually I found that if added a variable interactively, and then I clicked dashboard settings followed by JSON Model I got to a description that included new data in the templating field. I pasted that into my original JSON description of the dashboard, and restarted Grafana --- the change persisted.

Trigger a plugin step on "entityimage" change

I created a plugin that should upload the contact entity "entityimage" to an external storage.
The code itself should works (it works as a console app), but I am unable to add a step that trigger on "entityimage" change as I can't find it in the filtering attribute list in the Plugin Registration Tool.
Is there a way to trigger this plugin only when "entityimage" change?
Regards,
Dremor
Reviewing the Contact's entityimage field in the Metadata Browser indicates that it is a "Virtual" field, which may be why it is unavailable as a filtering attribute.
Also, according to the SDK there does not appear to be any other message available besides "Update" on the Contact that could be used to indicate that the entityimage has changed.
And, changing the image through the UI does create an Audit History entry, however, it is a generic "Update" entry, with the old value and new value blank.
It appears that triggering a plugin on change of only the entityimage field is not possible, nor do there appear to be any OOB hooks to see if that field has changed.
The only other think I can think to research is Change Tracking. Otherwise it looks like you may have to upload the image on any Update of a Contact.
Or, you could sync the image URL's from CRM to an external system and compare the one in CRM to the external system before uploading.
Strangely enough, if you don't set any filtering attributes the plugin does get triggerd when changing the image, but i guess this also means that all field changes will trigger it.

is it possible to get an xPages build number?

I do all development in a single application. when a new version is ready I create a template and give it a version number. this way I can store a history of all previous versions.
the development templates are used to push the new design to many applications via replace design.
Creating manual version number or template names is fine but I am looking for a more automatic way of finding out which build the different applications are inherited from
When I visit the different applications I would like to be able to see which build number each application are inherited from. is this possible?
A simple build time stamp could do, but is there a built in build number that can be used and that can be displayed on the xpage.
e.g Build 2012092712345
Update:
Thank you for all your answers, many good suggestions but it looks like all require manual work.
The best solution would be if there is a way to read (from ssjs) a timestamp from any file within the nsf that is always updated during a build. is this possible?
In classic notes, there was a method to add a shared field with a special name to the application. Cannot remember the details, but have it somewhere on the disk.
Then you can see the build number in the design tab of the application properties. And you can of course display the value in your applikation as well.
But you have to fill the item manually on each build. Or use teamstudio Buildmanager. This tool adds the value automatically.
And I also guess that you can write some code that changes the value whenever you create a new build.
Another option would be to use a versioning system like CVS/SVN. This is possible since 8.5.3.
Source control
I think I know what you are meaning. Your a pushing out design and want to check thru code what version each database has. I usually do this with a Build form. In this form I have computed fields with all the data I want to retrieve. Then I open the database with an agent create a document
and set the form field to "BuildForm" and do a computewithform.
Now I can see all information about this database.
I once wrote a rudimentary build system for "classic" Notes, and had the last part of the build pipeline create a form named _BUILDID_, and put the build id in the $Comment field.
The main reason to create a form instead of a shared field was that I could dynamically fetch the form using NotesDatabase.Forms, and open up the desired field.
I sure hope there are simpler solutions nowadays... :-)