Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-tck-dev] TCK "Promotion" 


On 8/15/20 5:04 PM, David Blevins wrote:

On Aug 5, 2020, at 7:08 PM, Scott Marlow <smarlow@xxxxxxxxxx> wrote:

IMO, in the first pass of this change, just adding the SHA to the filename would be enough.  Especially since we have already staged the Standalone TCKs via https://ci.eclipse.org/jakartaee-tck/job/eftl-standalonetck-build-run-900 but will stage TCKs again on an as needed basis.

Your changes could probably go directly inline to https://ci.eclipse.org/jakartaee-tck/job/eftl-standalonetck-build-run-900/config


Ok, finally have something working.  First the results:

  - https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee9-eftl/staged-900/history/
Wow, nice to see the date + SHA included (e.g. jakarta-jakartaeetck-9.0.0-2020-08-15-18714851ee2d1af691263c1b2e9edf6ef496732537cf9c769ff9ade4eb14ce8f.zip)! 



Every time a build is run and the publishing step happens the same binary is also uploaded to the `history` directory with an expanded name.  If at any time a project wants to promote a specific TCK, they can indicate the one they want by date or SHA (ideally SHA).  We keep up to 5 builds of the TCK which should give us enough history.

Because we're uploading the same binary twice, once with expected name and once with the expanded name, no one should have to update any builds to account for a name change.  As long as people put the SHA in their TCK results, we're completely fine and there really is no need to adjust or remove the binary with the short and more human readable name.

Here's the PR we need to merge:

  - https://github.com/eclipse-ee4j/jakartaee-tck-tools/pull/3

This introduces a new `jobs` directory that currently looks like this:

  - jobs
  - jobs/common
  - jobs/common/backup.sh
  - jobs/eftl-jakartaeetck-build-900
  - jobs/eftl-jakartaeetck-build-900/publish.sh
Would it make sense to keep the copying of files and other eftl-jakartaeetck-build-900 specific aspects in the Jenkins eftl-jakartaeetck-build-900 job?
If yes, perhaps we could instead have some reusable jobs/common/*.sh scripts that could be used by the various Jenkins jobs. Leaving the "duplicate logic in Jenkins jobs" alone for now. 



The Jenkins job for `eftl-jakartaeetck-build-900` now simply refers to this script like so:

     #!/bin/bash -x
git clone https://github.com/eclipse-ee4j/jakartaee-tck-tools.git && 
     ./jakartaee-tck-tools/jobs/$JOB_NAME/publish.sh

Rather, that's what we should update it to once the PR is merged.  Currently it actually points to my fork.

If we like the pattern, we could expand it to include other builds.  For example:

  - jobs/eftl-jakartaeetck-build-900/run.sh
  - jobs/eftl-jakartaeetck-run-900/run.sh
  - jobs/eftl-jakartaeetck-run-web-900/run.sh
  - jobs/eftl-standalonetck-build-run-900/run.sh
  - jobs/jakartaee-tck-alwin/run.sh
  - jobs/jakartaee-tck-grao/run.sh
  - jobs/jakartaeetck-nightly-build-master/run.sh
  - jobs/jaxb-tck-grao/namespace-change/run.sh
  - jobs/jaxb-tck-grao/master/run.sh
  - jobs/standalonetck-nightly-build-run-master/run.sh

 From there we can start to eliminate the copy/paste reuse by putting anything reusable here:

  - jobs/common/*

You can effectively "import" them in a script like so:

  - https://github.com/eclipse-ee4j/jakartaee-tck-tools/blob/74a931588bce3c6c2a495546f350f9e17de69418/jobs/eftl-jakartaeetck-build-900/publish.sh#L3-L6

Then you can simply refer to all the sourced functions in the script:

  - https://github.com/eclipse-ee4j/jakartaee-tck-tools/blob/74a931588bce3c6c2a495546f350f9e17de69418/jobs/eftl-jakartaeetck-build-900/publish.sh#L49-L51

Considering most of our scripts are duplicates in some way, this pattern could really reduce the overhead of maintaining all that.  It'd be very easy to roll out changes that improve all related builds.


Thoughts?
I am concerned about the impact on the Jakarta EE 9 release schedule and the impact on the current process that we are following for staging/promoting TCKs. Perhaps we could figure out an incremental way to include the SHA+Date in some TCK names that doesn't change the current process that is now being used actively. 

Scott




-David




_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev

Back to the top