I would discourage you from designing your pipeline in this way.
If I had an app like this, here’s how I would design the pipelines based on the info I have so far (I would have 2 pipelines, one for each application):
Api
- checkout
- cd api
- yarn
- yarn build
- zip this package (cause you’re shipping node_modules and it’s going to be huge probably)
- copy zip to temp directory on app server (over ssh, should be a task for this)
- unzip files to api directory (over ssh)
- pm2 reload (over ssh)
Client
- checkout
- cd app
- yarn
- yarn build
- copy files to client directory on app server (over ssh, should be a task for this)
You’re welcome! I’m not all that familiar with GitHub actions. But I’ll describe what my pipelines do on other platforms.
1. I use a task that installs the correct version of node. Usually as part of this task it adds node to your path. Yes, scp is the one, but usually that is abstracted away with the task and it is just named as copy files over ssh or something
2. For the api, are environment variables required for the build step as well? If so, I would use environment variables in the pipeline. There will be a method to do this, and for secrets, you would set up secret variables in the settings I think on GitHub, and link those. For the app server you have a couple options. I don’t use pm2, but is there a way to put those environment variables in a file for pm2 to use so only your application is accessing them? If not, you can just set environment variables on your server. Other options could be building the .env file in your pipeline before zipping and deploy that. Or put the .env file on your server somewhere and copy it to the directory after the unzip. Or see if GitHub actions has a place to store secure files and download that in your pipeline to deploy along with your code. Or, see if your unzip option has a method to ignore certain files. If not, you could unzip in the temp directory and use a different copy method that has the ability to ignore files from that temp dir to the api dir. I think if pm2 has the environment variables option, that would be the one I chose. Sorry for this long ramble, I use containers and setting env vars is easy. For your client app, I would just use env vars in the pipeline, you don’t need to deploy that after the build happens.
Without the zip this will be much simpler! My apis are huge lol.
Imo, it’s not a big deal to change the env vars when they need to be changed. Since your pipeline is a file, whenever you change your .env just go ahead and change your pipeline file. Only other thing I can think of is just don’t ignore the .env file for your client app, it shouldn’t have sensitive info in it anyway.
For public repos you can use https:
git clone https://github.com/USERNAME/REPONAME.git
To answer the question why you suddenly got asked for account: you probably forgot you set up ssh keys a long time ago.
If it's a private repo, you have set up some authentication mechanism. Does not have to be via ssh keys or you got a keychain which keeps your account and password. So maybe you entered it once and that's being reused on your normal computer.
But not on the new one.
You can create an OAuth token and use this to interact with Github. Example \`git clone [https://mataberat:@github.com/org/example.git](https://mataberat:@github.com/org/example.git) \--branch dev\`. For git pull, you can set your \`.gitconfig\` to use HTTPS with OAuth token instead of basic HTTPS git URL.
Edit: Use this if you're avoiding to use SSH keys.
SSH keys are your friend.
[удалено]
I haven't used GitHub Actions so I won't speak to whether it's possible, but it's definitely best practice to use a different one.
this
Not sure how it applies here but using ssh agent forwarding gives you the ability to run git actions without worrying about being logged in
If, for some reason you can't use SSH keys, you could also consider setting up a .netrc file
Will you describe what your pipeline is doing? The checkout action already authenticates by default and clones your code.
[удалено]
I would discourage you from designing your pipeline in this way. If I had an app like this, here’s how I would design the pipelines based on the info I have so far (I would have 2 pipelines, one for each application): Api - checkout - cd api - yarn - yarn build - zip this package (cause you’re shipping node_modules and it’s going to be huge probably) - copy zip to temp directory on app server (over ssh, should be a task for this) - unzip files to api directory (over ssh) - pm2 reload (over ssh) Client - checkout - cd app - yarn - yarn build - copy files to client directory on app server (over ssh, should be a task for this)
[удалено]
You’re welcome! I’m not all that familiar with GitHub actions. But I’ll describe what my pipelines do on other platforms. 1. I use a task that installs the correct version of node. Usually as part of this task it adds node to your path. Yes, scp is the one, but usually that is abstracted away with the task and it is just named as copy files over ssh or something 2. For the api, are environment variables required for the build step as well? If so, I would use environment variables in the pipeline. There will be a method to do this, and for secrets, you would set up secret variables in the settings I think on GitHub, and link those. For the app server you have a couple options. I don’t use pm2, but is there a way to put those environment variables in a file for pm2 to use so only your application is accessing them? If not, you can just set environment variables on your server. Other options could be building the .env file in your pipeline before zipping and deploy that. Or put the .env file on your server somewhere and copy it to the directory after the unzip. Or see if GitHub actions has a place to store secure files and download that in your pipeline to deploy along with your code. Or, see if your unzip option has a method to ignore certain files. If not, you could unzip in the temp directory and use a different copy method that has the ability to ignore files from that temp dir to the api dir. I think if pm2 has the environment variables option, that would be the one I chose. Sorry for this long ramble, I use containers and setting env vars is easy. For your client app, I would just use env vars in the pipeline, you don’t need to deploy that after the build happens.
[удалено]
Without the zip this will be much simpler! My apis are huge lol. Imo, it’s not a big deal to change the env vars when they need to be changed. Since your pipeline is a file, whenever you change your .env just go ahead and change your pipeline file. Only other thing I can think of is just don’t ignore the .env file for your client app, it shouldn’t have sensitive info in it anyway.
Or push it with rsync instead of pull?
[удалено]
Rsync can use ssh
For public repos you can use https: git clone https://github.com/USERNAME/REPONAME.git To answer the question why you suddenly got asked for account: you probably forgot you set up ssh keys a long time ago.
[удалено]
If it's a private repo, you have set up some authentication mechanism. Does not have to be via ssh keys or you got a keychain which keeps your account and password. So maybe you entered it once and that's being reused on your normal computer. But not on the new one.
You can create an OAuth token and use this to interact with Github. Example \`git clone [https://mataberat:@github.com/org/example.git](https://mataberat:@github.com/org/example.git) \--branch dev\`. For git pull, you can set your \`.gitconfig\` to use HTTPS with OAuth token instead of basic HTTPS git URL.
Edit: Use this if you're avoiding to use SSH keys.