21 Apr 2021 |
_hc | izzy: jochensp I gave you both maintainer access to trackingthetrackers/rfp and wrote up the instructions on how to run your fork in the README: https://gitlab.com/trackingthetrackers/rfp | 08:37:27 |
_hc | its relatively easy to setup a repo like that, if you want your own | 08:38:14 |
_hc | I could set it up | 08:38:17 |
@rdfg77:kde.org | Do you know why https://gitlab.com/fdroid/fdroiddata/-/merge_requests/8838 CI failed? Looks like the CI try to publish it? | 08:40:28 |
@rdfg77:kde.org | ++ ./tools/should-run-publish.py cz.hernik.kaku:1
ERROR: no signatures found | 08:40:44 |
_hc | linsui: hmm, looks like a bug in my recent commit, looking now | 08:47:12 |
izzy | <have you seen this account> at least gives a real name which is clearly not connected to me. Btw, I only chose IzzySoft back then because "Izzy" was occupied already. Must have been free in between as it's now "owned" by a GitLab team member since January 2021 (that member has multiple accounts but doesn't seem interested in giving me my favorite). | 08:47:24 |
_hc | here's the first run with it set to izzysoft fork: https://gitlab.com/trackingthetrackers/rfp/-/pipelines/289803400 | 08:51:53 |
izzy | <wrote up the instructions> thanks! That means we'd fork the repo and work on the fork? Because otherwise, "conflicting access" (if all 3 of us change that ISSUEBOT_FORK var, 2 out of 3 will have a "surprise"). | 09:15:18 |
izzy | linsui: maybe author has set up to produce a "signed APK", but we of course do not have their keys? Wouldn't be the first time. That was some setting in build.gradle IIRC. | 09:17:07 |
izzy | _hc: <here's the first run with it set to izzysoft fork> The errors can be ignored? And I wonder why it didn't mention my scanner module. | 09:19:42 |
izzy | Ah, I no longer wonder that. I didn't push master to my fork (done now) #D | 09:21:42 |
izzy | Just retrying the pipeline now… | 09:22:29 |
_hc | should work | 09:24:43 |
_hc | linsui: I think I fixed it https://gitlab.com/hernikplays/fdroiddata/-/jobs/1198756796 | 09:24:49 |
izzy | Good idea to echo the ISSUEBOT_FORK var _o/ | 09:24:52 |
izzy | bash: npm: command not found | 09:27:36 |
izzy | No APK then to scan I'm afraid. Maybe I pick some other app and try again. Btw: is it possible to point ISSUEBOT_FORK to a branch, so one doesn't have to mess up master? | 09:29:34 |
izzy | Or have it use a specific branch (by whatever name) in general? | 09:31:40 |
_hc | the existing workflow is to use master in your fork for testing there, I'd like to keep it that way, otherwise it gets confusing what is running where | 09:34:00 |
izzy | So we'd have to push "experimental changes" to our forks' master then. Maybe I miss something here, but I have no idea how to clean that up afterwards to pull changes from the "real master" afterwards. Wouldn't it be much easier to use a dedicated branch for that, like "ttt" or "trackingthetrackers"? If I then break something, I can simply drop the branch and re-created it from an up-to-date master. | 09:53:14 |
jochensp | izzy: git push --force-with-lease fork origin/master:master | 09:54:45 |
jochensp | (with fork = your alias to the fork remote) | 09:55:24 |
izzy | jochensp: thanks, but I still miss a point: I've messed up my "local" master. How do I get that reset to the recent "upstream" master so I can force-push it? And isn't "master" protected so I cannot force-push anyway? | 09:56:59 |
jochensp | git reset --hard origin/master and for your fork you can unprotect master | 09:57:38 |
izzy | "origin" is my own fork – so to what is my local copy reset then? | 09:58:43 |
jochensp | origin should be https://gitlab.com/fdroid/issuebot/, fork (or izzy) should be your fork | 09:59:14 |
jochensp | see man git-remote | 09:59:36 |
izzy | OK, so as "origin" for me is always my own and "upstream" would be the "outside connection", I had to use "git reset --hard upstream/master" (to reset my local copy to what comes from fdroid), right? | 10:00:52 |
jochensp | that works as well | 10:01:30 |