How often is there a check on changes to the source data for the hook to trigger?
We've only managed to get it to trigger automatically / instantly once.
We've tried deleting and reconnecting the source, trying different sources and making new projects.
Sometimes, it just doesn't trigger at all.
Anything that might shed light would be a great help.
The frequency of source data check in Supernova Hooks varies.
But if you're having trouble with the hook triggering once or not at all, here's what you can check:
Double-check that the hook is set up and configured to trigger based
on the changes you want to see.
Make sure there aren't any network/firewall blocks preventing the
hook from triggering.
Check if the source data is being updated correctly and if those
changes are reflected in the hook.
If all else fails, hit up the Supernova support team for help.
And, don't forget, the issue might be with Figma, not Supernova. So, check their docs and support as well.
Related
Is it somehow possible to automatically add a label to GitLab issue in the git commit message? I know that it is possible to close issue by message fix #123, but how to add label to issue, for example, "Testing"?
No, this is not possible natively. The only thing you can do is mention the issue 'Fixes/Closes #123' as you mentioned.
If you really need to do this, then you could potentially do it as part of a custom server-side hook. You would have to interact with the GitLab API to add/manage the labels, but it would be possible. You can learn more about this in Custom Hooks Documentation.
However, I generally recommend avoiding custom hooks. Especially ones that interact with an API as strange things can happen. For example, if you call an API in a pre-receive hook and that connection hangs, your push also hangs. It's not quite so bad for a post-receive but there could still be problems if a post-receive hangs indefinitely.
I am writing some code that will update the reference of the Business Units after the deployment of a new solution.
After a solution import all the references point to the Dev's Business Unit Guid, so, for instance, every view that refers to them is empty.
Manually updating those references is time consuming and boring. That's why I am writing some code that does the trick.
The code works, but it would be much better if I could add it inside a Custom Workflow Activity or a Plugin and have them run after every solution import automatically.
Is it possible or am I just daydreaming?
There is an Import and ImportAll message you can register your plugins on, however I have never used them so I'm not sure how they work.
I have registered plugins on Publish and PublishAll messages before. You can use those messages and they will run after you publish an entity/resource or publish all the changes respectively.
A remote CMIS repository contains many folders/files.
I am writing a software that keeps a local copy of these folders/files in sync.
At first run I just download everything recursively.
At later runs, I check what has changed, and download any changes.
What is the most efficient way to check the remote changes?
(additional/removal of files/folders)
Most efficient = Least bandwidth usage.
I can only use the CMIS protocol, and I can not run any custom software on the remote server.
My ideas so far:
Idea 1: Re-download everthing every time.
Idea 2: Check the root folder's modification date, hoping modification dates are recursive.
Idea 3: Use CMIS search to find all files that are more recent than the last time I synchronized. Problem: that won't tell me which files have been removed.
Any other ideas?
I don't know the CMIS protocol much, there might be something more convenient.
Using the repository's change log is the right way to go, but realize that not every repository supports this. For example, for Alfresco you must configure the audit sub-system and you must set audit.cmischangelog.enabled=true in alfresco-global.properties.
To find out if your repo supports changes you can look as the results of the repository's getCapabilities response. If you see 'Changes' set to 'None' then your repository doesn't support change logs.
Assuming it does, you need to ask the repository for its latest change log token. You can get that from getRepositoryInfo. Save that before you call getContentChanges. Then, on the next call, pass in the token. You'll get the changes made since the token was issued.
So, your code needs to:
Check getCapabilities for something other than Changes = None
Save the getRepositoryInfo's latestChangeLogToken
The first time you ask, call getContentChanges with no arguments
The next time you ask, call getcontentChanges with the last saved token
You can then process the result set. Each change log entry tells you its type (created, updated, deleted, permissions, etc., see spec for exact values) and provides the cmis:objectId of the changed object.
Repeat with step 2.
I have a "cmis-sync" script that does one-way synchronization using this approach implemented in Python. I've tested it against Alfresco as the source and the OpenCMIS InMemory repository as the target. If there is interest I can make it available.
A more ideal version of idea 3 is easily accomplished according to some digging through the CMIS protocol you posted.
2.1.11 Change Log
CMIS provides a “change log” mechanism to allow applications to easily discover the set of changes that have occurred to objects stored in the repository since a previous point in time. This change log can then be used by applications such as search services that maintain an external index of the repository to efficiently determine how to synchronize their index to the current state of the repository (rather than having to query for all objects currently in the repository).
Entries recorded in the change log are referred to below as “change events”.
Note that change events in the change log MUST be returned in ascending order from the time when the change event occurred.
Using whatever tools of your choice, you should be able to do an initial pull of the entire repository and save the time the pull was performed. Subsequent queries to the repository (at an interval of your choosing) are done with the following procedure:
Pull down the CMIS changelog from the repository
Parse all changes created after the previous pulls
Perform operations based on the ChangeType enum: for example, if the "deleted" enum is present for an objectID, delete that object locally.
I didn't get any overlay change when my teammates make changes or add a new file to my project.
Should I regularly update my project to keep track with the updates made? Or am I missing any configuration part that shows a new overlay whenever any of my teammates makes a change?
Note: I get red and other overlays correctly whenever I make changes to files.
Yes, you would need to do periodic updates to get changes from you team members. The trigger for this could also be one of the folloiwng.
A notification from the continuous integration when a build containing changes from other team members has been done.
A post-commit hook in your subversion server which emails all interested parties whenever there is a check-in.
I've been doing some research into finally automating our Development builds and still have one nagging question that I'm hoping the StackOverflow community can solve for me.
My understanding is that an IntervalTrigger when setup properly will check VSS every X seconds for changes and if it finds a modified file, will run my tasks. One of my tasks would be to checkout the AssemblyInfo files and update the version numbers. After these files are updated they would be checked back into VSS.
Thinking about this solution it doesn't make much sense because in my mind, I'm forcing the check for changed files to true every time the trigger fires. Am I missing something here? Is there a way of doing this without triggering an automatic build on the AssemblyInfo check-in?
You can use a Filtered Source Control Block to exclude certain files from the trigger.
I just posted a bunch about my default build process here which may be of some interest to you: SVN Website Development and Deployment Solution
The way I usually configure my projects with CC.NET is to have two project blocks per solution. One configured as an interval trigger that does nothing more than get the latest from my repository, build the solution, and run unit tests. The other is a schedule trigger that does all the things the other one does, but actually publishes a build. This includes changing version numbers, publishing files, etc. This might work in your case, since the change in version would cause the interval project to trigger, but only once.
Checking the automatically generated AssemblyInfo into the version control system is a bad idea, don't do it. You'll get a lot of noise (50% of all commits!) in your history. Also, it does not give you any new information - you can always pull this from VCS. Have your build script autogenerate those files is a good practice, but don't push those changes back!