I have a legacy FME script written a long back but now I got a scenario to add a new workspace and call it only once. If I am running this script manually then it triggers only once but the moment I run all workspace together then running twice.
Just curious to know is there any way to force the workspace to trigger only once irrespective of input count. I have attached the screenshot below to give more clarity.
As you can see this stacked_linker_workspace wanna trigger once.
Maybe you can add counter and tester transformer just before Stacked_Linker_workspace
On the tester, create test to pass when the value of counter is the first number (by default it's 0)
Related
The currentBuild global variable in Jenkins has a method of getBuildCauses(). The Reference says this:
getBuildCauses
Returns a JSON array of build causes for the current build
I was wondering, why does this method returns an array? Is there any possibility that a build was caused by several causes?
There are cases where a job was triggered by another job that was e.g. started manually by a user. So this information about a user who triggered the parent job is made available in the array. In another case, this job may be rebuilt manually by a user from a previous run that was triggered by a webhook. Sometimes, people want to know the whole history of the job instance, and so it's made available in this array.
I have a pipeline in Jenkins, where one project sends parameter to the next one. The trigger is set during the Build step and is the last step in the Build process. I have checked the "For each property file, invoke a build" button, where the properties files to be read are in the work space of the current project.
On build, I can see that the Downstream project following the current one, is given the properties of the property file. But when I try accessing them, it just takes the name of the variable and not the value. This means that I am not able to access the parameters in the property file. Can you tell me how will I be able to access the parameters that were passed during trigger from the property file? I have tried all ways, but I can't seem to access them.
Image of Parametrized Trigger--
I solved the issue: in order to use the parameters sent during the trigger, we need to declare them in the triggered project. They should be kept empty. Once we do that, they will take the values sent across by the previous project.
I was able to create the new job but I am NOT able to add any build step.
This behaviour is reproducible and it occurs when I try to do it from the initial “configure” page I get after job creation as well as with a later configure attempt. And its persists for all job types.
It does not depend on whether I am logged in or not.
The problem is that when I open the “add build step” I get a selection of possible job types (“shell script”, “windows batch”, …) but when I select one of those nothing more happens.
I also have other jobs of this type already up and running and I am also not able to add more build steps to those.
I had this with v1.625.3, all of a sudden. Problem in Chrome and FF. Workaround was to use IE.
I had a request a to create a java client and start jenkins build for a specific job; and get back the result of that build.
The problem is, the system is used by multiple users and their build might messed up altogether. Also the get latest build my retrieve me the previous finished build instead of current one. Is there anyway to do build/get result transactionally?
I don't think there's a way to get true transactional functionality (in the way that, say, Postgres is transactional), however, I think you can prevent collisions amongst multiple users by doing the following:
Have your build wrapped around a script (bash, Python, or similar) which takes out an exclusive lock on a semfile before the build and releases it after its done. That is, a file which serves as a semaphore that the build process must be able to exclusively lock in order to be able to proceed.
That way, if you have a build in progress, and another user triggers one, the in-progress build will have the semfile locked, and the 2nd one will block waiting for the exclusive lock on that file, getting the lock only once the 1st build is complete and has released the lock on the file.
Also, to be able to refer to each remote build after the fact, I would recommend you refer to my previous post Retrieve id of remotely triggered jenkins job.
I need to build in jenkins only if there has been any change in ClearCase stream. I want to check it also in nightly or when someone choose to build manually, and to stop the build completely if there are no changes.
I tried the poll SCM but it doesn't seem to work well...
Any suggestion?
If it is possible, you should monitor the update of a snapshot view and, if the log of said update reveal any new files loaded, trigger the Jnekins job.
You find a similar approach in this thread.
You don't want to do something like that in a checkin trigger. It runs on the users client and will slow tings down, not to mention that you'd somehow have to figure out how to give every client access to that snapshot view.
What can work is a cron or scheduled job that runs lshistory and does something when it finds new checkins.
Yes you could do this via trigger, but I'd suggest a combo of trigger and additional script.. since updating the snapshot view might be time-consuming and effect checkins...
Create a simple trigger that when the files you are concerned about are changed on a stream will fire..
The script should "touch/create" a file in some well-known network location (or perhaps write to a pipe)...
the other script could be some cron (unix) or AT (windows) job that runs continually or each minute and if the well-known file is there will perform the update of the snapshot view..
The script could also read the Pipe written to by the trigger if you go that route
This is better than a cron job that has to do an lshistory each time.. but Martina was right to suggest not doing the whole thing in a trigger for performance and snapshot view accessability for all clients.. but a trigger to write to a pipe or write some empty file is efficient and the cron/AT job that actually does the update is effieicnet as it does not have to query the VOB each minute... just the file (or only after there is info on the pipe)..