Is there a way to 'watch' for submissions to all, or a specific depot, in Perforce? I was looking at p4 reviews but I'm not sure if it's what I need.
I want to make a piece of middleware that will send a payload to an internal service whenever someone makes a submission but I need some sort of way to watch for those changes. Something like p4 changes but in real-time so a new line is printed to the terminal whenever a change is made.
What am I best off using for this?
So, the review daemon (and by extension reviews on your user) is the recommended way to watch for changes, BUT, it sounds like you want more customization here...
So, if you go down a rabbit hole too far and decide you just want basic reviews, this article: http://answers.perforce.com/articles/KB/2920 details what needs to be setup.
Having said that, a way to do this would be triggers on the server. Check out p4 triggers. You can catch a submit in several places. Before it's properly committed to the server, after it's officially committed, etc.
What you can do is setup a trigger that runs a script and either checks in a file to another part of the depot with processed payload from the changelist, or email a set of folks, whatever you want. Triggers can run arbitrary scripts (with all the security issues that can bring of course).
Related
When you're developing on localhost, then you've got full access to a terminal that you can log anywhere you want. But, in a project, I work on (and am new to team collaboration as a whole) they use something called weavescope to view logs that developers have created at the time of coding.
Now what the difference between this and logging locally, everytime you'll create a change in the code, you gotta send a pull request, they approve it, and merge it, deploy it and we finally see it in the log. Now, sometimes the state of local and deployed things don't match and it really makes us wanna dynamically log on to the development server without having to go through all these cycles over again. Is there any solution already around that helps us insert some quick log statements without having to go through the routine PR, merge, deploy cycle?
EDIT: I think from discussions I had below, the tool I am looking for is more or less a logging statment code injection tool. A tool that would keep track of the logs I'm inserting into the production code, and on/off them at spin of a command.
This seems like something that logging levels can help with (unless I'm misunderstanding). Something I typically do is leave debug-level log messages on commonly problematic or complex functions, but change the logging level to something higher when I move out of local. Sometimes depending on the app and access these can be configured at the environment rather than in the build.
For example there are Spring libraries that will let you import a static logger, set the level of each message you log out. Then locally you can keep the level at DEBUG, in UAT the level can be INFO, and if you only want ERROR OR WARN messages in prod you can separate that too. At the time of deployment you can set what environment it is and store a separate app.properties or yml file for each environment storing the desired level for each
Of course there is a solution for fast pace code changes.
Maybe this kind of hot reloading is what you're looking for. This way you can insert new calls to a logger or console.log quickly.
Although it does come with a disclaimer from the author.
I honestly haven't looked into whether this method of hot reloading would provide stable production zero-downtime deploys, however my "gut feel" says don't do it. And production deployments are probably one area where we should stick to known, trusted procedures unless we have good reason.
My Word add-in programmatically makes some changes to the user's document, sends that document to a remote endpoint, and then needs to undo those changes.
I don't see any references to the undo stack in the Javascript API documentation, though I've seen some mentions in online questions that seem to indicate that the undo stack is inaccessible via the API. Is this the case? Is there no way to perform an automated undo on these changes?
I've thought of a few workarounds, but none seem viable.
Copying the contents prior to the changes and then pasting it over the altered content won't work as any Content Controls seem to not persist in the pasted content.
Another potential solution would be to save a copy of the document, make the changes to this copy, send the copy and then delete it afterwards, all invisibly to the user. I don't see any functionality in the API that would allow for this though.
Failing all this, I'll need to track all the changes and then re-create the initial state one change at a time, which will be challenging. Any simpler solutions at all would be very much appreciated.
I'm working on a plugin for IBM Lotus Notes. I need to change content of an email right after user clicks 'send email' button, before the email is actually sent. I have searched APIs of Lotus Notes but can't find a workaround. There is a library named com.ibm.notes.mailsend in folder /opt/ibm/lotus/notes/framework/shared/eclipse/plugins. But I can't find any document related to it on Internet, and have no idea how to capture event about sending email. Does anyone know how to implement the function that I need? Thanks.
Update: Thanks Richard. Basically I've figured out how to hook email sending. But I also need to make an option that user can set differently for each individual email. From my understanding, email known as message is stored in Mail File database before being sent. How to 'add flag' to the message? Thanks.
The way to hook events in Lotus Notes is with the Notes C API's Extension Manager routines. The general strategy for hooking mail send operations is to set up a hook on EM_NSFNoteUpdateMailbox. This can be done on either the Notes client or the Domino Server. On the server side, if your processing is non-trivial, you run the risk of slowing down Domino if you try to do all of the work in your hook, so the strategy most people adopt is to have the hook code change the status of the message to "On Hold" and then signal a separate server task to take over the work. That way the hook can return and the separate server task can take whatever time is needed before resetting the status of the message so that normal routing will take over. You can find documentation here.
For server-side processing only, there are two options that will allow you to write your code in Java instead of C. One is an OpenNTF project called TriggerHappy that allows you to write Java Agents that are fired when some boilerplate hook code is triggered, and the other is the OpenNTF version of the Domino OSGi Tasklet Service (aka DOTS), which allows taskets to be fired in response to EM events. Note that there is an IBM-supported version of DOTS that is shipped in Domino 9 "Social Edition", but my understanding is that it does not include the EM event support.
Updated for additional info requested...
In order to add a flag to each message that can be read by the code that runs in your hook, you need to modify the mail template that is used in the users' mail files. You will need permission from the Domino system administrators to do this, and to be blunt: this is not something that Domino adminisrators like to do because it makes their job more difficult when they are upgrading Domino versions. There are many ways you could modify the template, but the point of all of them would be to add a new hidden field to messages which would serve as a flag for your hook code. If the field exists, your code would do the changes to the content that you need, otherwise it would leave the content alone. One possible way to do this would be by adding a shared action containing a formula to set your hidden field (that formula is just something like FIELD myFlagFieldName := "1";) and then you can add that shared action to the Memo form. Users would press the action button any time they want to trigger your code. The admin would need to maintain backup database containing your shared action and re-add it to the mail template after every upgrade and then re-add it to the new template version's Memo form. Of course there are other ways as well, some that are more friendly to users but harder for admins to deal with, and vice versa.
We have an app that is written in PHP. The front end uses javascript heavily. Generally, for normal applications that require page reloads, continuous deployment is not really an issue, because:
The app can be deployed with build tags: myapp-4-3-2013-b1, myapp-4-3-2013-b2, etc.
When the user loads a page (we are using the front controller pattern), we can inject the buildtag and the files are loaded from the app directory with the correct build tag.
We do not need to keep the older builds around for too long because as the older requests finish, they will move to the newer build tags.
The issue with database and user data being incompatible is not very high as we move people to the newer builds after their requests finish (more on this later).
Now, the problem with our app is that it uses AJAX heavily for smooth page loads. In addition, because there is no page refresh at all when people navigate through the application, people can keep their unsaved data in a their current browser session and revisit it as long as the browser has not been refreshed.
This leads to bigger problems if we want to achieve continuous deployment:
We can keep the user's buildtag in their session (set when they make the first request) and only switch to newer buildtags after the logout and login again. This is obviously bad, because if things like the database schema changes or the format of files to be written to disk changes in a newer build, there is no way to reconcile this.
We force all new requests to a newer build tag, but there is a possibility we change client side javascript and will break a lot of things if we force everyone with a session onto the new build tags immediately.
Obviously, the above won't occur with every build we push and hopefully will not happen a lot, but we want to build a fool proof process so that every build which passes our tests can be deployed. At the same time, we want to make sure that every deployed and test passing build does not inadvertently break in clients with running sessions cause a whole bunch of problems.
I have done some investigation and what google does (at least in google groups) is that they push a message out to the clients to refresh the application (browser window). However, in their case, all unsaved client side data (like unsaved message, etc) would be lost.
Given that applications that uses AJAX and local data are very common these days, what are some more intelligent ways of handling this that will provide minimal disruption to users/clients?
Let me preface this that I haven't ever thought of continuous deployment before reading your post, but it does sound like quite a good idea! I've got a few examples where this would be nice.
My thoughts on solving your problem though would be to go for your first suggestion (which is cleaner), and get around the database schema changes like this:
Implement an API service layer in your application that handles the database or file access, which is outside of your build tag environment. For example, you'd have myapp-4-3-2013-b1, and db-services folders.
db-services would provide any interaction with the database with a series of versioned services. For example, registerNewUser2() or processOrder3().
When you needed to change the database schema, you'd provide a new version of that service and upgrade your build tag environment to look at the new version. You'd also provide a legacy service that handles the old schema to new schema upgrade.
For example, say you registered new users like this:
registerNewUser2(username, password, fullname) {
writeToDB(username, password, fullname);
}
And you needed to update the schema to add the user's date of birth:
registerNewUser3(username, password, fullname, dateofbirth) {
writeToDB(username, password, fullname, dateofbirth);
}
registerNewUser2(username, password, fullname) {
registerNewUser3(username, password, fullname, NULL);
}
The new build tag will be changed to call registerNewUser3(), while the previous build tag is still using registerNewUser2().
So the old build tag will continue to work, just that any new users registered will have a NULL date of birth. When an updated build tag is used, the date of birth is written to the database correctly.
You would need to update db-services immediately, as soon as you roll out the new build tag - or even before you roll out the build tag I guess.
Once you're sure that everyone is using the new version, you can just delete registerNewUser2() from the next version of db-services.
This will be quite complicated to make sure that you are correctly handling the conversion between old API and new API calls, but might be feasible if you're already handling continuous deployment.
I'm testing out Microsoft Sync Framework to try and see if it'll be suitable for a task that I'm working on. One of the things I'd like to be able to do is to have the option to not just send changed files, but instead to send all of the files (for example, if I'm syncing to a client machine for the first time, and so want to send all files).
I can't seem to find an example of this in the documentation, so any advice would be welcome.
if you're synching for the first time, then there is nothing special to configure as it will sync everything.
if you've already synched and want to re-send all files regardless of whether they've changed or not, just delete the metadata file and that should remove all knowledge of what has been synched.