<ocdtrekkie>
coffeebird[m]: Only Kenton can change the topic here.
<ocdtrekkie>
Also, I do not think anyone reads the topic.
<ocdtrekkie>
People often come here, ask a question, leave before anyone answers it, and do not post on the mailing list, where people can actually respond and get back to them. :P
<ocdtrekkie>
I feel like if reading the topic was a thing people were prone to do, more of those questions would actually make it to the discussion group.
samba_ has quit [Quit: WeeChat 2.0.1]
<simpson>
I've found that, in general, people don't read.
<coffeebird[m]>
most people don't care to idle on irc. Thankfully I can use the matrix bridge
AZero has quit [Read error: Connection reset by peer]
XgF is now known as gay
gay is now known as XgF
jemc has quit [Ping timeout: 246 seconds]
<ocdtrekkie>
Kinda awesome: A new version of the Gogs package is now in the experimental market.
<ocdtrekkie>
...It's amazing how much Gogs looks exactly like GitHub though. o.O
<ocdtrekkie>
I just want to test the cloning feature and then it'll be approved, everything looks good.
pie__ has quit [Ping timeout: 240 seconds]
<ocdtrekkie>
(It's approved!)
<ocdtrekkie>
I am also excited that WordPress will probably get updated on Sandstorm soon too.
jemc has joined #sandstorm
<TimMc>
ocdtrekkie: Does the Gogs package allow anonymous visitors to browse the code? Gitlab package doesn't. :-/
<ocdtrekkie>
I do not know for I did not check.
<TimMc>
k one sec :-)
<TimMc>
(hmm... link to Gogs experimental?)
<ocdtrekkie>
I am testing. Moment.
<ocdtrekkie>
It's approved already.
<ocdtrekkie>
Yes, I can see code anon.
<TimMc>
sweeeet
<ocdtrekkie>
And by "code", I mean the text of the LICENSE file I put in an empty repo to test with.
<ocdtrekkie>
Note that you can mark Gogs repos as "private", and I'd guess in those cases anon users could probably not see them. :P
<TimMc>
Oh hmm, gitlab is grain-per-repo, gogs is grain per... bunch of repos.
<ocdtrekkie>
Explore tab will show you my test repo.
<TimMc>
ocdtrekkie: Small issue in Gogs: Can't update profile without changing email from the pre-filled value, which is buncha-hex@localhost. Wonder what that's about...
<ocdtrekkie>
TimMc: I would probably report that in the repo for it. :P
<TimMc>
Where does that email even come from, though?
<TimMc>
Maybe I'll just report it as-is, without a "this is what I want instead" component.
* Zarutian_PI
thinks from the Hex-ia De Trix witch of Duck Tales.
<kentonv>
`git push` is giving me an error
<TimMc>
I really like how similar this is to Github, tbh.
<ocdtrekkie>
Hmmm... I didn't have anything to push, I tested a clone and a pull.
<ocdtrekkie>
TimMc: It is comfortingly similar, but it is also "is this infringement somehow" similar. :P
<TimMc>
Unlike gitlab, it actually puts the files front and center, which is... what I usually want, when going to a repo. -.-
<TimMc>
heh yes
<kentonv>
yeah clone and pull seem to work but push does not... :/
<TimMc>
"pre-receive hook declined"
<kentonv>
let's un-publish the package for now
<kentonv>
(done)
<TimMc>
"remote: Gogs: Internal error" as well
<ocdtrekkie>
I just stumbled through enough git commands to find that error.
<kentonv>
I think the main error is "remote: Gogs: Internal error"
<kentonv>
and "pre-receive hook declined" is a side-effect of that
<ocdtrekkie>
Well, I tested that data survived the upgrade, and that I could connect to and clone a repo. Now I know what happens when I assume I tested enough. :/
<kentonv>
don't feel bad, there are *so many* things I failed to test with the HTTP rewrite
<kentonv>
I would totally have thought testing a pull was enough, except that I just recently fixed a bug in the HTTP rewrite that specifically broke pushes... from Mercurial... specifically very-old versions of Mercurial....
<ocdtrekkie>
So in pre-receive.log in my grain after I tried a push.
<ocdtrekkie>
2018/03/14 03:08:40 [FATAL] [...its/gogs/cmd/serv.go:88 setup()] SetEngine: Fail to connect to database: Fail to create directories: mkdir data: read-only file system
xet7 has quit [Read error: Connection reset by peer]
xet7 has joined #sandstorm
xet7 has quit [Remote host closed the connection]
xet7 has joined #sandstorm
xet7 has quit [Remote host closed the connection]
xet7 has joined #sandstorm
jemc has joined #sandstorm
<TimMc>
ocdtrekkie: Some integration test frameworks allow you to ignore certain tests or collections of tests, but I think the hardest part would be adapting things like Selenium or other headless browser tests to go into the inner frame.
compuguy has quit [Ping timeout: 256 seconds]
samba_ has joined #sandstorm
XgF is now known as gay
gay is now known as XgF
Telesight has joined #sandstorm
ocdtr_web has joined #sandstorm
<ocdtr_web>
TimMc: I was just thinking like... rather than running tests inside the Sandstorm grain, having your test suite run normally, but have some way to tell the test additionally to fail if it tries to write to anything but /var, or tries to read /proc, or tries to reach an address that isn't 0.0.0.0 or 127.0.0.1.
<ocdtr_web>
Because that shortlist is effectively most of the ways apps in a Sandstorm grain fail to run.
<TimMc>
Oh yeah, I suppose if you run the integration test *inside* the container, that works.
<TimMc>
and I suppose that's how it's usually done with spk
<ocdtr_web>
It'd be interesting to see what would be involved in including and launching tests inside the container. Presumably you wouldn't want that in your end product spk though.
<ocdtr_web>
I had just been thinking about testing outside of Sandstorm entirely, but somehow monitoring for things we known Sandstorm apps can't do.
<ocdtr_web>
s/known/know
<TimMc>
Ah, yeah.
isd has joined #sandstorm
xet7 has quit [Quit: Leaving]
xet7 has joined #sandstorm
Telesight has quit [Remote host closed the connection]
<ocdtr_web>
cem just pushed and updated Gogs, I will see if I can git push with it in a few hours.
<ocdtr_web>
Experimental market has always done that. ;)
<ocdtr_web>
It's because the last updated date is the date that the packageId is approved. And the experimental market has packages which have not been approved.
<TimMc>
Ah, date of -1?
<TimMc>
or of 0, with time zones maybe
<ocdtr_web>
It's presumably something of that nature.
<TimMc>
Anyway, it appears to still have the push problem.
<ocdtr_web>
:(
<TimMc>
Still that same problem: "Fail to connect to database: Fail to create directories: mkdir data: read-only file system"
<ocdtr_web>
I presume you pushed "Upgrade grains" and the like before testing?
<TimMc>
Hmm... I installed from your link, and there was a big "Upgrade" button (instead of install). Is there a separate step required for upgrading existing grains?
<TimMc>
(found it!)
<ocdtr_web>
Yes
<TimMc>
OK, so it's on the app's page on my instance.
<ocdtr_web>
Yes, generally when you click the Upgrade button, it redirects you to that page next.
<TimMc>
wooo!
<TimMc>
git push worked.
<ocdtr_web>
(Kenton intends to change the way apps/grains upgrade so everything is automatic, but there needs to be some sort of way to pin old versions and undo broken things before he can do that.)
<TimMc>
It probably redirected me to that page, but I didn't see the notice.
<ocdtr_web>
I have ferrets and a chinchilla, but I had INTENDED to have rats.
<ocdtr_web>
Sometimes I end up with animals I did not intend.
<TimMc>
A friend of mine has had a long-time obsession with ferrets, ended up fostering some rats, and now has her own pet rat and no more desire for ferrets. Close enough, I guess. :-P
<ocdtr_web>
I would not immediately think "Git" when I think of where to put recipes. I probably would've used Etherpad or Wekan. But this is a pretty nice presentation.
<ocdtr_web>
My dad is an exotic animal vet, I end up with take-homes from his clinic. I've never bought a pet, as the case is.
<TimMc>
It started out when I was trying to figure out a way to store multiple variations on recipes. They change over time, you know? And recombine elements from past variations. Kind of DAG-like.
<TimMc>
And it's not just the ingredients that change, but the process.
<ocdtr_web>
I saw that, you had various alterations listed by date.
<TimMc>
Originally I was going to have a separate *commit* for every version of the recipe, and the commit's tree would have a single file, the recipe as it was made on that day. New variations would have one or more parents.
<TimMc>
But that's a total pain in the butt, and it turns out that *most* of the time it's only the ingredients that change, hence my current usage. :-)
<TimMc>
(And I can still just re-copy the directions each time if I want, with a note about what changed, if necessary.)
<TimMc>
I still might make a fluent front-end for the original idea some day.
<TimMc>
(In parallel I also slowly came to the realization that the history of the recipes was a first-class object of interest, and git is bad for that, since you can't fix typos in the history without rewriting the whole thing.)
xet7 has quit [Quit: Leaving]
<ocdtr_web>
I am off to other places, but thanks for testing the thing! I will probably push it through when I get home, and then hopefully Kenton can be excited about the update without being immediately sad to discover it is broken.
<TimMc>
++
ocdtr_web has quit [Quit: Page closed]
xet7 has joined #sandstorm
<TimMc>
Cool, if I share access, and then use the clone credentials from *that* page, I get an anonymous (albeit bulky) clone URL for git: git clone https://yeind:cgk5K1vRbWmaSVqqUqwcfGfca_YymN67iZF-1nHLb9N@api-1b42d5620f96595bc705f32de9d84865.sandy.parsni.ps/timmc/recipes.git recipes