On Tue, Jan 24, 2017 at 03:08:52PM +0100, Pavel Raiskup wrote:
> On Tuesday, January 24, 2017 12:58:00 PM CET Michal Novotny wrote:
> > Hello, I will deploy fedmsg hotfix tomorrow at 7:30am UTC. I am very sorry
> > for the inconvenience.
>
> I'm very sorry too. I failed with testing this against fedmsg because I was
> even unable to connect to fedmsg.
Well, you can easily run you own/local fedmsg bus. All it takes is pretty much
running fedmsg-relay in one terminal and fedmsg-tail (to watch the bus) in
another terminal.
You might want to stop listening to the production bus by editing
/etc/fedmsg.d/endpoints.py to reduce the noise on fedmst-tail.
> And I did not realize that this could get to
> production so quickly, I was kind of believed staging environment.
Does copr have a stg environment?
> I'd like to propose follow-up patch for Michal's hot-fix; to unify the
> code so only one announce_job() (in super-class) is available.
> I probably see reason why the announce_job() was added to FedMsg
> sub-class, but we can still pretty easily fix the general "API" and fix
> Red Hat's copr so it accepts different format of message (without touching
> FedMsg's api anymore) ... rather than have two announce_job() implementations.
>
> I'm just curious what happened with '{who}' part of the message?
>
> But, ugh, I'm bit afraid of fixing the code now without being able to test
> properly ... could I get a testing access to fedmsg so I can avoid similar
> issues in future?
There isn't really any testing access, we have two bus, the one in prod and the
one in stg but as copr doesn't (iirc) have a stg instance, it doesn't have
access to the stg bus.
The easiest really is to just run a local fedmsg-relay and see which messages
the app sends.
After that it's a matter of adjusting fedmsg_meta to process them.
Pierre
_______________________________________________
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
