RE: [go-cd] Issues with backups on Go 22.2 and PostgreSQL v12

[chantryc]

Sure! I’d be happy to drop it in and see if that works! I can double check on 
the folder creation that way as well. I haven’t entirely worked out building 
the package myself so if you have an installer I can run or just the files to 
replace and instructions on where they need to go I’m happy to give it a run. 

 

Thanks!

 

From: go-cd@googlegroups.com  On Behalf Of Chad Wilson
Sent: Wednesday, November 2, 2022 11:05 AM
To: go-cd@googlegroups.com
Subject: Re: [go-cd] Issues with backups on Go 22.2 and PostgreSQL v12

 

With a bit of quick pg_dump testing on Windows (via choco install 
postgresql12/choco install postgresql14) without actually integrating with 
GoCD) I can confirm the utility complains about the order of the positional 
(non-option) dbname arguments in ways that the same utility on MacOS does not. 
Only checked v12 and v14.

So it seems we need to fix something on the server here. I have a draft fix at 
https://github.com/gocd/gocd/pull/10982 which should be easy to get into the 
next 22.3.0 release (we were planning to release shortly anyway), especially if 
you are willing to help with sanity testing backups on your trial Windows setup 
you are working on. 

-Chad

 

On Wed, Nov 2, 2022 at 11:13 PM Chad Wilson mailto:ch...@thoughtworks.com> > wrote:

Technically speaking, the docs say the dbname without --dbname= should be the 
last argument after all connection options, which GoCD doesn't respect. 
Possibly pg_dump is more flexible on other OSes than Windows?

If you move "gocd" to the end of the command line you will probably find it 
works.


