Community
Participate
Working Groups
I am opening this bug as a continuation of bug 496335. The Eclipse Platform has a complicated build process, since we must (currently) build repositories from a number of projects (equinox, jdt, pde, and platform) and we want to occasionally "tag" the repositories we build during the build. I do not know if anyone else has that complicated a system, or, if they are that concerned about "tagging" the repositories during the build, but if so, then a generalized solution would be helpful. = = = = = = I mostly wanted to open this now, to provide some "tips" and possibilities before I forgot, but there is nothing particular I need (any longer). First, even for the simple case of "one project build" wants to "tag their own project repositories they build" then I think two things would make this pretty simple and automatic: A. The "genie.<user>" should have their ${HOME}/.gitconfig set up with their genie<user> as the git user.name, and similar for the email address of that user. Currently, if I look at git config --global --list for our Releng HIPP I see user.name=hudson user.email=hudsonbuild@hudson.eclipse.org I assume that is the same for all HIPP instances. That won't be helpful to anyone, and if anything, should start off as user.name=genie.<user> user.email=genie.<user>@eclipse.org or similar for every "HIPP instance user". That could just become part of the standard setup procedure for HIPP instances. B. The other thing that would make the "simple case" easier is if there was be a git "hook" that prohibited "commits" from this user for anything other than tags (possibly branches). That is, no "code". I am not sure how to write such a hook, but pretty sure it would be doable. This would be an improvement over one "protection" mechanism mentioned by Wayne in bug 496335 -- which would be to have the IP Log software check that the "genie user" committed/authored nothing but tags, no code. It would not hurt to have both mechanisms, but the "hook" prevents people from making the mistake in the first place. The IP Log tool check would spot cases where people found a way around the hook :/ or their repository was not set up correctly. = = = = = = I suspect technically, the above could be applied to the more complicated cases (one HIPP user to multiple project repositories) except the "hook" would be a little more complicated, and have to be "customized" for each specific case (to provide a list of permissible repositories or user dev groups). = = = = = = I also wanted to repeat here an important constraint mentioned in bug 496335 comment 8 that this generalized mechanism is only for cases where projects have to "build together" -- not for unrelated projects that can build independently -- it is always preferable to do that. <quote> As long as we're clear this is only an option for projects like platform(which has several individual projects, but a single 'build') but not for unrelated projects(ie: technology.ease and tools.cdt). </quote> = = = = = This latter constraint gets more into what the review and approval process should be. And, that I am less sure of, though might mean this bug belongs somewhere else, such as under the "Process" component. Feel free to move to another component if that would help if get proper visibility. Thanks,
(In reply to David Williams from comment #0) > Currently, if I look at git config --global --list for our Releng HIPP I see > user.name=hudson > user.email=hudsonbuild@hudson.eclipse.org > > I assume that is the same for all HIPP instances. > > That won't be helpful to anyone, and if anything, should start off as > ... I guess I am partially wrong about this. I see now that Mr. Hudson can and does "tag our repositories". Is that by design? That "hudson" has permission to "push" to all repositories? That seems less safe than having it be something more specific -- something tied to each "HIPP" instance (and, even then, not only if requested). I am a little surprised I was asked to get Wayne's and Janet's approval on bug 496335 if if in fact things have been set-up to already give this very broad access. So you somehow prevent "hudson" from pushing anything except tags? Changing to "major" since I think this needs to get well understood and settled sooner rather than later.
> I guess I am partially wrong about this. I see now that Mr. Hudson can and > does "tag our repositories". Is that by design? That "hudson" has permission > to "push" to all repositories? That seems less safe than having it be > something more specific -- something tied to each "HIPP" instance (and, even > then, not only if requested). I'm not sure I understand. If a project owns a HIPP, the project-specific HIPP user does not have write access to git repos or the project's download area by default unless they ask for it. Unlike with the shared instance, each hipp instance operates under a project-specific user account for that purpose. HIPP A cannot tag/push to Project B.
(In reply to Denis Roy from comment #2) > > I guess I am partially wrong about this. I see now that Mr. Hudson can and > > does "tag our repositories". Is that by design? That "hudson" has permission > > to "push" to all repositories? That seems less safe than having it be > > something more specific -- something tied to each "HIPP" instance (and, even > > then, not only if requested). > > > I'm not sure I understand. If a project owns a HIPP, the project-specific > HIPP user does not have write access to git repos or the project's download > area by default unless they ask for it. > > Unlike with the shared instance, each hipp instance operates under a > project-specific user account for that purpose. HIPP A cannot tag/push to > Project B. I'm not sure I understand, either, but I can make it more concrete and perhaps that will help. The Releng HIPP (until just an hour ago, when I changed it) had as git config --global user.name=hudson user.email=hudsonbuild@hudson.eclipse.org And, I just looked and the SimRel HIPP also has git config --global user.name=hudson user.email=hudsonbuild@hudson.eclipse.org Now, I know for a fact, some of our projects were "tagged" (i.e. the tag was created and pushed to some "JDT" projects by the "hudson" user. So, it seems to me, I could run a job under SimRel check out platform projects, and also "push changes" to the repo (since "hudson" user has permission to, as far as Git is concerned). I have not tried it, mind you, -- want me to try? :) -- but that is what I am talking about. What is to prevent it? For example, here's the commit that "tagged" one of our Platform projects with P20160623-0900. http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=7a4217be2c000e3ceeea67204ea9e698e5392897 I am sure you have a better overall view of ALL the HIPP instances, but ... it seems there should not be two of them that define a user "hudson" that has permission to "push" things to it. If "Releng" was special in some way, then it is just a matter of educating (me) why 'hudson' was allowed from Releng HIPP but could not do it from SimRel HIPP. Notice, BTW, that by a commit shortly later I had changed things so *our* user genie.releng pushed a commit as expected. http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=34430a08d8f4bcd6850fbf69b059a71d7113c5d9 [That was after I "manually" changed the git config --global settings on that HIPP instance).
The git config is not used to authenticate who can push -- they just establish user-friendly names and emails. We use user accounts and file system permissions to authenticate. Is it possible that the two hipps were configured to write to the same file systems?
(In reply to Denis Roy from comment #4) > The git config is not used to authenticate who can push -- they just > establish user-friendly names and emails. We use user accounts and file > system permissions to authenticate. Is it possible that the two hipps were > configured to write to the same file systems? Ok, that's a little eduction. But, not sure what you mean by "same file system". But from what you say, it should be perfectly safe for me to try to tag a platform bundle and it would simply fail. The SimRel HIPP, normally, never commits anything to any repository, so it should not have any access even its own -- I mean, ok if it does, I guess, in case someday someone does want to "tag builds" -- but I've never configured it to do anything "to" git; just read from it.
I'll change this back to an "enhancement" now that I understand the "user.name" is just a convenient way to document commit and authors and is not related to "permission" to commit code. I still think it would be nice enhancement if ever HIPP has their user.name set to the user.name that was "running" the HIPP, instead of always being "hudson", but the main purpose of this bug is how to generalize the process where one project needs to build other projects and be able to tag the build.
Adding Mikael as cc since he's doing some work in this area. -M.
This handled at the same time we're migrating to new clustered infra (JIRO). All instances running on the new infra can push to git repos via a bot (genie.xxx).
