The flyweight is just a temporary repository clone the GoCD server creates to keep track of changes on the remote repository and work out which pipelines need triggering due to changes.
If you are getting "connection reset by peer" I suggest you investigate the network connectivity to that "peer" - which is the Git repository manager the material points to. This is a generic SSH error from a Git SSH clone, and is unlikely to be a GoCD issue. You can try doing a regular `git clone <gitSshUri>` of the same material into a temp folder on the server - you'll probably find it fails the same way since GoCD just uses the server's git binary and SSH config to do such clones. If it is a sporadic problem you are getting, you might be getting rate limited by the remote Git repository manager. That may also explain why pipelines are taking a long time to be triggered. If you have recreated a server with many pipelines/materials (and or many configuration repositories) you might overload your git repository manager while doing an initial re-clone. Perhaps not relevant if your server has been back up for a while now. Suggest you monitor resource usage of the target server and/or GoCD anyway. As Ashwanth says, there is no logic built into GoCD to push the configuration history to a remote repository, so you can do it however works for you. On MacOS it should be in <installDir>/db/config.git unless you have overridden any storage locations at start-up. -Chad On Wed, Nov 2, 2022 at 9:00 PM SATYA R <satya96...@gmail.com> wrote: > 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 <https://stackoverflow.com/a/69398009> 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 >> <https://docs.gocd.org/current/advanced_usage/config_repo.html>, 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 <satya...@gmail.com> 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 >>> <https://groups.google.com/d/msgid/go-cd/0f7f723b-23bd-416c-a9e1-ec585dcb7a38n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> >> 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 > <https://groups.google.com/d/msgid/go-cd/0d437f59-4e9b-463f-9dda-328eefacc612n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAA1RwH9yU0dfRwChnFG-t6043duUQYawtRejN1uX5Gk3yn5vUA%40mail.gmail.com.