yetus-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allen Wittenauer ...@effectivemachines.com.INVALID>
Subject Re: [DISCUSS] YETUS-683
Date Fri, 16 Nov 2018 23:28:38 GMT


> On Nov 14, 2018, at 5:11 PM, Sean Busbey <busbey@apache.org> wrote:
> 
> "latest" sounds like something a downstreamer should use to stay up to
> date, so I'd rather have it track release and name the current master
> branch image "master”.

	I’m actually leaning towards not having a latest.  ‘latest’ is particularly loaded
when it comes to Docker and we probably want folks to manually switch from one version to
another.  e.g., what happens when latest switches from a 1.0 to 2.0?  likely major carnage.
 I’m also thinking the same thing about branches.  In the end, that would leave us with
(e.g.):

apache/yetus-base:master    <- pre-reqs to run master
apache/yetus-base:0.9.0      <- pre-regs to run 0.9.0

apache/yetus:master             <- yetus-base:master + master installed in /usr
apache/yetus:0.9.0               <- yetus-base:0.9.0 + 0.9.0 installed in /usr


From a practical perspective, this would make a Jenkins pipeline+Github Source Plugin (post-YETUS-681
and all of its dependents, which auto-resolves a lot of the command line parameters) file
look something like this if the yetus Dockerfile has everything a build needs from the OS:

pipeline {
	agent {
		docker ‘apache/yetus:0.9.0’
	}
	options {
		checkoutToSubdirectory(’src’)
	}
	stages {
		steps {
			sh ‘’’#!/usr/bin
			test-patch —basedir=${WORKSPACE}/src —plugins=all —patch-dir=${WORKSPACE}/out
			‘’'
		}
	}
	post {
		dir(“${WORKSPACE}”) {
			archiveArtifacts artifacts: ‘out/**/*'
		}
	}
}

If there are no other comments, I’ll start a vote thread to work out the logistics with
INFRA to get images uploaded.

Thanks!


Mime
View raw message