Community
Participate
Working Groups
Now that bug Bug 496335 has been fixed, a few final steps are needed to fully migrate to "genie.releng" instead of "e4Build". The main one(s) are a few places where we 'clone' the repository, we explicitly configure it so that B_GIT_EMAIL=e4Build@eclipse.org B_GIT_NAME="E4 Build" COMMITTER_ID=e4Build These should now be (I believe) B_GIT_EMAIL=genie.releng@eclipse.org B_GIT_NAME="Platform Releng HIPP" COMMITTER_ID=genie.releng = = = = = These are the most substantial cases. There is a who bunch of places it is used in comments, which should change too. = = = = = = The only other place has to do with some "mailto" functions as the "FROM: " address. I think that should be changed too and have asked in bug 496335 what exactly its email address is to confirm. I am not sure if it has to "subscribe" to mailing lists, to be able to "send mail" to it, but suspect that it does.
This is main fix, changing e4Build to genie.releng http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=102f341a44c460d716c17478da14b54875ec20f0 Still need to change the "name" from "E4 Build" to "Releng HIPP". And, that name "Releng HIPP" is intentional, instead of "Platform Releng HIPP" since on the "page of HIPP servers" at https://hudson.eclipse.org/ is it called simple "Releng" not "Platform Releng". = = = = = = But, I have noticed we do not seem to explicitly configure on clone, as I though we did. So, I will do a test build now (after deleting previous "N-build" gitCache, to see if it "ends up" with the right values. I noticed on "e4Build" id that we did have these global git configuration variables set: e4Build@build:~> git config --global --list core.autocrlf=false branch.autosetuprebase=always user.email=e4Build@eclipse.org user.name=e4Build push.default=matching My guess is we would be better off explicitly setting the values on clone. But, we'll see what we end up with. (Plus, I think core.autocrlf=input would be a better value that false. We have had cases in the past where someone checked in something with Windows CRLF (such as from OSGi) and then on the next "pull" we get an error that says "source has changed". This would be avoided by using "input" instead of "false". [Though, that might mess up our little "stashing heuristic"].
From a test build, the repo definitely does not automatically get "genie.releng" as the committer. So, will need to add explicit "config on clone" values.
(In reply to David Williams from comment #2) > So, will need to add explicit "config on clone" values. I have tried this on my local test build machine with confusing results. This may be hard to read, but the basic "clone" command is STANDARD_CONFIG="--config core.autocrlf=input --config branch.autosetuprebase=always --config user.email=\"${B_GIT_EMAIL}\" --config user.name=\"${COMMITTER_ID}\" --config push.default=matching" # write command once, to make sure its echo, and the command itself are the same! (from experience :) GIT_CLONE_CMD="git clone --recursive ${STANDARD_CONFIG} $BRANCH_CMD $URL $TARGET_DIR" # print out what we are going to do echo "${GIT_CLONE_CMD}" # then do it ${GIT_CLONE_CMD} This *does* set those config values in eclipse.platform.releng.aggregator, but not for each submodule. And, the confusing part is, I do not know if it needs to, or if the submodules get (some of) their config values from their parent. And, so far have not seen this topic on the web anywhere. So, we may just have to "test it out". But there are other approaches that might be less error prone. The other approaches would basically call "git config" as a completely different step, perhaps using "git submodule foreach". One (confusing) thing I have noticed is that using --config in the clone command *requires* that there by an "=" between the key and the value. But, using git submodule foreach git config key value requires that there *not* be an "=" between the key and the value. = = = = = = I am beginning to think it would be easiest to simply set the "global configs". I can't imagine that "genie.releng" would be building repositories where other settings would be needed. In fact, these are the current git config values for that machine (global and system) Git global config user.name=hudson user.email=hudsonbuild@hudson.eclipse.org Git system config fatal: unable to read config file '/usr/local/etc/gitconfig': No such file or directory Seems there should be an empty gitconfig file for "system" instead of resulting in an error. Should also check ENV variables, just to be positive that the global config is not "shared" on "hipp8".
(In reply to David Williams from comment #3) > Should also check ENV variables, just to be positive that the global config > is not "shared" on "hipp8". Our ${HOME} is specific to "genie.releng", so we could have our own global config, without fear of us stepping on someone, or someone stepping on us. Git global config user.name=hudson user.email=hudsonbuild@hudson.eclipse.org cat /home/hudson/genie.releng/.gitconfig [user] name = hudson email = hudsonbuild@hudson.eclipse.org
(In reply to David Williams from comment #4) > (In reply to David Williams from comment #3) > > > Should also check ENV variables, just to be positive that the global config > > is not "shared" on "hipp8". > > Our ${HOME} is specific to "genie.releng", so we could have our own global > config, without fear of us stepping on someone, or someone stepping on us. > > Git global config > user.name=hudson > user.email=hudsonbuild@hudson.eclipse.org > > cat /home/hudson/genie.releng/.gitconfig > [user] > name = hudson > email = hudsonbuild@hudson.eclipse.org I have changed these to to "genie.releng" but that is not working yet. See bug 496335.
Mail now comes from "genie.releng" and the repositories are tagged by "genie.releng" so I think this bug can be marked fixed.
