[12:14:17] <wm-bb>	 <nokibsarkar> hi, the issue at T422538 still not solved. Am I doing something wrong?
[12:23:45] <taavi>	 you cannot start a webservice if you already job with exact the name of the tool
[12:33:47] <wm-bb>	 <nokibsarkar> @taavi, then how can i run my webservice which was build using push to deploy?
[12:34:28] <taavi>	 as https://wikitech.wikimedia.org/wiki/Help:Toolforge/Deploy_your_tool says, web services are not yet supported on push-to-deploy
[12:36:29] <wm-bb>	 <nokibsarkar> Then, how come my campwiz-backend-dev is using push to deploy with webservice on?
[12:39:01] <taavi>	 it isn't
[12:39:27] <taavi>	 well, it is using push-to-deploy to start a separate job that hasn't anything to do with the webservice the tool is also running
[12:40:45] <wm-bb>	 <nokibsarkar> then how https://campwiz-backend-dev.toolforge.org/api/v2/user/me is reaching to the backend which i deployed?
[12:41:02] <wm-bb>	 <nokibsarkar> I am kind of confused, or doing something wrong here?
[12:42:01] <taavi>	 that webservice is built with the build service, but it was seemingly done manually and not with push-to-deploy
[12:42:45] <wm-bb>	 <nokibsarkar> O. let me verify it. if it is true, a lot of my questions might be answered.
[12:46:07] <wm-bb>	 <nokibsarkar> So, @taavi, images built using push to depoy is not same as images built manually using buildservice?
[12:50:11] <taavi>	 it will build the same images. but, in addition to just building the image, the push-to-deploy service will also create and manage the job using the image, and restart the job when the image is changed. the push-to-deploy service cannot build an image without also managing that job, and at the moment it can only manage jobs and not web services
[12:56:52] <wm-bb>	 <nokibsarkar> So, can i reuse the built image in webservice using toolforge webservice start --image ..... something like this?
[12:59:18] <taavi>	 you technically could, but unless you're also using the job managed with push-to-deploy, that's just a lot of added complexity and wasted resources compared to manually building the image with `toolforge build start`
[14:51:40] <wm-bb>	 <nokibsarkar> ssh: connect to host login.toolforge.org port 22: Connection refused
[14:52:06] <wm-bb>	 <nokibsarkar> ssh -4 -i id_rsa.toolforge "$USER@$HOST" 'bash -s' < deploy.sh
[14:53:12] <wm-bb>	 <nokibsarkar> any idea why this happened? I wanted to use gitlab CI to log into toolfrge, become the relevant tool, start building the image, restarting the webservice
[14:57:29] <wm-bb>	 <Gerges404> I'm using Github Actions: https://github.com/wiki-connect/wikimonitor/blob/main/.github/workflows/deploy.yml (re @nokibsarkar: any idea why this happened? I wanted to use gitlab CI to log into toolfrge, become the relevant tool, start building the image, ...)
[15:18:31] <wm-bb>	 <bd808> https://phabricator.wikimedia.org/T397888 (re @nokibsarkar: any idea why this happened? I wanted to use gitlab CI to log into toolfrge, become the relevant tool, start building the image, ...)
[15:20:11] <wm-bb>	 <nokibsarkar> Access Denied: Restricted Task
[15:23:05] <wm-bb>	 <bd808> Ugh. Sorry. The gist of that task is that the WMCS hosted gitlab-ci runners are not currently capable of connecting to other hosts on the internal WMCS network. If your job is using the Digital Ocean runners then that’s not what you are hitting however.
[18:26:42] <wm-bot>	 !log jeanfred@tools-bastion-15 tools.wikiloves Deploy 1f12fc8 (Update database query following categorylinks normalization) for T420408
[18:26:46] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.wikiloves/SAL
[19:52:32] <wm-bot>	 !log jeanfred@tools-bastion-15 tools.wikiloves Deploy 3f3c90198 (Fix query performance by using subquery instead of JOIN for linktarget) for T420408
[19:52:36] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.wikiloves/SAL