<RockyTV>
sending on discord so allis gets the message
<RockyTV>
actually nevermind because I just realized that blueprints != api
<RockyTV>
@AllisTauri we should have a type-checked method for games and users that allow you to lookup a game/user by its name (or shortname)/username
<RockyTV>
VITAS, I also asked on the master post if mods are going to be workshop exclusive
AllisTauri[m] has joined #spacedock
<AllisTauri[m]>
@irc_RockyTV:52k.de: is there an issue for this? And by lookup you mean API call?
aradapilot has quit [Ping timeout: 190 seconds]
AllisTauri[m] has quit [Quit: Idle timeout reached: 10800s]
VITAS[m] has joined #spacedock
<VITAS[m]>
still 500 errors when pushing github hooks
<VITAS[m]>
Age: 1
<VITAS[m]>
Connection: keep-alive
<VITAS[m]>
...(truncated)
AllisTauri[m] has joined #spacedock
<VITAS[m]>
not?
<AllisTauri[m]>
there wasn't any 500 errors before
<AllisTauri[m]>
hey, that's beta
<VITAS[m]>
in that case its progress?
<VITAS[m]>
only one yesterday
<VITAS[m]>
the last one before that was on the 23th
<AllisTauri[m]>
we haven't merged anything to beta yet, have we?
<VITAS[m]>
"message": "Removed __init__ methods from DB Models\n\nThey all have the base __init__ that accepts all the fields as kwargs and does\nother stuff under the hood, so it's not recommended to override it, especially\nwhile not calling the super method.",
<AllisTauri[m]>
ah, yes, there's no discrimination between alpha/beta on github site
<AllisTauri[m]>
* ah, yes, there's no discrimination between alpha/beta on github side
<VITAS[m]>
how do i attach a hook to a branch?
<AllisTauri[m]>
don't know; you attach hook to the API endpoint, which should be on alpha.spacedock.info
<VITAS[m]>
ive two hooks one for alpha and one for beta
<AllisTauri[m]>
the endpoint checks the branch
<VITAS[m]>
and i want to either of them trigger on their respective branches not randomly on any
<VITAS[m]>
on githubs side
<AllisTauri[m]>
they should both trigger not randomly, but any time the specified event occures
<VITAS[m]>
dont i have to bind the hook on githubs side to a branch so it only triggers when that is updated?
<AllisTauri[m]>
don't know if you can; never used them hooks that much
<VITAS[m]>
because we have alpha and beta and both are different hooks in github with different servers and urls on our end
<VITAS[m]>
but nothing i see defines the branch they are triggered by
<VITAS[m]>
so alpha triggers when beta branch is updated and vice versa
<AllisTauri[m]>
correct; as far as I know it is responsibility of the endpoint to know what events/branches/etc it is interested with. You can configure a single endpoint to handle not only multiple branches, but multiple repos
<VITAS[m]>
so both trigger and our ends have to filter if its for them?
<HebaruSan[m]>
Since those are all GET instead of POST, nothing happened in the server
<AllisTauri[m]>
not apache, sd logs
<HebaruSan[m]>
There is zilch in journalctl in that time period
<HebaruSan[m]>
And they're still all GETs
<HebaruSan[m]>
There would be a POST if the web hook had fired
<VITAS[m]>
apache webserver log?
<AllisTauri[m]>
true, nothing in the logs
<HebaruSan[m]>
sudo less /var/log/apache2/spacedock.info-access.log
<VITAS[m]>
ok so ill set something up to monitor the rev proxys logs
<VITAS[m]>
and then well test the hooks again
<VITAS[m]>
leaves the distribution of hooks
<VITAS[m]>
as alpha and beta hooks dont fire for the same events but just alternating and not caring about branches
<AllisTauri[m]>
This shouldn't be happening, actually.
<VITAS[m]>
and yet it does
<VITAS[m]>
as you can see from the bits of log i posted
<HebaruSan[m]>
Maybe GitHub decided not to fire it anymore after too many failures?
<VITAS[m]>
but both have plenty of errors
<HebaruSan[m]>
Wait, we're talking about eleven days ago? I thought this was a test you just ran
<VITAS[m]>
both fired yesterday at different times
<VITAS[m]>
with different events
<HebaruSan[m]>
OK, here's the journalctl line corresponding to that response you posted:
<HebaruSan[m]>
Aug 17 09:41:22 sd6 gunicorn[27084]: 2019-08-17 09:41:22,720 WARNING Backend:27091 X-Hub-Signature didn't match the request data
<VITAS[m]>
beta is getting 500 and alpha is getting 403
<HebaruSan[m]>
Same as always
<HebaruSan[m]>
Aug 27 12:19:18 sd6 gunicorn[27084]: 2019-08-27 12:19:18,579 WARNING Backend:27098 X-Hub-Signature didn't match the request data
<HebaruSan[m]>
So it still looks like a problem with the secret
<VITAS[m]>
i copied the secret to my computer into notepad++
<VITAS[m]>
removed whitepsaces and copied it back to both sd6 and github
<HebaruSan[m]>
Notably my hook still works from when I pushed a new commit for PR 237:
<HebaruSan[m]>
Aug 27 12:30:35 sd6 gunicorn[27084]: 2019-08-27 12:30:35,774 INFO Backend:27098 Wrong repository. Expected 'KSP-SpaceDock/SpaceDock', got 'HebaruSan/SpaceDock'
<VITAS[m]>
and i did the same for sd2
<VITAS[m]>
so the are the same strings
<HebaruSan[m]>
Well somewhere in that process it got corrupted
<HebaruSan[m]>
No they're not
<VITAS[m]>
no
<VITAS[m]>
im certain
<HebaruSan[m]>
So am I 🙂
<VITAS[m]>
i visualy inspected the string after copying over to sd6 and closing and reopening the file
<HebaruSan[m]>
You can say that Jesus Christ himself verified it for you, it's still wrong
<VITAS[m]>
let me rephrase: theres nothing i know about to make the process more precise and correct for the part im playing in it
<VITAS[m]>
so its either the transimission when the hook fires that get corrupted
<VITAS[m]>
or the process of saving it on github is
<VITAS[m]>
or the matching isnt correct
<HebaruSan[m]>
Based on the fact that the hook that I created on my fork works, I am confident that the problem is the wrong secret string is saved into the main fork's web hook
<HebaruSan[m]>
Otherwise it would also be saying "X-Hub-Signature didn't match the request data" for mine
<HebaruSan[m]>
Instead it gets past the sig check and rejects it because it's the wrong repo
<VITAS[m]>
i will delete the hook on github again and recreate it using a string i generate on my computer using keepass and then copy paste it over again
<HebaruSan[m]>
OK, remember to set the same key in the config and restart the server
<VITAS[m]>
ill change the config and you can restart the server
<VITAS[m]>
ill also copy you the key so you can check iot against the config.ini
<VITAS[m]>
send you the key in irc
<VITAS[m]>
you can restart the server and compare the key to the one on alpha in config.ini
<VITAS[m]>
i also disabled the beta hook for the moment
<HebaruSan[m]>
Restarted
<HebaruSan[m]>
Can you edit the hook and save it again to trigger one of those test messages?
<HebaruSan[m]>
The previous one fired with the old config
<HebaruSan[m]>
(The old server that is)
<VITAS[m]>
uhm dont know
<VITAS[m]>
i just said trigger on everything so it fires as frequent as possible for testing
<HebaruSan[m]>
Well my fork's hook now fails the sig check, which is a midlly good sign:
<HebaruSan[m]>
Aug 28 10:34:59 sd6 gunicorn[16571]: 2019-08-28 10:34:59,976 WARNING Backend:16580 X-Hub-Signature didn't match the request data
<VITAS[m]>
so it does come trough?
<VITAS[m]>
ill set it back to just push events
<VITAS[m]>
application / x-www-form-urlencoded or application/json?
<VITAS[m]>
what do you want me to select
<HebaruSan[m]>
json
<VITAS[m]>
done
<VITAS[m]>
was on default: form from recreqating the hook
<HebaruSan[m]>
The traffic server wouldn't be caching /hook, would it?
<VITAS[m]>
if the flags on requests are right it wont
<VITAS[m]>
it will filter out nonstandart http requests like "DELETE" or "PUT"
<VITAS[m]>
thats why i asked if the req is a post because that works
<HebaruSan[m]>
Well I set the new secret into my fork's hook and pushed a new change to PR 237, and it once again gets past the sig check to the repo check:
<HebaruSan[m]>
Aug 28 10:45:48 sd6 gunicorn[16571]: 2019-08-28 10:45:48,338 INFO Backend:16579 Wrong repository. Expected 'KSP-SpaceDock/SpaceDock', got 'HebaruSan/SpaceDock'
<HebaruSan[m]>
OK, heretofore my goal has been web hook working on alpha.
<HebaruSan[m]>
With that seemingly working now, I agree with a feature freeze, the next thing I'd like to see is the stuff that's on alpha advanced to beta.
<HebaruSan[m]>
Any objections to starting a PR to do that?
<AllisTauri[m]>
RockyTV: i'm against it; it's better to know exactly what we're doing each time we query the database. Generic logic always has its overhead
<RockyTV[m]>
so you're proposing a method for querying via id and another for querying via shortname?
<AllisTauri[m]>
Besides, one thing is `Game.query.get(id)` and quite another `Game.query.filter(short='asdf').first()` both from performance and logical point of view. We don't have unique constraint on `short`
<AllisTauri[m]>
Not quite)
<AllisTauri[m]>
What I did with #227 is I just added `game_short_name` as an optional argument to the request data.
<AllisTauri[m]>
...(truncated)
<RockyTV[m]>
uh I need to check the PR, didn't get it :p
<AllisTauri[m]>
So you can query with `{'game_id':123, 'game_short_name':'ksp'}` and the `game_id` will be used. Or you can use only the `game_short_name`.
<AllisTauri[m]>
The difference between this approach and what you suggest is that it is explicit. Both the client and the server always know exactly what each meant and what to do. While making arguments with ambiguous meaning is a source of confusion.
<AllisTauri[m]>
It's not PRed yet, sorry.
<AllisTauri[m]>
I tend to keep things in local branch until I'm sure I won't need any more heavy rebasing to clean up the history
<RockyTV[m]>
ah so game_id becomes optional
<AllisTauri[m]>
They both mutually optional
<AllisTauri[m]>
(and the old `game` argument is a deprecated alias for `game_id` for backward compatibility)
aradapilot has joined #spacedock
aradapilot has quit [Remote host closed the connection]
aradapilot has joined #spacedock
<RockyTV>
AllisTauri[m], that means you can have one or the other
<RockyTV>
?
VITAS[m] has quit [Quit: Idle timeout reached: 10800s]
HebaruSan[m] has quit [Quit: Idle timeout reached: 10800s]
RockyTV[m] has quit [Quit: Idle timeout reached: 10800s]
AllisTauri[m] has quit [Quit: Idle timeout reached: 10800s]
AllisTauri[m] has joined #spacedock
<AllisTauri[m]>
One, or the other, or both, in which case id takes precedence
DasSkelett[m] has joined #spacedock
<DasSkelett[m]>
We might have to set up _something_ to handle config changes for the future.
<DasSkelett[m]>
Don't ask me how this something should look like.
VITAS[m] has joined #spacedock
<VITAS[m]>
config changes of config ini or the whole of alpha, beta, prod and github?
<DasSkelett[m]>
config.ini, what broke alpha earlier because of my PR
<VITAS[m]>
shouldnt config.ini be on ignore?
<VITAS[m]>
and not be overwritten by git
<DasSkelett[m]>
Maybe getting the value from config.ini.example (which should be updated in the PR changing config keys itself) if the key is not present in the normal config.ini, and somehow write the new key+value in config.ini?
<DasSkelett[m]>
I think config.ini is already ignored
<VITAS[m]>
config.ini should never be auto updated new config values should be rarly neccesary and we could do manual updates?
<VITAS[m]>
we could think about ways to manualy updat ethe config ini easier and also to signal the need for config ini edeting
<DasSkelett[m]>
Yeah auto-updating it doesn't sound good, security and stuff.
<DasSkelett[m]>
I fear config changes are forgotten in the long delay between initial PR and push to beta / prod. We somehow have to make sure the guy merging from alpha to beta and from beta to master knows what changes he has to do in the config.ini **immediately** after merge.
<VITAS[m]>
idea: something like db migrations
<VITAS[m]>
maybe there is such a thing for files in general
<VITAS[m]>
to detect structual changes to config and thus the requirement to alter config ini
<DasSkelett[m]>
Maybe a new big red GitHub label `Config changes` for PRs, and the one creating the PR to beta or master has the responsibility to check whether one of the so labeled PRs is included in this one, and point it out in his PR body text.
<VITAS[m]>
OR simply flag config changes (maybe by incrementing a counter and compairing it to the exisiting one in a file on the server) and an err msg on the site if config changes need to be made
<VITAS[m]>
that too
<VITAS[m]>
but we need some visible error on the site or somewhere visible when you actualy deploy the code without changes
<DasSkelett[m]>
I think those two ideas can be combined, and probably should be. Better know beforehand if production will break.
<VITAS[m]>
yes but as you said people will overlook tags
<VITAS[m]>
and so youre right
<VITAS[m]>
combination of all those
<RockyTV>
we should setup defaults
<VITAS[m]>
that too
AllisTauri[m] has quit [Quit: Idle timeout reached: 10800s]
DasSkelett[m] has quit [Quit: Idle timeout reached: 10800s]
VITAS[m] has quit [Quit: Idle timeout reached: 10800s]