Hi all (but sorry, Iohannes really) -
I'm back i nteh state where I can't push to github (I'm merging stuff on my own machine and "git push origin --tags" says it's synced but github still doesn't see the new commits I've made, or the tags. So now I'm making a new branch "pure-data/temporary-merge", pushing that successfully, then whacking buttins on the github site to merge it into master. This is stupid and I'd like to find the underlying problem but I'm stumped at the moment.
Meanwhile, though, I've managed now to get github to see my "0.53-0test3" commit, and its tag, but now it doesn't show up on the CI system at https://git.iem.at/pd/pure-data/-/pipelines.
... I think this might be related to the first problem and the way I'm trying to work around it, but I could be wrong about that.
Anyhow, if anyone can tell me what I have to do now to get the CI system to see and compile 0.53-0test3 I'd love to hear it.
thanks Miller
... and the problem sems to be fixed now by some invisible hand, probably Iohannes :)
On Mon, Oct 24, 2022 at 08:15:23AM -0700, Miller Puckette via Pd-dev wrote:
Hi all (but sorry, Iohannes really) -
I'm back i nteh state where I can't push to github (I'm merging stuff on my own machine and "git push origin --tags" says it's synced but github still doesn't see the new commits I've made, or the tags. So now I'm making a new branch "pure-data/temporary-merge", pushing that successfully, then whacking buttins on the github site to merge it into master. This is stupid and I'd like to find the underlying problem but I'm stumped at the moment.
Meanwhile, though, I've managed now to get github to see my "0.53-0test3" commit, and its tag, but now it doesn't show up on the CI system at https://urldefense.com/v3/__https://git.iem.at/pd/pure-data/-/pipelines__;!!... .
... I think this might be related to the first problem and the way I'm trying to work around it, but I could be wrong about that.
Anyhow, if anyone can tell me what I have to do now to get the CI system to see and compile 0.53-0test3 I'd love to hear it.
thanks Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
On 10/24/22 17:15, Miller Puckette via Pd-dev wrote:
Hi all (but sorry, Iohannes really) -
i'm not entirely surewhat you mean by this. i do get your emails via the mailinglist.
I'm back i nteh state where I can't push to github (I'm merging stuff on my own machine and "git push origin --tags" says it's synced but github still doesn't see the new commits I've made, or the tags. So now I'm making a new branch "pure-data/temporary-merge", pushing that successfully, then whacking buttins on the github site to merge it into master. This is stupid and I'd like to find the underlying problem but I'm stumped at the moment.
that's indeed weird. it might be totally unrelated, but i have seen outages of the github webinterface in the past weeks. so maybe the simple solution is just to wait a bit longer?
also, i think a better monitor of the repo is to just do a local clone besides your "work repository", and see what you get back (that is: whether all the tags and commits you expect are there)
Meanwhile, though, I've managed now to get github to see my "0.53-0test3" commit, and its tag, but now it doesn't show up on the CI system at https://git.iem.at/pd/pure-data/-/pipelines.
... I think this might be related to the first problem and the way I'm trying to work around it, but I could be wrong about that.
git.iem.at takes a while to sync to github. it basically works like this: - you push to https://github.com/pure-data/pure-data/ - gitlab.com regularly *polls* the github repository for new changes - if there any new changes it pulls them into https://gitlab.com/pure-data/pure-data - it then pushes these changes to https://git.iem.at/pd/pure-data - this triggers the CI on git.iem.at
this was the easiest system to setup, as github does not allow for push mirroring¹ (you *can* do that with a github-"action" (aka CI job), but it's much more complicated to do it manually and requires changes to the repository itself (which i don't really like) and needs to be guarded against forks), and the free community edition of gitlab (that is powering git.iem.at) does not allow for pull mirroring².
maybe things have changed a bit since i originally setup the mirroring and they could be simplified.
gfmdsar IOhannes
¹ push mirroring: whenever the repository receives changes, they are automatically pushed to another repository ² pull mirroring: a repository watches another repository for changes and pulls them.
I meant "here for all to see but of course Iohannes is the only person who's likely to have a good answer"...
and... yep, i tried pushing and tehn cloning and got nothing. The only way I've found to push stuff to github is to push on a separate branch and then merge via the github site itself. The problems started only a couple of days ago.
I can live with the current situation but it does pollute the repository with unnecessary commits, so someday I hope to figure out what's going on.
Anyhow, currently I think things are on track for me to make the current test version into the official 0.53-0.
thanks M
On Mon, Oct 24, 2022 at 05:46:21PM +0200, IOhannes m zmölnig wrote:
On 10/24/22 17:15, Miller Puckette via Pd-dev wrote:
Hi all (but sorry, Iohannes really) -
i'm not entirely surewhat you mean by this. i do get your emails via the mailinglist.
I'm back i nteh state where I can't push to github (I'm merging stuff on my own machine and "git push origin --tags" says it's synced but github still doesn't see the new commits I've made, or the tags. So now I'm making a new branch "pure-data/temporary-merge", pushing that successfully, then whacking buttins on the github site to merge it into master. This is stupid and I'd like to find the underlying problem but I'm stumped at the moment.
that's indeed weird. it might be totally unrelated, but i have seen outages of the github webinterface in the past weeks. so maybe the simple solution is just to wait a bit longer?
also, i think a better monitor of the repo is to just do a local clone besides your "work repository", and see what you get back (that is: whether all the tags and commits you expect are there)
Meanwhile, though, I've managed now to get github to see my "0.53-0test3" commit, and its tag, but now it doesn't show up on the CI system at https://git.iem.at/pd/pure-data/-/pipelines.
... I think this might be related to the first problem and the way I'm trying to work around it, but I could be wrong about that.
git.iem.at takes a while to sync to github. it basically works like this:
- you push to https://github.com/pure-data/pure-data/
- gitlab.com regularly *polls* the github repository for new changes
- if there any new changes it pulls them into https://gitlab.com/pure-data/pure-data
- it then pushes these changes to https://git.iem.at/pd/pure-data
- this triggers the CI on git.iem.at
this was the easiest system to setup, as github does not allow for push mirroring¹ (you *can* do that with a github-"action" (aka CI job), but it's much more complicated to do it manually and requires changes to the repository itself (which i don't really like) and needs to be guarded against forks), and the free community edition of gitlab (that is powering git.iem.at) does not allow for pull mirroring².
maybe things have changed a bit since i originally setup the mirroring and they could be simplified.
gfmdsar IOhannes
¹ push mirroring: whenever the repository receives changes, they are automatically pushed to another repository ² pull mirroring: a repository watches another repository for changes and pulls them.
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Hi all (but sorry, miller really) -
On 10/24/22 17:46, IOhannes m zmölnig wrote:
maybe things have changed a bit since i originally setup the mirroring and they could be simplified.
so i've re-evaluated the options for synching, and it seems i have found a solution that is now somewhat faster (whenever you push something to github, our CI is now notified directly¹ that it should sync again).
i also tried to push some tags directly to the 'master' branch on github, and they immediately showed up. either the issue miller was having has been resolved magically on the github side, or it is really something odd going on with miller's pushes. if the problem still persists, there's also the option to create a tag directly via the webinterface which you (miller) could use instead of the temporary branch dance.
gmdsar IOhannes
¹ well "more directly" at least. our git-server recieves a notification that it should sync, then a CI job is run that syncs the repositories which in turn triggers another CI run that re-builds whatever needs rebuilding)
That woulds like a good change.
Meanwhile, whatever problem I was having pushing to github seems to have vanished now.
cheers M
On Wed, Oct 26, 2022 at 05:05:55PM +0200, IOhannes m zmölnig wrote:
Hi all (but sorry, miller really) -
On 10/24/22 17:46, IOhannes m zmölnig wrote:
maybe things have changed a bit since i originally setup the mirroring and they could be simplified.
so i've re-evaluated the options for synching, and it seems i have found a solution that is now somewhat faster (whenever you push something to github, our CI is now notified directly¹ that it should sync again).
i also tried to push some tags directly to the 'master' branch on github, and they immediately showed up. either the issue miller was having has been resolved magically on the github side, or it is really something odd going on with miller's pushes. if the problem still persists, there's also the option to create a tag directly via the webinterface which you (miller) could use instead of the temporary branch dance.
gmdsar IOhannes
¹ well "more directly" at least. our git-server recieves a notification that it should sync, then a CI job is run that syncs the repositories which in turn triggers another CI run that re-builds whatever needs rebuilding)
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
-
IOhannes m zmölnig -
Miller Puckette