search

assimilation / assimilation-official

This is the official main repository for the Assimilation project
51 stars 9 forks source link

bintray test #54

Closed borgified closed 6 years ago

borgified commented 6 years ago

i want to finalize the configs for descriptor_file before we merge @Alan-R can you help? i filled in the places where i knew the answer and left alone the ones that i did not.

documentation about what these fields mean: https://docs.travis-ci.com/user/deployment/bintray not all fields are mandatory: https://github.com/bintray/bintray-examples/blob/master/travis-ci-example/descriptor.json

borgified commented 6 years ago

there's also some request to make the contents of descriptor_file more dynamic: https://github.com/travis-ci/travis-ci/issues/7880

oh yea this is supposed to fix #52

Alan-R commented 6 years ago

So, looking at the pull request, here are things I wonder about...

Putting keys unencrypted into source control is a really, really bad idea... There are people who harvest those from github automatically. We will get hacked. Whatever key you put in here should be disabled.

The license is wrong - ours is GPLv3.

Do we have a file called RELEASE.txt?

Not sure what attributes we want to put in the attributes section. What's it used for - or how should it be used? Ditto for labels...

I'm not certain that I want to publish every version that we build automatically - and that we only want to publish .deb packages for a single version of Ubuntu (and an obsolete one at that). Moreover, I'm pretty certain we don't want to do that...

I think what we need is a way to build for our dozen or so versions of Linux that we make full releases for and then have a repository for each of these OSes. We need to be able to do this in two different ways:

1) For testing - that is, not being certain that all dozen or so versions will build and work. I don't see any reason to trigger this with every build. 2) For a release - once they're built and we know they work.

Other thoughts...

We must sign our packages - but the keys can't be in source control unencrypted.

I want to continue to have Travis build one version for us and say "build passing". But I also want another mechanism to build releases. I specifically don't want to publish public packages for every time we push to github.

So, how should we do this?

Alan-R commented 6 years ago

Of course, if you're using the Travis encryption method, then ignore my comments about key security ;-)

borgified commented 6 years ago
borgified commented 6 years ago

the build is using trusty because thats what travis-ci is using: https://travis-ci.org/assimilation/assimilation-official/builds/356712724#L7

Build system information
Build language: c
Build group: stable
Build dist: trusty

there's probably ways to to build for other versions of ubuntu even if we're sitting on trusty but i havent figured that out yet

Alan-R commented 6 years ago

I don't think that Travis is going to be able to build for 12 (or so) versions of Linux. This includes 2 versions of Red Hat, one or two for SuSE, at least 2 for Debian, and whatever the current Ubuntu versions are.

Maybe the best bet is to follow our build scripts - which then build everything inside docker. See "docker/builditall" for the full details... But this takes quite a while, and I suspect they won't like doing that much work for us for free...

Either we need to just let Travis do the tiny bit of work it's doing now (on an obsolete version of Ubuntu) to do some basic error checks, or get it to do everything.

But where ever we do "everything" that's where the connection to jfrog needs to be. Jfrog needs to host all the versions we plan on supporting (whatever those are). Whatever we decide, it will be much more than just "trusty".