-
-
Notifications
You must be signed in to change notification settings - Fork 491
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gitpod: track remote trac branch #33589
Comments
comment:2
I think |
comment:3
Not sure if that's really a good idea. The git manual contains
Your idea was to prevent accidental commits to github, right? Would it be possible to restrict write access for the trac mirror repo to only allow the sync-hook to have write access? |
comment:4
It's already documented as standard procedure in |
comment:5
Where exactly? I can only find |
comment:6
Yes, that's the one. |
comment:7
This is already included in the gitpod config:
|
comment:8
No, the first line is setting the wrong URL for fetching. |
comment:9
I took this from the docs: https://doc.sagemath.org/html/en/developer/manual_git.html#the-trac-server
What is then the correct url? |
comment:10
Further up in the same section. |
comment:11
Does not work well. If you then push something to trac, VS still notifies you that there are changes between your local and remote branch. The reason is that VS invokes |
comment:12
OK. Then I'd suggest that we make switching to the ssh remote ( |
comment:13
We should probably also note this in the documentation (https://doc.sagemath.org/html/en/developer/manual_git.html) that the first configuration is not recommended for users who use VS Code. |
comment:14
Replying to @mkoeppe:
The point of this ticket was that this happens automatically for each ticket/gitpod session without manual intervention. |
comment:15
Replying to @mkoeppe:
What's the reason for this config in the first place? It is also against the git recommendations that I've cited above. |
comment:16
Replying to @tobiasdiez:
That's what read-only mirrors are for - they scale better than 1 read/write server. I don't think that recommendation that you found in the doc is intended to rule out mirrors. |
comment:17
Replying to @tobiasdiez:
I think we shouldn't force users to do the SSH key thing if all they want to do is fetch from trac. |
comment:18
Maybe it should be made conditional on |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:20
Replying to @mkoeppe:
Good suggestion, thanks. I've implemented that now. |
comment:21
That should be "-n "${PRIVATE_SSH_KEY}"` |
comment:22
Yes... |
comment:23
And everyone needs the |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:40
I've added comment:13 to #33088 |
comment:41
OK, that's a good solution too |
comment:42
I think all of these steps:
and
should be unconditional |
comment:43
Replying to @mkoeppe:
During the prebuild there is never a ssh key set, so the trac remote is always either unset or set to the github mirror.
Fetching trac doesn't work without ssh keys (at least for me). |
comment:44
Replying to @tobiasdiez:
It doesn't if the remote is ssh, which is why we have changed that. |
comment:45
I don't get what you want.
is in conflict with
Since the ssh setup is more involved for gitpod, its better in my opinion to explicitly tell the user that something is off so he might look this up in the docs. Ps: can we please migrate to github/gitlab; their server are beefy enough to don't need a special mirror setup ;-) |
comment:46
I mean like this (untested).
|
comment:47
That would work, I guess. But I fail to see the point of setting the upstream to "trac" even if you don't have the ssh keys configured. Why change the gitpod default? I would like to leave the whole trac remote business as minimal as possible. |
comment:48
Replying to @tobiasdiez:
Because it means that there are fewer differences between "without ssh key" and "with ssh key", which reduces the complexity in explaining it to developers? |
comment:49
If you cannot push anything, then you don't need to worry about trac at all. Everything you need is in "origin". The remove trac is only added because of the limitations of git-trac you mentioned above. |
comment:50
OK, I think this makes sense |
comment:51
Now if we also want to support a development model in which users use their own GitHub forks as |
comment:52
And I'd still prefer to move the line
to the very beginning so that it runs in both cases - it's easier to understand that it is correct |
comment:53
Replying to @mkoeppe:
Do you know how/with which credentials the sync hook pushes to the github mirror? Maybe its easy to setup a branch protection rule that would prevent any pushes to the mirror (except for the syncs). |
comment:54
No idea, sorry |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:57
According to
it is always |
comment:58
Replying to @mkoeppe:
I agree. |
Branch pushed to git repo; I updated commit sha1. New commits:
|
Reviewer: Matthias Koeppe |
comment:61
Thanks for the review and the many helpful suggestions! |
Changed branch from public/build/gitpod_trac_tracking to |
Currently, gitpod tracks the branch on github as the remote. Thus, one might accidentally changes to github instead of trac. With this ticket, the remote is changed to trac.
CC: @mkoeppe
Component: build
Author: Tobias Diez
Branch/Commit:
bbe8724
Reviewer: Matthias Koeppe
Issue created by migration from https://trac.sagemath.org/ticket/33589
The text was updated successfully, but these errors were encountered: