Is there a way to directly run handler by ansible-playbook?
For example, i have handler restart service in my role and sometimes i want just trigger it directly without deploying whole app.
There are a number of options answered in a similar post on ServerFault. In summary:
Options for triggering a particular handler:
Use a no-op command to trigger it
Use a debug with changed_when: true to trigger it
Options for triggering all handlers:
Run with --force-handlers
Use a meta: flush_handlers task
Options for re-architecting:
Use a task instead
Related
I have an action job which upload the context to other website. The token was set and stored in the secret.MY_TOKEN.
But others who make the pull request also trigger this action job using the token I set.
How to limit the privilege of executing the jobs that only I can run this action job.
fyi my ci.yml as follow:
name: foobar
on: [push, pull_request]
jobs:
upload:
runs-on: ubuntu-latest
steps:
....
- name: execute upload
env:
TOKEN: ${{ secrets.MYTOKEN }}
run:
upl --token ${TOKEN}
I assume there are two security problems here.
The token is printed in log file.
others who can use this private token by trigger action with their own purpose.
Use the github.repository_owner context
https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context
The syntax should be something like:
- if: github.repository_owner == 'owner_name'
There is a new feature which could help, since July 2022:
Differentiating triggering actor from executing actor
Starting next week, workflow re-runs in GitHub Actions will use the initial run’s actor for privilege evaluation.
The actor who triggered the re-run will continue to be displayed in the UI, and can be accessed in a workflow via the triggering_actor field in the GitHub context.
Currently, the privileges (e.g. – secrets, permissions) of a run are derived from the triggering actor.
This poses a challenge in situations where the actor triggering a re-run is different than the original executing actor.
The upcoming change will differentiate the initial executing actor from the triggering actor, enabling the stable execution of re-runs.
For more details see Re-running workflows and jobs.
I don't believe allowing actions to run only for certain users is a native feature.
However, you could simply check the action context actor and exit early if the actor is not the yourself (or the owner of the repo, or whatever condition you'd like).
I have written a script to update my db table after reading data from db tables and solr. I am using asyn.waterfall module. The problem is that the script is not getting exited after successful completion of all operations. I have used db connection pool also thinking that may be creating the script to wait infinitly.
I want to put this script in crontab and if it will not exit properly it would be creating a hell lot of instances unnecessarily.
I just went through this issue.
The problem with just using process.exit() is that the program I am working on was creating handles, but never destroying them.
It was processing a directory and putting data into orientdb.
so some of the things that I have come to learn is that database connections need to be closed before getting rid of the reference. And that process.exit() does not solve all cases.
When my project processed 2,000 files. It would get down to about 500 left, and the extra handles would have filled up the available working memory. Which means it would not be able to continue. Therefore never reaching the process.exit at the end.
On the other hand, if you close the items that are requesting the app to stay open, you can solve the problem at its source.
The two "Undocumented Functions" that I was able to use, were
process._getActiveHandles();
process._getActiveRequests();
I am not sure what other functions will help with debugging these types of issues, but these ones were amazing.
They return an array, and you can determine a lot about what is going on in your process by using these methods.
You have to tell it when you're done, by calling
process.exit();
More specifically, you'll want to call this in the callback from async.waterfall() (the second argument to that function). At that point, all your asynchronous code has executed, and your script should be ready to exit.
EDIT: As pointed out by #Aaron below, this likely has to do with something like a database connection being active, and not allowing the node process to end.
You can use the node module why-is-node-running:
Run npm install -D why-is-node-running
Add import * as log from 'why-is-node-running'; in your code
When you expect your program to exit, add a log statement:
afterAll(async () => {
await app.close();
log();
})
This will print a list of open handles with a stacktrace to find out where they originated:
There are 5 handle(s) keeping the process running
# Timeout
/home/maf/dev/node_modules/why-is-node-running/example.js:6 - setInterval(function () {}, 1000)
/home/maf/dev/node_modules/why-is-node-running/example.js:10 - createServer()
# TCPSERVERWRAP
/home/maf/dev/node_modules/why-is-node-running/example.js:7 - server.listen(0)
/home/maf/dev/node_modules/why-is-node-running/example.js:10 - createServer()
We can quit the execution by using:
connection.destroy();
If you use Visual Studio code, you can attach to an already running Node script directly from it.
First, run the Debug: Attached to Node Process command:
When you invoke the command, VS Code will prompt you which Node.js process to attach to:
Your terminal should display this message:
Debugger listening on ws://127.0.0.1:9229/<...>
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Then, inside your debug console, you can use the code from The Lazy Coder’s answer:
process._getActiveHandles();
process._getActiveRequests();
I'm seeing multiple submissions on a form, presumably because someone is double-clicking a submit button. Is there a good way to prevent this in GAS? I suppose I could set up a global variable via JSON, and use that to determine whether or not to execute the handler, but it seems a bit clunky.
Thanks.
create a client Handler that disables the submit button before the rest of your code is executed.
You can add a client handler anywhere you would add a server handler of any type, and it works entirely on the client without any server roundtrip.
See Serge insas comment below!
I have a package that sends out two emails whenever a control flow element fails. For example, if the ExecuteSQL Task fails, the Package level OnError event handler fires two emails.
Is this a known issue? How do I get around this?
I can do this through database driven scripts, but essentially, I would like to handle the situation on SSIS itself. Thanks for any help.
Keep in mind that event handlers will raise events anytime the triggering action occurs. So, you're not guaranteed to only get one event using an event handler (with a few exceptions of course).
If you want to guarantee only one email then I would recommend not sending email via the OnError event and instead linking a 'Send Email Task' that is part of the control flow and connected to the ExecuteSQL task with a 'Failure Constraint'.
Or, you could also set a user variable equal to true in the OnError event and then send the email based on that with a 'On Completion' constraint mixed with an expression that checks the value of the Error user variable. That way, it doesn't matter how many times the OnError event raises as the task will only run if it was raised at least once.
I have to modify an Oracle Form but cannot find my way to start.
What is the start up order for a standard form? That is which event, trigger etc will be called at form load, canvas load, etc. I assume that it is When-New-form-Instance but a cannot get it to stop at a break point on the first line of this trigger.
I am getting
FRM-40735 ON_ERROR trigger raised unhandled exception ORA-06508
Which I suspect means I do not have my environment set up correctly but I have done the same as others at this site. So I thought to start with debugging and try to identify which call is failing
PRE-FORM fires before WHEN-NEW-FORM-INSTANCE. Check what's defined in PRE-FORM trigger.
Also, your ON-ERROR trigger is giving a ORA-06508 error, so might want to check what program unit is being referred to in the ON-ERROR trigger
To get a start in trying to find the source of the error, try disabling custom code in forms. If the error does not persist when custom code is disabled, you'll have to start tracing through CUSTOM.PLL to find the source of the issue.