I use github action to deploy my website to my server. The last ssh cmd is npm run start. It will output ready - started server on http://localhost:4000(Since i use Nextjs) finally but it seems that github doesn't know what did it mean and print :
2021/01/09 14:24:14 Error: command timeout
err: Run Command Timeout!
Although the website is successfully deployed, it shows that the Github action failed to execute.
So how to tell github action that the job had done successfully？
You should find a way to start the application in a daemon process of its own, rather than as a process within the SSH session. Perhaps this tool (pm2) might solve your problem? This question and answer is somewhat related.
There are definitely other ways to start your app in a daemon process, or perhaps as a service, but this might be the most straightforward for you since it's a Node tool.
Related
...is there like compiling the project and make it run to be autoexecutable?
Sorry for the general question. I have been doing little projects with server side and I find that always I need to write "npm start" or so to make the whole start working.
My doubt is, Do these projects need to be compiled somehow or it is just as is, a simple line runs the coded files and that works like a server side?
Also, should not a server side able to run by itself (by definition) when the system restarts? So far, I needed to create bat files/start folder in windows to make then run in case of restart.
According to NPM documentation:
npm start
This runs an arbitrary command specified in the package’s "start" property of its "scripts" object. If no "start" property is specified on the "scripts" object, it will run node server.js.
To start the server you have to start a process and that process is started by npm start. If processes are killed they cannot be brought back to life by themselves. If the process is killed (eg when you restart) you have to make sure a new process is automatically spawned. You can accomplish this in multiple ways. You could use services (for example systemctl in Debian). You could also use tools like Kubernetes which can automatically restart a container in case of a crash.
Another possbile solution to use something like Respawn which allows you to respawn a process if it crashes from NodeJS code. Of course, it can also be accomplished with plain NodeJS.
When running dbt deps, I get back this error message:
Running with dbt=0.17.0
Error sending message, disabling tracking
Encountered an error:
Unable to connect to registry hub
What's happening here, and how can I work around it?
First of all, it's worth understanding what's going on here. It looks like you're trying to install a package from the dbt hub site (hub.getdbt.com) — if you open up your packages.yml file, you'll find something like this:
packages:
- hub: package-owner/package-name
version: 0.1.0
When you run dbt deps (at a high level):
dbt sends a request to hub.getdbt.com
From hub.getdbt.com, a request is sent to GitHub to download the package.
The package is copied into your project
This error occurs if dbt cannot connect to the hub site after sending a network request repeatedly. First off, we recommend you retry the dbt deps command — sometimes it's just a blip in connectivity that goes away on the second try.
If the error persists, there may be a few different reasons for it:
hub.getdbt.com might be unavailable. This happens but is relatively rare. You can navigate to hub.getdbt.com to check if this is the case. Also check the Netlify status page to see if there are any issues.
GitHub might be down — you can check this by going to the GitHub status page.
Finally, it may be that a firewall rule or antivirus software on your computer is rejecting the request. Talk to your IT team to find out if this is the case and whether that restriction can be removed.
We generally recommend using the hub syntax for packages, however if you need to work around it, you can consider using the git syntax (docs) or installing the package from a local directory (docs)
I have a unique problem using jmeter SSH command.
I use this step to run spark jobs.
the problem is that one of the commands not working, to clarify it connects and not get response and just wait and wait for hours, and nothing displayed on screen.
I know how to work with the tool, and this behavior is special for this script alone.
All other script worked, I duplicate one that worked for example
sudo /run_stg.sh this command worked
sudo /run_off2-stg.sh this command not worked
if I run the job manually via jenkins it worked
if I entered to command line and use plik ssh it worked,
the problem is just Jmeter, that is waiting and waiting and I can not understand for what?
the job is about 3 minutes, and I wait for response in Jmeter for 4 hours and nothing Jmeter just waiting.
in the console log I set to trace level and nothing, absolutely no idea how to start handle this issue in Jmeter.
an anyone please assists how to make Jmeter to write what happened?
or just to know if he connect or anything
since this behavior all the test can not be performed
Most probably you are as usual misconfiguring the SSH Command sampler.
The idea is not to run the script per se, you need to delegate the script execution to the Unix Shell, for example Bash this way you will be able to combine several commands together, see the output, amend debugging level, etc.
So I would recommend setting your command to something like /bin/bash -c -x /your/script.sh
Another guess, given you use sudo it might be the case that the sudo command simply waits for the password (which JMeter never provides), if this is the case try amending your script permissions using chmod command and allowing your user its execution without root privileges.
And finally, given you're able to run your command using "plik ssh" (whatever it is) you can run it using OS Process Sampler
More information: How to Run External Commands and Programs Locally and Remotely from JMeter
I just started using fugitive in my workflow... very useful! But I've seem to have run into a weird annoyance that I'm hoping someone might have a solution to:
When I run :Gpush, sometimes control never returns to vi. Vi hangs on the output of git push until I Ctrl+C to kill "it". I've also tried installing vim-dispatch and, within tmux, the result is that the git push pane never closes. This is even more annoying because I've got to switch down to that pane to Ctrl+C it.
Oddly, if I ps, I do not see any git processes running, so I'm not sure what is hanging, exactly... but Ctrl+C does kill "it", whatever "it" is, and control returns to vi.
I've found a closed github issue that mentions similar behavior, but a solution was never posted... it appears the problem eventually just "went away" for the OP, so the issue was closed.
However, a second person replied to the issue some time later saying he was having a similar problem and it seemed to happen when git spawned some kind of "credential cache daemon". I'm not using a credential helper as he is, so that's not my exact issue... but that caused me to notice something else:
I have ssh configured to keep connections open for 5 minutes (ControlPersist 5m in my ~/.ssh/config). If I haven't pushed in a while, git push causes ssh to spawn a process to persist the connection. This triggers the issue. After 5 minutes, ssh exits, which will fix the problem and cause the tmux pane to close. If I do another push while the connection is still open, it works fine.
So, the problem seems to be when git spawns another process. This obviously doesn't cause any issues when I run git on the command-line, so why does it cause an issue here? And what can I do about it? I don't want to disable the ssh persistent connections because that's useful...
For anyone who stumbles upon this in the future, I've come up with a solution for my particular case where the ssh process is hanging vim: I disable the ControlPersist option, but only for git commands run inside vim via fugitive by setting the following option in my .vimrc:
let g:fugitive_git_executable = "env GIT_SSH_COMMAND='ssh -o ControlPersist=no' git"
It's ugly, and I'm sad that I have to disable the persistent connections, but it works.
I just downloaded the free trial of Bamboo continuous integration server, and created the first plan with nothing but downloading the source code from the git. I have a local git repository on the bamboo machine so the git URL is pointing to a local path.
The problem is that when I run the job, it never finishes even after waiting for an hour. This is the last lines of the activity log:
07-Apr-2011 20:03:23 Checking out revision f9dc82500914333ed4bbdae5ed038771fd658c3c.
07-Apr-2011 20:03:23 Creating local git repository in '/home/bob/bamboo-home/xml-data/build-dir/DEV-DEV-1/.git'.
From the shell I can go to the directory shown in the log and see that the source code were cloned correctly to the bamboo working directory. But the job will never finish and the log will not have any more update from here. I have to manually terminate the job. Any ideas? Do I miss something?
Just a guess, since the Bamboo instance we have at work pulls from Accurev and not Git, and I've never run into this problem myself - but it may be hung because there isn't a builder defined for that plan. You might try defining a builder (even if it's one that you know will fail) just to see if it makes it to that next step.
I had very similar problem.
It's not very original solution but I just uninstalled bamboo and installed it again.. Now it works now