|strange pushes on GitHub||Dominik Bartholdi||11/10/13 7:47 AM|
Hi everyone and specially Luca,
yesterday something strange has happen to many Jenkins repositories on GitHub (more then 50 Repos)…
Luca Milanesio seems have pushed to many many repositories without really changing anything - at least I have not seen anything changed.
If you look at the activity stream/feed at https://github.com/organizations/jenkinsci and go back to yesterday, you’ll find many pushes to many different repositories.
Maybe I’m wrong and someone has an easy explanation for this?
But for me this looks like someone did not really now how Git/GitHub works and accidentally pushed to every single repo - maybe someone else could also have a look and see if there is something broken now?
|Re: strange pushes on GitHub||Marcelo Rebasti||11/10/13 7:56 AM|
Domi, maybe it's related to this mail http://jenkins-ci.361315.n4.nabble.com/Jacoco-plugin-repo-reset-tt4680030.html.
|Re: strange pushes on GitHub||Vincent Latombe||11/10/13 8:21 AM|
It seems like a lot of repositories are back to previous revisions. git-client-plugin's master now points to 1.4.3-SNAPSHOT whereas it should be pointing to 1.4.7-SNAPSHOT...
2013/11/10 Marcelo <mreb...@gmail.com>
|Re: strange pushes on GitHub||ogondza||11/10/13 8:25 AM|
Definitely related, selenium-tests repo lost 17+ commits after such push.
|Re: strange pushes on GitHub||Dominik Bartholdi||11/10/13 8:51 AM|
As I don’t know if Luca is following this list too, I’m adding Lucas mail on the to list… (got the email address from his GitHub account)
Please Luca can you explain what you have done to all this repositories?
|Re: strange pushes on GitHub||Arnaud Héritier||11/10/13 10:24 AM|
I confirm we lost many commits. damned github that doesn't allow to disable the history rewrite at least on master branch.
Last commit on Xcode repo is referencing one done by Jerome Lacoste 5 montages ago while KK worked on it recently.
I don't know how we can restore everything easily. We need to find the recent hash and relative history in a clone we the push of yesterday was retrieved.
|Re: strange pushes on GitHub||Arnaud Héritier||11/10/13 10:45 AM|
|AW - *PLEASE READ* Re: strange pushes on GitHub||lucamilanesio||11/10/13 10:55 AM|
I have triggered an involuntary "forced push" last night on the list of Jenkins-CI plugins indicated below in this e-mail.
I did not realise that I actually had forced push permissions and I do apologise for the inconvenience caused.
The operations pushed back the all the branches to around 1 month. The history is not lost and is still on the GitHub server but on detached branches.
I can raise a request to GitHub to provide the "reflog" of those repositories and restore the branches to the point before my forced push.
Alternatively the owners of those repositories can still perform a "forced push" to restore the correct position of the branches.
(if you would like to do so, please write to the mailing list so that we do not overlap the recovery operations)
The full list
See below the full list of repositories impacted:
Can we prevent this to happen again ?
I personally do not work on any of those repositories but still have "forced push" permissions ... and so many other people have.
I don't see the value of having such power of "potential disruption" associated to my account :-( ... can we remove the forced push by default and enable on a case-by-case basis ?
--- * ---
If you would like to propose an alternative approach to resolve the problem, feel free to follow-up !
... and again ... accept my sincere apologies :-(
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||ogondza||11/10/13 11:05 AM|
I have already asked Github support to provide hashes of former master positions and referenced this thread. Will report ASAP.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||lucamilanesio||11/10/13 11:10 AM|
*UPDATE*I have just send the request to GitHub support on-line, looping them as well in this e-mail.
@GitHub Support: please consider this request as a matter of urgency, thank you.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Arnaud Héritier||11/10/13 11:30 AM|
Thx guys for these details. We are all humans and subject of doing errors.
I hope we'll have some help from github but I'm not sure they may spend many time to help us for an error not coming from their side.
In any case it is recommended to NOT PULL current master branches from these repositories, your local copy may be more up-to-date. If you have a recent hash you can at least try to push them in github under a branch named "master-fix" the time we find the best solution to repare all master repositories.
If you commited on these repositories since yesterday verify that you didn't started your work from the wrong old hash.
Idea : in our CI server logs we should be able to find the lastest hash of each repo in the related plugin build. After that we have to find how to restore them. It's easy to do it when you have this commit locally but AFAIK it's not if it is only in the remote (you don't get orphelin commits when you clone a repo)
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||lucamilanesio||11/10/13 11:41 AM|
*UPDATE* after a cross-check I need to add 2 extra repositories to the list:
The total number of impacted repositories should then be: 186
@ALL: is there anyone with direct contact of some GitHub-er ? It would be best to resolve the problem *before* the start of the working week on Monday.
Thanks to everyone that contributed to resolve the problem !
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||lucamilanesio||11/10/13 11:47 AM|
thanks for the understanding :-) I am used to warn other people from doing any "forced push" ... and Murphy's law wanted this time happening to me :-(
Technically yes, but for the "customer relationship" and because it is an easy recovery (git reflog + git branch), they could make some effort to help us out.
JenkinsCI is possibly the largest customer they have worldwide ;-)
Yes, that's what I thought as well ... but definitely the "git reflog" on GitHub server would be more reliable.
The CI workspace (assuming that Git clones are not shallow copies) may have as well those commits as well, but again GitHub would be safer and better IMHO.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Marcus Bauer||11/10/13 11:52 AM|
I don't think GitHub.com has any possibilities for disabling force pushes, this seems to be exclusive to GH Enterprise only.
The JaCoCo repo where I initially noticed this was restored by Dominik Stadler (centic9) few minutes ago.
Am Sonntag, 10. November 2013 19:55:08 UTC+1 schrieb lucamilanesio:
|Re: strange pushes on GitHub||Mirko Friedenhagen||11/10/13 12:00 PM|
I saw these strange pushes as well, jobConfigHistory-plugin was
failing because master was reset to a commit which was two months old.
I see that https://github.com/jenkinsci/maven-hpi-plugin/tree/master
is pointing to an old commit as well, the new version 1.106 is much
newer than master.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||lucamilanesio||11/10/13 1:40 PM|
That's really pitty :-( ... force push are dangerous, especially if you don't have control over the Git Server.
Typically recovering a force push is straightforward:
1. git reflog > look at the SHA-1 before the forced push
2. git branch -f <name> <sha-1>
But if you don't have control over the Git repo on the Server, that you need to prevent force push to happen: unless they want everyone to buy GH Enterprise !
I still hope GitHub will do 1. and 2. for us :-)
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Dominik Stadler||11/10/13 1:59 PM|
I didn't know that this was a bigger problem and thus just pushed the previous commits again, in case of the jacoco-plugin repo it was easy as I just committed changes yesterday and thus could easily push the latest changes together with the missing commits.
The really bad thing in my view is that as a user of the repo you do not see at all that it happened. Git and Github is all about history of changes, but in this case your repo looks like a month ago with no visible trace on github that something newer was there at some time... Quite dangerous....
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||slide||11/10/13 2:06 PM|
I did a force push to email-ext and it seems to be fine now.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Arnaud Héritier||11/10/13 2:11 PM|
In theory, to restore the master to the latest hash (and others branches - As I can see in Github organisation history) no --force will be required. You won't change the history, you just re-add missing commits on top of the old one.
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Arnaud Héritier||11/10/13 2:16 PM|
I hope that Github will help us. That may save us a lot of time. Perhaps giving us a copy of all repositories could be enough and we may dig ourselves in reflogs to restore branches.
Yes that's really annoying that they don't allow us to block force push on some branches. Because of that when I migrated my company from subversion to Github I setup a daily external clone/backup process of all repositories in a case where we had such issue and we weren't easily able to identify a recent clone amonst ours developers (which is a children game in a company compared in an OSS like Jenkins)
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Christopher||11/10/13 2:42 PM|
With 678 members in the jenkinsci organisation, we're probably
relatively exceptional; I can't imagine GitHub have much incentive to
implement the type of fine-grained force-push permissions we would need.
Plus I think even with the number of members we have, git accidents are
very rare, i.e. it's likely easier to fix mistakes in git, than to
maintain a big set of permissions for new and existing users/repos.
BTW, out of curiosity, how did you manage to force push such a large
number of repositories at the same time? :)
> <mailto:mab...@gmail.com>> wrote:
>> I don't think GitHub.com <http://GitHub.com> has any possibilities for
>> disabling force pushes, this seems to be exclusive to GH Enterprise>> <https://enterprise.github.com/help/articles/disable-force-pushes> only.
>>>> *_My apology _*
>>>> *_The solution_*
>> I can raise a request to GitHub to provide the "reflog" of those>> /_Alternatively the owners of those repositories can still perform
>> a "forced push" to restore the correct position of the branches._/
>> (if you would like to do so, *_please write to the mailing list so
>> that we do not overlap the recovery operations_*)
>> *_The full list_*
>> *_The prevention_*
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||lucamilanesio||11/10/13 3:24 PM|
GitHub model is based on pull requests and not on shared Git repositories: that's why protections against forced push is typically not needed (typically repo is pushed by only its maintainers and not by contributors).
The way we use GitHub with Jenkins is not very typical for them :-)
Yes they are rare ! ... but when they happen you need to sort them out :-(
BTW, out of curiosity, how did you manage to force push such a large number of repositories at the same time? :)
Problems with the Gerrit replication plugin ... unfortunate combination of three events (Murphy's law ?):
- working on a directory where I had the Jenkins plugins repos cloned (but outdated to around 1 month ago)
- having a Gerrit replication plugin pointing to that directory (I did not realised was using *forced push* that until later today)
- having the permissions of making *forced push* on repos that I did not work on (I did not realised that until today)
I have removed those local repos on my machine ... so can't do it again, but we need to sort out the mess in the meantime :-(
I am submitting now a patch to Gerrit replication plugin to *forbid* forced push by configuration: so at least I can block them from my side.
Possibly a bit late ... closing the gates when the sheep just escaped ;-(
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Christopher||11/10/13 3:42 PM|
On 11/11/2013 12:24 AM, Luca Milanesio wrote:> I am submitting now a patch to Gerrit replication plugin to **forbid*
> forced push by configuration*: so at least I can block them from my side.
Yeah, that's unlucky.
One thing I sometimes do for repos where I have commit access, but don't
want to push, is to clone the repository via HTTP. That way, any
accidental attempts at pushing won't use my ssh key, and so GitHub will
prompt me for my password.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||lucamilanesio||11/11/13 12:11 AM|
Does anyone have news from GitHub ?
They haven't responded at all to my customer support request :-(
|Re: Re: AW - *PLEASE READ* Re: strange pushes on GitHub||vjuranek||11/11/13 12:15 AM|
On Sunday 10 November 2013 21:40:28 Luca Milanesio wrote:I wonder if we can use our all.git  somehow (in the worst case scenario
that github doesn't help us). When it try to clone it, it fails with remote
error and when looking into web UI the changes are already synchronized with
github. But IMHO still worth to investigate, orphan commits could still be
|Re: Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Emanuele Zattin||11/11/13 12:21 AM|
Maybe somebody from the bay area could try driving to the Github office on Monday morning. Scott Chacon would probably be good bet.
-I don't have to know an answer. I don't feel frightened by not knowing things; by being lost in a mysterious universe without any purpose — which is the way it really is, as far as I can tell, possibly. It doesn't frighten me.- Richard Feynman
On Mon, Nov 11, 2013 at 9:15 AM, Vojtech Juranek <vjur...@redhat.com> wrote:
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||nicolas de loof||11/11/13 1:05 AM|
git fetch + git push restored git-client and git plugins history
2013/11/10 Luca Milanesio <luca.mi...@gmail.com>
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Stephen Connolly||11/11/13 1:09 AM|
I had pushed releases of credentials, ssh-credentials, ssh-agent and ec2 on Friday, so I just re-pushed them. I don't think anyone made changes to scm-api or branch-api since my last push, so I pushed those from my local also
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Mads Nielsen||11/11/13 2:06 AM|
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||nicolas de loof||11/11/13 2:25 AM|
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Arnaud Héritier||11/11/13 2:36 AM|
For me it would be the safer issue. You could wait for tomorrow (it's a day off today in France) but we just need to take care to not loose these repositories.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||nicolas de loof||11/11/13 2:38 AM|
I can look into this while traveling to devoxx tomorrow
2013/11/11 Arnaud Héritier <aher...@gmail.com>
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||lucamilanesio||11/11/13 2:58 AM|
Yes, I think that would be a sensible approach.
As some of the people started already to push their up-to-date repo, it is better a push from the CI node rather than a "reset" from the GitHub guys at this stage.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Hakan Tandoğan||11/11/13 4:16 AM|
I pushed transifex-plugin.git from my local tree, all fine for this plugin now.
|Re: strange pushes on GitHub||Mike Caspar||11/11/13 4:22 AM|
I just tried to connect to check out the plugin I maintain (ironmq-notifier).
I have lost access to the repo completely.
I suspect that since I'm new, my rights were reverted due to this somehow.
Could someone add me back into the plugin ironmq-notifier.
|Re: strange pushes on GitHub||Mike Caspar||11/11/13 4:24 AM|
Actually, looks like it was just some weird caching problem.
Back into the repo now.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||nicolas de loof||11/11/13 6:09 AM|
I've pushed plugin's master branches from jenkins.ci.cloudbees.com,
some of then were rejected, like
! [rejected] master -> master (non-fast-forward)
Anyway I guess most plugin repo should be restored now.
2013/11/11 Hakan Tandoğan <hakan.t...@gmail.com>
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Mads Nielsen||11/11/13 6:16 AM|
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Vivekanand S V||11/11/13 6:20 AM|
This one https://github.com/jenkinsci/copy-to-slave-plugin recovered only some commits.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||nicolas de loof||11/11/13 6:26 AM|
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||ogondza||11/11/13 6:28 AM|
Could you list the repos that rejected the push and point us to the backup
repos so we can fix the rest manually? For instance
next-build-number-plugin is missing 6 commits compared to my local copy. I
assume this is not the only one.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Ullrich Hafner||11/11/13 6:33 AM|
I already pushed my local commits again, so the history of the warnings plug-in is up to date again.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||nicolas de loof||11/11/13 6:37 AM|
Here are the repo that fail to git push as "[rejected] master -> master (non-fast-forward)"
2013/11/11 oliver gondža <ogo...@gmail.com>
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||slide||11/11/13 6:40 AM|
I already pushed the correct stuff to email-ext-plugin.git, so that one is done.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Iñaki Albors||11/11/13 7:09 AM|
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Vivekanand S V||11/11/13 7:16 AM|
@nicolas, I have a local clone which I last used to push a release. What do I need to do ?
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Stefan Brausch||11/11/13 7:32 AM|
logfilesizechecker and scm2job restored from local copy (wasn’t complete)
Am 11.11.2013 um 15:26 schrieb nicolas de loof <nicolas...@gmail.com>:
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||nicolas de loof||11/11/13 7:56 AM|
just git push origin master
the unintentional force push just reverted history some weeks ago, so this will re-add the missing commits
2013/11/11 Vivekanand S V <svvive...@gmail.com>
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Vivekanand S V||11/11/13 8:09 AM|
@nicolas, its done, copy-to-slave is upto date now.
Thanks a lot.
|Re: Re: AW - *PLEASE READ* Re: strange pushes on GitHub||vjuranek||11/11/13 11:04 AM|
just FIY, if your plugin is not on this list, this doesn't mean the commits
were successfully restored - e.g. one of my plugins (beaker-builder) is not on
the list and the last commit is 3 months old , while actual last commit is
one week old , so please double check your plugins
> 2013/11/11 oliver gondÅ¾a <ogo...@gmail.com>
|Re: Re: AW - *PLEASE READ* Re: strange pushes on GitHub||nicolas de loof||11/11/13 11:17 AM|
yes indeed, this is just the last state on CI job, no guarantee it hasn't been updated in the meantime based on github forced push
2013/11/11 Vojtech Juranek <vjur...@redhat.com>
|Re: Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Mirko Friedenhagen||11/11/13 12:00 PM|
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Rob Petti||11/11/13 12:09 PM|
perforce-plugin.git has been restored from my local copy.
It may be beneficial to look into implementing finer grained access control for individual repos. For example, I thought that only myself, Oleg, and the Jenkins project owners had write access to the perforce plugin. If everyone has access to everything, then this sort of thing could happen again.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Kohsuke Kawaguchi||11/11/13 12:19 PM|
On 11/10/2013 10:55 AM, Luca Milanesio wrote:> *_My apology _*
>> *_The solution_*
> I can raise a request to GitHub to provide the "reflog" of those> /_Alternatively the owners of those repositories can still perform a
> "forced push" to restore the correct position of the branches._/
> (if you would like to do so, *_please write to the mailing list so that
> we do not overlap the recovery operations_*)
If they can just create refs for all the tips of the affected branches
before a forced push in a distinct names, then we can write a script
that compares that with the current tip of the branches (which may or
may not be fixed by someone manually already) and do the right thing.
> *_The full list_*
> *_The prevention_*
>> On 10 Nov 2013, at 18:24, Arnaud Hï¿½ritier <aher...@gmail.com
> <mailto:aher...@gmail.com>> wrote:>> ï¿½
>> Sent from Mailbox <https://www.dropbox.com/mailbox> for iPhone
>>>> <mailto:do...@fortysix.ch>> wrote:
>> As I donï¿½t know if Luca is following this list too, Iï¿½m adding
>> Lucas mail on the to listï¿½ (got the email address from his GitHub
>> <mailto:ogo...@gmail.com>> wrote:>>> <mailto:firstname.lastname@example.org>.
>>> For more options, visit https://groups.google.com/groups/opt_out.>> <mailto:email@example.com>.
>> For more options, visit https://groups.google.com/groups/opt_out.--
Kohsuke Kawaguchi http://kohsuke.org/
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Kohsuke Kawaguchi||11/11/13 12:23 PM|
Yes, I was thinking about the same. The last run of this is Nov 9,
11:24pm in EST.
I really hope this is before the incident. But I'll find out soon.
On 11/11/2013 12:15 AM, Vojtech Juranek wrote:
> On Sunday 10 November 2013 21:40:28 Luca Milanesio wrote:
>> That's really pitty :-( ... force push are dangerous, especially if you
>> don't have control over the Git Server.
> I wonder if we can use our all.git  somehow (in the worst case scenario
> that github doesn't help us). When it try to clone it, it fails with remote
> error and when looking into web UI the changes are already synchronized with
> github. But IMHO still worth to investigate, orphan commits could still be
>  http://git.jenkins-ci.org/?p=all.git;a=summary
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Jenkins Enterprise, our professional version of Jenkins
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Andrew Bayer||11/11/13 12:25 PM|
fwiw, gradle-jpi-plugin, throttle-concurrent-builds-plugin, jclouds-plugin and associated-files-plugin are all up to date now.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Kohsuke Kawaguchi||11/11/13 1:22 PM|
You should push 'master' in these repos to a separate ref so that we can
> 2013/11/11 oliver gondža <ogo...@gmail.com <mailto:ogo...@gmail.com>>
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Kohsuke Kawaguchi||11/11/13 2:08 PM|
On 11/11/2013 12:23 PM, Kohsuke Kawaguchi wrote:Unfortunately, it appears that the last sync process has run after
luca's "push -f".
I'll hold on to this repo just in case, but resurrecting lost commits
from this appears hopeless.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||lucamilanesio||11/11/13 2:22 PM|
Good news from GitHub: they have extracted the full list of SHA-1 before the forced push !
Many thanks to Nathan Witmer :-)
See below the full CSV with the SHA-1.
He created as well a branch named 'recovery' that points to the candidate point for restoring the master branch.
Hope this will help to sort out the remaining repos.
> Hi Luca.
> Oh man, that sinking feeling!
> But, no worries: I've gone through each of the repos listed above and done the following:
> * retrieved the SHA for the previous `master` before you force-pushed
> * created a branch called `recovery` pointing to each former master
> In some cases, these are the same.
> I can go further and reset the master refs to their former shas if you'd like, or you can recover these yourself. To do so, in each repo:
> $ git fetch
> $ git checkout master
> $ git reset --hard origin/recovery
> $ git push --force origin master
> I've attached a csv containing the shas (former master and forced master) for each branch, for your reference.
> Good luck!
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Kohsuke Kawaguchi||11/11/13 2:27 PM|
We at the #jenkins channel in IRC were just wondering what the 'recovery' branch is.
I think it makes sense to bring back 'master' to 'recovery' where it is fast-forward, but let's walk bit slowly here...
2013/11/11 Luca Milanesio <luca.mi...@gmail.com>
|Recovery step #2: (was: Re: AW - *PLEASE READ* Re: strange pushes on GitHub)||Kohsuke Kawaguchi||11/11/13 2:46 PM|
On 11/11/2013 02:27 PM, Kohsuke Kawaguchi wrote:I'm downloading all the affected repositories as is now and. I'd like to
back them up first before attempting any further scripted edits to refs.
Once that's completed, I propose is we run "git push
origin/recovery:master" on each repo. The purpose of this command is:
1. if the current 'master' (which lost some commits) can be
fast-forwarded to 'recovery', we'll do so.
2. if the current 'master' has diverged from the 'recovery',
for example because it has already been pushed or a separate
recovery was attempted, then this git-push will fail.
For repositories where 'master' didn't fast-forward to 'recovery', I'll
create a list of them and we'll look at them individually. Hopefully
they won't be large in numbers.
If anyone else have any thoughts about how to recover all the
repositories en mass, please let us know.
> 2013/11/11 Luca Milanesio <luca.mi...@gmail.com
> > For more options, visit https://groups.google.com/groups/opt_out.> <mailto:jenkinsci-dev%2Bunsubscribe@googlegroups.com>.
> For more options, visit https://groups.google.com/groups/opt_out.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Arnaud Héritier||11/11/13 3:15 PM|
On Mon, Nov 11, 2013 at 11:27 PM, Kohsuke Kawaguchi <k...@kohsuke.org> wrote:
A big thx to Nathan Witmer !!
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier
|Re: Recovery step #2: (was: Re: AW - *PLEASE READ* Re: strange pushes on GitHub)||Arnaud Héritier||11/11/13 3:31 PM|
On Mon, Nov 11, 2013 at 11:46 PM, Kohsuke Kawaguchi <kkawa...@cloudbees.com> wrote:
Nothing better to propose.
|Re: Recovery step #2:||Kohsuke Kawaguchi||11/11/13 6:13 PM|
Any more sanity checks on this course of action before I actually run
them? I've only heard from Arnaud...
|Re: Recovery step #2:||Dominik Bartholdi||11/11/13 8:50 PM|
Sounds perfect for me!
> Am 12.11.2013 um 03:13 schrieb Kohsuke Kawaguchi <kkawa...@cloudbees.com>:
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Wes Turner||11/12/13 12:04 AM|
> I can't imagine GitHub have much incentive to> implement the type of fine-grained force-push permissions we would need
There are fine-grained "File and branch conditions" in mercurial-server
that can prevent these sorts of pushes from succeeding. 
On Sunday, November 10, 2013 4:42:53 PM UTC-6, Christopher wrote:
With 678 members in the jenkinsci organisation, we're probably
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Ikedam||11/12/13 4:16 AM|
Unfortunately, there may be something wrong with this list...
scoring-load-balancer-plugin have same orig_master and forced_master, 634609e.
And the version in its pom.xml is 1.0.1-SNAPSHOT.
But I have released scoring-load-balancer-1.0.1 last week.
The latest commit should be:
There may be same problems in other plugins if they are updated in a week.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||lucamilanesio||11/12/13 5:10 AM|
Looking again at the list right now: there are a few in the same situation :-(
Sent from my iPhone
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Olivier Dagenais||11/12/13 6:04 AM|
I learned of this situation last night. I'm the [current] maintainer of the tfs-plugin and I don't see commits since I released version 2.0, nor do I see a 'recovery' branch at https://github.com/jenkinsci/tfs-plugin
The machine I last made release 3.0.1 from has a clone with the 24 missing commits, and it looks like I should be able to just push them.
I don't want to interfere with any mass-fixing attempts discussed here (especially by Kohsuke), so please let me know if I should proceed.
P.S.: I'm the one who released the last rake-plugin (which sort of makes me a maintainer), but the last commit to that repo was long enough ago that it wasn't affected.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Andrew Melo||11/12/13 6:05 AM|
The same functionality exists in git, just not in github.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Kohsuke Kawaguchi||11/12/13 8:06 AM|
GitHub has the event API that shows activities in a given repository and organization. The documentation page says only up to 300 can be retrieved, and so the events in the org no longer seems to contain the push from luca.
But when I look at the repository, I can still see those pushes. For example, https://api.github.com/repos/jenkinsci/scoring-load-balancer-plugin/events
I think a little bit of scripting would allow us to go through each repository and find the trace of "git push -f" accurately.
2013/11/12 Luca Milanesio <luca.mi...@gmail.com>
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||lucamilanesio||11/12/13 11:35 AM|
I've checked as well and tfs-plugin was in the list of recovered repos but I can't find the recovery branch either:
Will run a quick script for assess the situation with the others.
In the meantime I've extracted the lists of repos with pre-push and post-push SHA1 are the same (54 repos):
Will check now their master SHA1 and compare with the one "post-push" to see if the plugins maintainers have already pushed it or not.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Kohsuke Kawaguchi||11/12/13 11:44 AM|
The tfs-plugin repository that I obtained yesterday does contain the
recovery branch pointing at f61f3fc4a395c40196fd51838bd4dc07b87bd139,
which is the tip of the master before luca's commit according to
git ls-remote that I just run also agrees with that:
> % git ls-remote https://github.com/jenkinsci/tfs-plugin.git
> 12b7198ce3b9ca2c940f3d995e64c481b22069b6 HEAD
> 12b7198ce3b9ca2c940f3d995e64c481b22069b6 refs/heads/master
> f61f3fc4a395c40196fd51838bd4dc07b87bd139 refs/heads/recovery
> d20b66b6f2af787faf1810f3e3af70bc354caa4c refs/heads/svn
> af49749cda406363888b3fd371193de0d1fe3d72 refs/heads/useTfsSdk
> 341fd55cc2765aee9a893d03f7a1fab507b86925 refs/meta/config
It's probably just not showing up in the UI presumably because the
recovery branch was created by an unusual means.
>> For more options, visit https://groups.google.com/groups/opt_out.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||lucamilanesio||11/12/13 11:58 AM|
Ah ok :-) that is clarified then !
I'm looking now the list of 54 repos to see if they have been already fixed by their maintainers ....
Will provide further updates later.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||slide||11/12/13 12:01 PM|
Please don't run any more scripts :-). The email-ext-plugin is just fine, please take it off your list for needing recovery.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||lucamilanesio||11/12/13 12:27 PM|
I'm just checking using the GitHub GUI, will not push anything :-)
I am trying the get the final list of repos that would need further fixing. Then would leave to the plugin maintainer to judge which is the latest, as it was not detected by the GitHub support team.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Hugo Arès||11/12/13 12:37 PM|
The git-plugin is missing at least one commit:
Author: Stephen Connolly <...>
Date: Fri Nov 8 15:51:49 2013 +0000
switch to c:select to support in-place addition of credentials
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Hugo Arès||11/12/13 12:45 PM|
The build-pipeline-plugin is missing the last 2 commits:
Merge: 64db20c d9a6545
Author: geoffbullen <...>
Date: Mon Nov 4 14:25:50 2013 -0800
Merge pull request #18 from jglick/lower-core-dep
Drop core dependency to 1.509 (LTS line).
Author: Jesse Glick <...>
Date: Mon Nov 4 17:18:01 2013 -0500
Drop core dependency to 1.509 (LTS line).
Current code requires at least 1.489 (for 15ba345b), but 1.521 seems unjustified.
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Kohsuke Kawaguchi||11/12/13 12:51 PM|
From what I can tell, those repositories are in the CSV file provided
by GitHub, and their commits do seem to be in the 'recovery' branch. So
those are already accounted for.
Right now we are focusing on either repositories that are not in the CSV
file, or the commits that are not in the 'recovery' branch.
> On Tuesday, November 12, 2013 3:37:53 PM UTC-5, Hugo Ar�s wrote:
|Re: AW - *PLEASE READ* Re: strange pushes on GitHub||Kohsuke Kawaguchi||11/12/13 12:55 PM|
Indeed, looking at
I see that Luca's push had changed master from
So there's something wrong with the list provided by GitHub...
|Re: Recovery step #2:||Kohsuke Kawaguchi||11/12/13 1:22 PM|
Since this CSV file and the 'recovery' branch created by GitHub support
doesn't appear to be complete, I'm putting this on hold for now.