zed-industries
Handle differently named zed remote in scripts
I contribute to zed from a fork so the "main" remote which these scripts should run against is called upstream instead of main. This change should handle arbitrary remote names by checking which one points to this repository.
Release Notes:
- N/A
@P1n3appl3 Is there a reason you need to be on a fork and not contributing from the main repo?
Some of these changes might be innocuous, but I don't think we should allow collab deploys, etc. from not zed-industries/zed, to be perfectly honest.
No real reason. I just prefer to use a fork cuz it's the more usual way to contribute and it surfaces some bugs like #13511 where things only work for our team.
I don't think we should allow collab deploys, etc. from not zed-industries/zed, to be perfectly honest
That's kinda what this PR is doing right? Making sure that I bump/deploy stuff on zed-industries/zed instead of another remote. I'm fine with not landing this though, the only one I think I need is bump-nightly and I can just do that by hand.
I don't think we should allow collab deploys, etc. from not zed-industries/zed, to be perfectly honest
That's kinda what this PR is doing right?
I more mean that we don't want users on forks trying to push tags to not their own forks.
While this should be prevented by GitHub's access control, we do have some community members who have write access on our repo, and this could make it easy to accidentally push a tag to our repo unintentionally.
In my mind the bigger thing is the expectation of what should work where. These scripts are only intended for Zed staff to use, and IMO Zed staff should be contributing directly to the repo instead of from forks.
For one, needing to interact with a Git branch from a fork is more trouble than one that is in the repo, which can became an impediment to collaboration. It's a necessary pain point for community PRs, but I think that if we can avoid it for within the Zed team, we should.
@maxdeviant I disagree that Julia’s setup is undesirable. Fundamentally, working from a fork is the primary way that open source work is done on github. And, until Julia joined and began working from her fork, this bug went unaddressed. Having Zed developers use a wide variety of setups is essential for continual monitoring. If we genuinely don’t trust some community members who have write access, then we should be fixing our processes or removing them from this repository. Making the scripts slightly less convenient for Zed staff isn’t a sound solution to the problem.
needing to interact with a Git branch from a fork is more trouble than one that is in the repo, which can became an impediment to collaboration
fwiw I publish branches I'm collaborating on to upstream rather than origin, I use the latter for quick fixes and features I'm working on by myself.
this could make it easy to accidentally push a tag to our repo unintentionally
not sure I follow: if someone has write access to our repo they can set the remote name as origin if they want and they'll be able to bump nightly.
I'm fine with continuing to bump nightly manually for now, I don't need to run the more complex deployment scripts much anyways.