08-08-2024 12:56 PM
(Not exactly a LabVIEW question, but SCC, so hopefully this is a decent spot...)
My company currently uses a self-hosted SVN server for our SCC system. We use it for both LabVIEW code as well as C. It's been working great for us, but we have some new needs, and will be switching to a paid Github account soon.
We have a few things that we've made over the years that we'd like to open source (a Datagrid library, for instance). So, we're planning on having a public repository for this work. Some tools like the Github issue tracker would be a great addition to our team, so we'd like to utilize that as well.
However, we need to keep this development work private until we're ready to release it due to privacy concerns. For example, the Datagrid library itself is public, but it's used in a number of internal projects that cannot be public. How might we go about having a semi-public-but-not-entirely piece of software on Github?
Example workflow: Customer A needs us to make individual cells highlighted in green. It would be very nice to add a new issue to the issue tracker "Make cells highlightable due to Customer A's request on the XYZ project". However, we can't share the customer name publicly, and we can't discuss the XYZ project publicly. We'd like to be able to do all of our development work in a fully private repo- that way, we can add the issue to the tracker, discuss the reasoning behind it, add comments (e.g., "Tested and works for the XYZ project, issue closed"). Then, once it's working, we apply the new feature to the public code, with a simple commit entry "Now the cells can turn green!"
How might we go about setting that up?
08-08-2024 03:23 PM
I hate GIT so things like this are right in my blind spot. I am, however, interested in the results of this discussion since I am being forced to do pretty much the same thing.
08-08-2024 03:59 PM
No experience with this, but gitlab supports public forks of private repostitories.
08-08-2024 04:26 PM
@Quiztus2 wrote:
No experience with this, but gitlab supports public forks of private repostitories.
This would be ideal, but gitlab doesn't have some of the compliance stuff we have to have 😞
08-08-2024 04:33 PM
I'll outline 2 approaches: git-only (manual sync, 2 projects) and github (project permissions, 1 project)
08-09-2024 12:33 AM
Did you consider hosting your own gitlab server? This is not uncommon.
08-09-2024 12:35 PM
I wish it was an option, but we don't have the IT infrastructure to support such a thing. (We currently host our own SVN server, but we're moving things to professionally hosted solutions to help with the mountain of compliance requirements we have, which is a bit outside the scope of this post, but trust me it's a lot!)
08-16-2024 04:09 AM
@BertMcMahan wrote:
@Quiztus2 wrote:
No experience with this, but gitlab supports public forks of private repostitories.
This would be ideal, but gitlab doesn't have some of the compliance stuff we have to have 😞
We are pretty much doing this without any problems:
Of course, you cannot discuss why Person A of customer B for project C needs the feature XY in a ticket of an open source repository. But why would you do that? Just describe, that you want a feature that can highlight cells in colours. In the private customer issue where this feature request popped up, you just link to the ticket of the open source repo.
Maybe I didn't get the problem right. Your compliance prohibits exactly what?
08-19-2024 12:43 PM
Paying another webhoster would definitely solve our compliance issues. I didn't know Gitlab could be self-hosted, so thanks for that info. I can see if our cloud IT company can provide that, but we don't have the resources to fully run something self hosted on, for example, AWS. We'd need a company that can comply with our various legal requirements. There's probably SOMETHING out there, it'll just be whether or not it's worth the cost.
Customer to customer visibility is definitely one consideration, but the compliance stuff is the big one. The main thing there is ensuring absolutely no public visibility as well as some strict rules regarding hosting and who can get to the content, even in an IT setting. I think the term is "Fedramp"- currently, Github offers a Fedramp compliant hosting service, but Gitlab doesn't. Self-hosting would require us to get a Fedramp compliant host plus maintain everything, and we've been trying to offload IT stuff, so I don't think it'll fly. But I can certainly pitch it!