www-builds mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kenneth Knowles <...@google.com.INVALID>
Subject Re: Nightly build & push of Docker image(s) to bintray?
Date Mon, 13 Nov 2017 18:52:48 GMT
Following up here -

Have you (or anyone else) set up a bintray "role" account (or some such)
specifically for the purpose of having Jenkins push to a non-release
repository?

We have a place to push, we just need Jenkins to be allowed to do so. I
know very little about how Jenkins is allowed to push to Nexus, but I
assume it should be roughly analogous so the security scenario is no worse.

Context is https://issues.apache.org/jira/browse/INFRA-15382 which is
moving right along.

Kenn

On Fri, Oct 20, 2017 at 2:22 PM, Kenneth Knowles <klk@google.com> wrote:

> Thanks for the heads up!
>
> When it comes to jars, I believe what we do is the usual and allowed
> process for release candidates / nightly test jars. They go to the snapshot
> repository [1], per the Release Policy [2] and ASF Jar FAQ [3]. So when it
> comes to jars, I am fairly sure what we are doing is OK.
>
> We have established the apache/beam-docker [4] repository for our official
> releases (there are no releases of this feature yet). So I was hoping to
> have an approved place to push release candidates / nightly test images.
> These are exactly analogous to the jars above, and are somewhat necessary
> companion artifacts.
>
> The answer could be as simple as "create apache/beam-docker-snapshots and
> get credentials onto your Jenkins workers", but TBH I'm not sure how
> Jenkins has credentials to push jars with `mvn deploy` nor how best to set
> up something analogous for `docker push`. But I'm sure this is something we
> could just figure out, once we know where we want to push.
>
> The answer could also be that we are on our own and we just need to follow
> the distribution guidelines. That is currently our status, and developers
> have to push their own containers to their own docker repos and pass magic
> command line flags for testing. But ideally there would be a nicer default
> for developers who were not touching these docker images, which are only a
> subcomponent of our project.
>
> Kenn
>
> [1] https://repository.apache.org/content/groups/snapshots/org/apache/
> [2] http://www.apache.org/legal/release-policy.html#host-rc
> [3] https://www.apache.org/dev/repository-faq.html#revolutioncode
> [4] https://bintray.com/apache/beam-docker
>
> On Fri, Oct 20, 2017 at 1:49 PM, Joan Touzet <wohali@apache.org> wrote:
>
>> Be very careful here. Making such binaries available outside of your
>> immediate developer community is a violation of Apache policy:
>>
>>   http://www.apache.org/dev/release-distribution.html#unreleased
>>
>> The middle two bullet points are the issue here.
>>
>> CouchDB decided to build packages and binaries off of master and
>> post them to a URL that is only shared on request to developers of
>> the project. As for Docker, especially because we now occupy the
>> apache/couchdb namespace, we only push official releases there, and
>> only publish a Dockerfile people can use for building off of master.
>> We could conceivably have our own Docker registry for master builds,
>> I guess, but the demand hasn't been there.
>>
>> Now that the scary warning is over ;) bintray's API docs are pretty
>> clear, and it shouldn't be too hard to auto-push to it if you need to.
>>
>> -Joan
>>
>> ----- Original Message -----
>> From: "Kenneth Knowles" <kenn@apache.org>
>> To: builds@apache.org
>> Sent: Friday, 20 October, 2017 4:38:28 PM
>> Subject: Nightly build & push of Docker image(s) to bintray?
>>
>> Hello from the Beam project,
>>
>> We have a Jenkins build that pushes a snapshot jar every 24 hours (if
>> tests
>> pass) and we would like to have the same for docker images that form a
>> core
>> part of the Beam project.
>>
>> Can you advise on the best way to go about this?
>>
>> I am aware of the use of bintray for Docker repository and my own account
>> is hooked up, but this would be a CI thing. Any pointers to docs or other
>> projects doing similar things would be super, too, and I am of course
>> happy
>> to do my homework if you can offer a pointer.
>>
>> Kenn
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message