If you can raise an issue with the specific details to make it easy to 
reproduce (I don't work with Windows much, so the easier the better) at 
https://github.com/gocd/gocd/issues it can probably be fixed/addressed with 
`--dbname=` prefix to be unambiguous.

You could try other versions of pg_dump and see if the behaviour is different 
as well.

 

-Chad

 

On Wed, Nov 2, 2022 at 10:46 PM Funkycybermonk mailto:chant...@gmail.com> > wrote:

It looks like the file version is 12.0.12.0.  I'm using the version that 
shipped with the PostgreSQL 12 installer. I can downgrade to a lower PostgreSQL 
version if this is an issue with this release of pg_dump.

 

The message I get when constructing the command line using as-is from the logs 
is:

 

"C:\Users\removed>pg_dump --no-password --host=localhost --port=5432 
--username=removed gocd --file="C:\Program Files (x86)\Go 
Server\artifacts\serverBackups\backup_20221101-202201\db.gocd"
pg_dump: error: too many command-line arguments (first is "--file=C:\Program 
Files (x86)\Go Server\artifacts\serverBackups\backup_20221101-202201\db.gocd")
Try "pg_dump --help" for more information."

 

I can make it work by adding the --dbname= in front of the gocd value although 
the directory has to be created before the path from the logs will work. I'm 
assuming thats because the process failed in GoCD so the folder was removed as 
cleanup. Creating the folder results in a successful db.gocd backup file being 
created.

 

Thanks!

On Wednesday, November 2, 2022 at 8:58:17 AM UTC-5 ketanpad...@gmail.com 
  wrote:

What version of pg_dump are you using? According to 
https://www.postgresql.org/docs/current/app-pgdump.html, the command line 
string looks OK. But we've not tested this on windows.

 

- Ketan

 

 

On Wed, Nov 2, 2022 at 4:31 AM Funkycybermonk mailto:chan...@gmail.com> > wrote:

Hello!

 

New upgrade going from GoCD 20.1 to 22.2 and migrated to PostgreSQL v12 on 
Windows. Everything is now working properly but the backups were blowing up due 
to not being able to find pg_dump. I added the bin for PostgreSQL to the system 
path and the backup exits with a status code 1. I went back and checked the 
command and it looks like it might be blowing up because the dbname isn't 
defined with a parameter name. 

 

The executing bit is showing [pg_dump, --no-password, --host=localhost, 
--port=5432, --username=, gocd, --file=C:\Program Files (x86)\Go 
Server\artifacts\serverBackups\backup_20221101-215455\db.gocd] with environment 
{PGPASSWORD=}

 

The gocd bit in the middle appears to be the dbname but its not qualified as 
--dbname. Is that a bug or is there something I haven't configured properly? If 
I take that parameter string and run it in a command prompt with the commas 
removed it blows up on the parameters not matching up. Adding the --dbname= to 
that parameter works for me but I'm not sure if that should be required. 

 

I can roll back to H2 but I was hoping there would be a performance improvement 
and future-proofing if I went ahead with the migration now. If that doesn't 
make sense then I'm happy to stay with H2.

 

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to go-cd+un...@googlegroups.com 

Re: [go-cd] Issues with backups on Go 22.2 and PostgreSQL v12

[Chad Wilson]

With a bit of quick pg_dump testing on Windows (via choco install
postgresql12/choco install postgresql14) without actually integrating with
GoCD) I can confirm the utility complains about the order of the positional
(non-option) dbname arguments in ways that the same utility on MacOS does
not. Only checked v12 and v14.

So it seems we need to fix something on the server here. I have a draft fix
at https://github.com/gocd/gocd/pull/10982 which should be easy to get into
the next 22.3.0 release (we were planning to release shortly anyway),
especially if you are willing to help with sanity testing backups on your
trial Windows setup you are working on.

-Chad

On Wed, Nov 2, 2022 at 11:13 PM Chad Wilson  wrote:

> Technically speaking, the docs say the dbname without --dbname= should be
> the last argument after all connection options, which GoCD doesn't respect.
> Possibly pg_dump is more flexible on other OSes than Windows?
>
> If you move "gocd" to the end of the command line you will probably find
> it works.
>
> If you can raise an issue with the specific details to make it easy to
> reproduce (I don't work with Windows much, so the easier the better) at
> https://github.com/gocd/gocd/issues it can probably be fixed/addressed
> with `--dbname=` prefix to be unambiguous.
>
> You could try other versions of pg_dump and see if the behaviour is
> different as well.
>
> -Chad
>
> On Wed, Nov 2, 2022 at 10:46 PM Funkycybermonk  wrote:
>
>> It looks like the file version is 12.0.12.0.  I'm using the version
>> that shipped with the PostgreSQL 12 installer. I can downgrade to a lower
>> PostgreSQL version if this is an issue with this release of pg_dump.
>>
>> The message I get when constructing the command line using as-is from the
>> logs is:
>>
>> "C:\Users\removed>pg_dump --no-password --host=localhost --port=5432
>> --username=removed gocd --file="C:\Program Files (x86)\Go
>> Server\artifacts\serverBackups\backup_20221101-202201\db.gocd"
>> pg_dump: error: too many command-line arguments (first is
>> "--file=C:\Program Files (x86)\Go
>> Server\artifacts\serverBackups\backup_20221101-202201\db.gocd")
>> Try "pg_dump --help" for more information."
>>
>> I can make it work by adding the --dbname= in front of the gocd value
>> although the directory has to be created before the path from the logs will
>> work. I'm assuming thats because the process failed in GoCD so the folder
>> was removed as cleanup. Creating the folder results in a successful db.gocd
>> backup file being created.
>>
>> Thanks!
>>
>> On Wednesday, November 2, 2022 at 8:58:17 AM UTC-5 ketanpad...@gmail.com
>> wrote:
>>
>>> What version of pg_dump are you using? According to
>>> https://www.postgresql.org/docs/current/app-pgdump.html, the command
>>> line string looks OK. But we've not tested this on windows.
>>>
>>> - Ketan
>>>
>>>
>>>
>>> On Wed, Nov 2, 2022 at 4:31 AM Funkycybermonk  wrote:
>>>
 Hello!

 New upgrade going from GoCD 20.1 to 22.2 and migrated to PostgreSQL v12
 on Windows. Everything is now working properly but the backups were blowing
 up due to not being able to find pg_dump. I added the bin for PostgreSQL to
 the system path and the backup exits with a status code 1. I went back and
 checked the command and it looks like it might be blowing up because the
 dbname isn't defined with a parameter name.

 The executing bit is showing [pg_dump, --no-password, --host=localhost,
 --port=5432, --username=, gocd, --file=C:\Program Files (x86)\Go
 Server\artifacts\serverBackups\backup_20221101-215455\db.gocd] with
 environment {PGPASSWORD=}

 The gocd bit in the middle appears to be the dbname but its not
 qualified as --dbname. Is that a bug or is there something I haven't
 configured properly? If I take that parameter string and run it in a
 command prompt with the commas removed it blows up on the parameters not
 matching up. Adding the --dbname= to that parameter works for me but I'm
 not sure if that should be required.

 I can roll back to H2 but I was hoping there would be a performance
 improvement and future-proofing if I went ahead with the migration now. If
 that doesn't make sense then I'm happy to stay with H2.

 Thanks!

 --
 You received this message because you are subscribed to the Google
 Groups "go-cd" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to go-cd+un...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/go-cd/1a7de3d6-8dae-4da0-b675-6d02ab885993n%40googlegroups.com
 
 .

>>> --
>> You received this message because you are subscribed to the Google Groups
>> "go-cd" group.
>> To unsubscribe from this group and stop receiving emails from it, 

Re: [go-cd] Issues with backups on Go 22.2 and PostgreSQL v12

[Chad Wilson]

Technically speaking, the docs say the dbname without --dbname= should be
the last argument after all connection options, which GoCD doesn't respect.
Possibly pg_dump is more flexible on other OSes than Windows?

If you move "gocd" to the end of the command line you will probably find it
works.

If you can raise an issue with the specific details to make it easy to
reproduce (I don't work with Windows much, so the easier the better) at
https://github.com/gocd/gocd/issues it can probably be fixed/addressed with
`--dbname=` prefix to be unambiguous.

You could try other versions of pg_dump and see if the behaviour is
different as well.

-Chad

On Wed, Nov 2, 2022 at 10:46 PM Funkycybermonk  wrote:

> It looks like the file version is 12.0.12.0.  I'm using the version
> that shipped with the PostgreSQL 12 installer. I can downgrade to a lower
> PostgreSQL version if this is an issue with this release of pg_dump.
>
> The message I get when constructing the command line using as-is from the
> logs is:
>
> "C:\Users\removed>pg_dump --no-password --host=localhost --port=5432
> --username=removed gocd --file="C:\Program Files (x86)\Go
> Server\artifacts\serverBackups\backup_20221101-202201\db.gocd"
> pg_dump: error: too many command-line arguments (first is
> "--file=C:\Program Files (x86)\Go
> Server\artifacts\serverBackups\backup_20221101-202201\db.gocd")
> Try "pg_dump --help" for more information."
>
> I can make it work by adding the --dbname= in front of the gocd value
> although the directory has to be created before the path from the logs will
> work. I'm assuming thats because the process failed in GoCD so the folder
> was removed as cleanup. Creating the folder results in a successful db.gocd
> backup file being created.
>
> Thanks!
>
> On Wednesday, November 2, 2022 at 8:58:17 AM UTC-5 ketanpad...@gmail.com
> wrote:
>
>> What version of pg_dump are you using? According to
>> https://www.postgresql.org/docs/current/app-pgdump.html, the command
>> line string looks OK. But we've not tested this on windows.
>>
>> - Ketan
>>
>>
>>
>> On Wed, Nov 2, 2022 at 4:31 AM Funkycybermonk  wrote:
>>
>>> Hello!
>>>
>>> New upgrade going from GoCD 20.1 to 22.2 and migrated to PostgreSQL v12
>>> on Windows. Everything is now working properly but the backups were blowing
>>> up due to not being able to find pg_dump. I added the bin for PostgreSQL to
>>> the system path and the backup exits with a status code 1. I went back and
>>> checked the command and it looks like it might be blowing up because the
>>> dbname isn't defined with a parameter name.
>>>
>>> The executing bit is showing [pg_dump, --no-password, --host=localhost,
>>> --port=5432, --username=, gocd, --file=C:\Program Files (x86)\Go
>>> Server\artifacts\serverBackups\backup_20221101-215455\db.gocd] with
>>> environment {PGPASSWORD=}
>>>
>>> The gocd bit in the middle appears to be the dbname but its not
>>> qualified as --dbname. Is that a bug or is there something I haven't
>>> configured properly? If I take that parameter string and run it in a
>>> command prompt with the commas removed it blows up on the parameters not
>>> matching up. Adding the --dbname= to that parameter works for me but I'm
>>> not sure if that should be required.
>>>
>>> I can roll back to H2 but I was hoping there would be a performance
>>> improvement and future-proofing if I went ahead with the migration now. If
>>> that doesn't make sense then I'm happy to stay with H2.
>>>
>>> Thanks!
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "go-cd" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to go-cd+un...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/go-cd/1a7de3d6-8dae-4da0-b675-6d02ab885993n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "go-cd" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to go-cd+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/go-cd/991c4de4-b112-4fc9-a8ed-4a8e3a2bdd3an%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to go-cd+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/go-cd/CAA1RwH_yuQ_N7j1OmE1G7h80euXBv2bbCJvAuPqG%3D0SY-KdbMw%40mail.gmail.com.

Re: [go-cd] Issues with backups on Go 22.2 and PostgreSQL v12

[Funkycybermonk]

It looks like the file version is 12.0.12.0.  I'm using the version 
that shipped with the PostgreSQL 12 installer. I can downgrade to a lower 
PostgreSQL version if this is an issue with this release of pg_dump.

The message I get when constructing the command line using as-is from the 
logs is:

"C:\Users\removed>pg_dump --no-password --host=localhost --port=5432 
--username=removed gocd --file="C:\Program Files (x86)\Go 
Server\artifacts\serverBackups\backup_20221101-202201\db.gocd"
pg_dump: error: too many command-line arguments (first is 
"--file=C:\Program Files (x86)\Go 
Server\artifacts\serverBackups\backup_20221101-202201\db.gocd")
Try "pg_dump --help" for more information."

I can make it work by adding the --dbname= in front of the gocd value 
although the directory has to be created before the path from the logs will 
work. I'm assuming thats because the process failed in GoCD so the folder 
was removed as cleanup. Creating the folder results in a successful db.gocd 
backup file being created.

Thanks!

On Wednesday, November 2, 2022 at 8:58:17 AM UTC-5 ketanpad...@gmail.com 
wrote:

> What version of pg_dump are you using? According to 
> https://www.postgresql.org/docs/current/app-pgdump.html, the command line 
> string looks OK. But we've not tested this on windows.
>
> - Ketan
>
>
>
> On Wed, Nov 2, 2022 at 4:31 AM Funkycybermonk  wrote:
>
>> Hello!
>>
>> New upgrade going from GoCD 20.1 to 22.2 and migrated to PostgreSQL v12 
>> on Windows. Everything is now working properly but the backups were blowing 
>> up due to not being able to find pg_dump. I added the bin for PostgreSQL to 
>> the system path and the backup exits with a status code 1. I went back and 
>> checked the command and it looks like it might be blowing up because the 
>> dbname isn't defined with a parameter name. 
>>
>> The executing bit is showing [pg_dump, --no-password, --host=localhost, 
>> --port=5432, --username=, gocd, --file=C:\Program Files (x86)\Go 
>> Server\artifacts\serverBackups\backup_20221101-215455\db.gocd] with 
>> environment {PGPASSWORD=}
>>
>> The gocd bit in the middle appears to be the dbname but its not qualified 
>> as --dbname. Is that a bug or is there something I haven't configured 
>> properly? If I take that parameter string and run it in a command prompt 
>> with the commas removed it blows up on the parameters not matching up. 
>> Adding the --dbname= to that parameter works for me but I'm not sure if 
>> that should be required. 
>>
>> I can roll back to H2 but I was hoping there would be a performance 
>> improvement and future-proofing if I went ahead with the migration now. If 
>> that doesn't make sense then I'm happy to stay with H2.
>>
>> Thanks!
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "go-cd" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to go-cd+un...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/go-cd/1a7de3d6-8dae-4da0-b675-6d02ab885993n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to go-cd+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/go-cd/991c4de4-b112-4fc9-a8ed-4a8e3a2bdd3an%40googlegroups.com.

Re: [go-cd] Issues with backups on Go 22.2 and PostgreSQL v12

[Ketan Padegaonkar]

What version of pg_dump are you using? According to
https://www.postgresql.org/docs/current/app-pgdump.html, the command line
string looks OK. But we've not tested this on windows.

- Ketan



On Wed, Nov 2, 2022 at 4:31 AM Funkycybermonk  wrote:

> Hello!
>
> New upgrade going from GoCD 20.1 to 22.2 and migrated to PostgreSQL v12 on
> Windows. Everything is now working properly but the backups were blowing up
> due to not being able to find pg_dump. I added the bin for PostgreSQL to
> the system path and the backup exits with a status code 1. I went back and
> checked the command and it looks like it might be blowing up because the
> dbname isn't defined with a parameter name.
>
> The executing bit is showing [pg_dump, --no-password, --host=localhost,
> --port=5432, --username=, gocd, --file=C:\Program Files (x86)\Go
> Server\artifacts\serverBackups\backup_20221101-215455\db.gocd] with
> environment {PGPASSWORD=}
>
> The gocd bit in the middle appears to be the dbname but its not qualified
> as --dbname. Is that a bug or is there something I haven't configured
> properly? If I take that parameter string and run it in a command prompt
> with the commas removed it blows up on the parameters not matching up.
> Adding the --dbname= to that parameter works for me but I'm not sure if
> that should be required.
>
> I can roll back to H2 but I was hoping there would be a performance
> improvement and future-proofing if I went ahead with the migration now. If
> that doesn't make sense then I'm happy to stay with H2.
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "go-cd" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to go-cd+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/go-cd/1a7de3d6-8dae-4da0-b675-6d02ab885993n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to go-cd+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/go-cd/CAMUPJd4bOJ4114zTdBLpeF5KKqia%2BK1qXVeLiEne3TNQ8ufNeg%40mail.gmail.com.

Re: [go-cd] Need help in resolving few issues with GoCD 20.4

[SATYA R]

Hi Ashwanth,

Thanks alot for the quick response.
Here is what i found from the server.log

*2022-11-02 08:43:20,092 WARN [131@MessageListener for 
MaterialUpdateListener] MaterialDatabaseUpdater:127 - [Material Update] 
Modification check failed for material: URL: 
gitit.l\tcom:flsndfydta/flydtadhgyplayfgheagit, Branch: master*
*java.lang.RuntimeException: Working directory: 
pipelines/flyweight/1d3077c5-8571-4a73-a87c-cecf44e5c5fe*
*STDERR: kex_exchange_identification: read: Connection reset by peer*
*STDERR: fatal: Could not read from remote repository.*
*STDERR: *
*STDERR: Please make sure you have the correct access rights*
*STDERR: and the repository exists.*

Is the error occurring because of this flyweight?

Regrading the GoConfig changes:
The old server was configured by some other person who is now not in the 
project.
Usually do we create a custom cron job to push GoConfig changes to gitlab? 
if yes, can you please let us know to which path we should set up the cron? 

Thanks in advance.




On Wednesday, November 2, 2022 at 6:10:17 AM UTC-4 ashwant...@gmail.com 
wrote:

> From the attached screenshot the error seems like something to do with a 
> network configuration. 
>
> > kex_exchange_identification: read: Connection reset by peer
>
> First answer on SO  also says the 
> same. Also if you can check the go-server.log, it might have additional 
> details which might be useful to debug as well. See if you can share those 
> after masking any sensitive details. 
>
> From the GoCD Docs 
> , the 
> config.git is not pushed by GoCD to a remote. We usually have a cron that 
> runs on the server machine that periodically does a `git push`. Do you know 
> how you were doing this with v18.x series earlier?
>
> Thanks,
>
>
> On Wed, 2 Nov 2022 at 15:30, SATYA R  wrote:
>
>> Hi Everyone,
>>
>> Recently our GoCD 18.8 server got destroyed and we installed new version 
>> of GoCD 20.4 in new mac server and restored the backup of 18.8.
>> We are able to get all the pipelines back and running. But we are facing 
>> few issues with the new server.
>>
>> 1. The pipelines Auto-trigger is not happening immediately, it is taking 
>> lot of time to get auto-triggered. And whenever we do test connection in 
>> materials it always  fails with an error. PFA after many refreshes we get 
>> "OK" connection message.
>> 2. Sometimes even when we try to trigger the pipelines manually, they 
>> don't run, after so many refreshes they run, we have to hit run button 
>> multiple times to make them run.
>> 3. After our old GoCD18.8 is crashed, the config.xml changes are not 
>> getting committed to GoConfig.git repo in GitLab.
>>
>> Kindly help us resolving the above issues.
>>
>> Thanks,
>> Srikala Rekapalli.
>> DevOps.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "go-cd" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to go-cd+un...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/go-cd/0f7f723b-23bd-416c-a9e1-ec585dcb7a38n%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
>
> Ashwanth Kumar / ashwanthkumar.in
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to go-cd+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/go-cd/0d437f59-4e9b-463f-9dda-328eefacc612n%40googlegroups.com.

Re: [go-cd] Need help in resolving few issues with GoCD 20.4

['Ashwanth Kumar' via go-cd]

>From the attached screenshot the error seems like something to do with a
network configuration.

> kex_exchange_identification: read: Connection reset by peer

First answer on SO  also says the
same. Also if you can check the go-server.log, it might have additional
details which might be useful to debug as well. See if you can share those
after masking any sensitive details.

>From the GoCD Docs
, the
config.git is not pushed by GoCD to a remote. We usually have a cron that
runs on the server machine that periodically does a `git push`. Do you know
how you were doing this with v18.x series earlier?

Thanks,


On Wed, 2 Nov 2022 at 15:30, SATYA R  wrote:

> Hi Everyone,
>
> Recently our GoCD 18.8 server got destroyed and we installed new version
> of GoCD 20.4 in new mac server and restored the backup of 18.8.
> We are able to get all the pipelines back and running. But we are facing
> few issues with the new server.
>
> 1. The pipelines Auto-trigger is not happening immediately, it is taking
> lot of time to get auto-triggered. And whenever we do test connection in
> materials it always  fails with an error. PFA after many refreshes we get
> "OK" connection message.
> 2. Sometimes even when we try to trigger the pipelines manually, they
> don't run, after so many refreshes they run, we have to hit run button
> multiple times to make them run.
> 3. After our old GoCD18.8 is crashed, the config.xml changes are not
> getting committed to GoConfig.git repo in GitLab.
>
> Kindly help us resolving the above issues.
>
> Thanks,
> Srikala Rekapalli.
> DevOps.
>
> --
> You received this message because you are subscribed to the Google Groups
> "go-cd" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to go-cd+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/go-cd/0f7f723b-23bd-416c-a9e1-ec585dcb7a38n%40googlegroups.com
> 
> .
>


-- 

Ashwanth Kumar / ashwanthkumar.in

-- 
You received this message because you are subscribed to the Google Groups 
"go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to go-cd+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/go-cd/CAD9m7CxVb%2BPr%3DW1R6AkpUQi%3DSCtud-%2BHAbicNwx5T4bqdp0GvQ%40mail.gmail.com.

[go-cd] Need help in resolving few issues with GoCD 20.4

[SATYA R]

Hi Everyone,

Recently our GoCD 18.8 server got destroyed and we installed new version of 
GoCD 20.4 in new mac server and restored the backup of 18.8.
We are able to get all the pipelines back and running. But we are facing 
few issues with the new server.

1. The pipelines Auto-trigger is not happening immediately, it is taking 
lot of time to get auto-triggered. And whenever we do test connection in 
materials it always  fails with an error. PFA after many refreshes we get 
"OK" connection message.
2. Sometimes even when we try to trigger the pipelines manually, they don't 
run, after so many refreshes they run, we have to hit run button multiple 
times to make them run.
3. After our old GoCD18.8 is crashed, the config.xml changes are not 
getting committed to GoConfig.git repo in GitLab.

Kindly help us resolving the above issues.

Thanks,
Srikala Rekapalli.
DevOps.

-- 
You received this message because you are subscribed to the Google Groups 
"go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to go-cd+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/go-cd/0f7f723b-23bd-416c-a9e1-ec585dcb7a38n%40googlegroups.com.