Conversation
The secret is simply named |
| # - 'package-lock.json' | ||
| # - 'package.json' | ||
| # - 'utils/deploy-toolforge.sh' | ||
| # - 'video2commons-socketio/**' |
There was a problem hiding this comment.
socketio is its own toolforge project, so we need to remove this line, and duplicate the deploy-toolforge script to have deploy-toolforge-video2commons and deploy-toolforge-video2commons-socketio. We could also add a fourth one for deploy-toolforge-video2commons-test.
Maybe we could push-to-deploy for "video2commons-test" automatically, and keep manual deployments for the the three production services.
There was a problem hiding this comment.
That makes sense to me! I didn't realize there was a test project. I'll update the patterns soon and work on a 3rd script. I do have a couple of questions.
- I noticed there's no test version of
video2commons-socketio. Is it used by both production and the testing environment, or is it not used at all byvideo2commons-test? - Does
video2commons-testuse the same encoders asvideo2commons?
There was a problem hiding this comment.
Oh, and one other question I forgot. How is the socketio service restarted? Or does it need to be restarted at all. I didn't see any mention of it in the Wikitech documentation.
There was a problem hiding this comment.
For 1, I don't remember, I think it uses the same as I don't remember having seen a socketio test account.
For 2, it uses the redis instance as an encoder. It's likely it doesn't work right now as nobody uses it, and I didn't touch it for a very long time. But you can give a try :) (with a small file of course): https://video2commons-test.toolforge.org/
There was a problem hiding this comment.
And how to restart the socketio service, mmmm good question!
There was a problem hiding this comment.
in the shell history I see I did that last year:
2025-01-19 17:14:52 toolforge webservice --backend=kubernetes node18 start
| V2C_USERNAME: ${{ secrets.V2C_USERNAME }} | ||
| V2C_REDIS_PW: ${{ secrets.V2C_REDIS_PW }} | ||
| V2C_CONSUMER_SECRET: ${{ secrets.V2C_CONSUMER_SECRET }} | ||
| V2C_CONSUMER_KEY: ${{ secrets.V2C_CONSUMER_KEY }} |
There was a problem hiding this comment.
These secrets don't exist yet, are you able to create them or do you want me to create them?
There was a problem hiding this comment.
I think I should be able to with my permissions. I'll let you know if I run into any problems.
There was a problem hiding this comment.
I added the secrets to the repository-level secrets. I don't have access to the environment-level secrets, which is where I assume SSH_PRIVATE_KEY is located. Is this fine?
There was a problem hiding this comment.
Also, I set V2C_USERNAME to adminv2c since that's what I saw in the membership requests.
There was a problem hiding this comment.
Ah strange, I must have missed something, I would prefer to set all secrets in the environment, I'm checking your permissions
There was a problem hiding this comment.
I've set you to maintainer role, is it enough now to have access to env secrets?
There was a problem hiding this comment.
OK now you're admin I can't give you more permissions :D Is it working?
There was a problem hiding this comment.
That seemed to do it. I'll get those updated here shortly 😅


Description
This patch adds GHA workflows for deploying to both the frontend (Toolforge) and encoders (Cloud VPS). This should help allow deployments to be easier for maintainers.
@don-vip I'll take this out of draft mode once we confirm some of the assumptions I'm making.
Changes
.gitignorefile as well.ci.ymlhave been removed. Thecheckjob just makes sure the build completes without any errors now.deploy-toolforge.sh.deploy.shtodeploy-encoders.shas there are now two deployment scripts.deploy-encoders.shscript to return a non-zero exit code if the deployment fails for any workers.TimeoutStopSec=infinityto thev2ccelery.serviceservice unit to make sure systemd never sends aSIGKILLto the workers before they complete.Disclaimers
The workflow assumes that the SSH key is stored in theV2C_SSH_PRIVATE_KEYsecret and uses ed25519. Please let me know if this needs to be changed.SSH_PRIVATE_KEY.