[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-tck-dev] TCK "Promotion"
|
First, apologies as I merged before seeing there were responses on this thread.
> On Aug 26, 2020, at 7:35 AM, Scott Marlow <smarlow@xxxxxxxxxx> wrote:
>
>
>> 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.
Completely agree on any sentiments that eliminating duplication is low or no priority at this stage. I tried to strike this balance in doing the change:
- Anything pre-existing in the script, leave it as-is and don't improve it (don't fix what isn't broken)
- Anything new being added to the script, try to think ahead and not perpetuate copy/paste mess
I also took care to check the script in unmodified and then did the change so we can get diffs and git "blame" like this:
- https://github.com/eclipse-ee4j/jakartaee-tck-tools/blame/master/jobs/eftl-jakartaeetck-build-900/publish.sh
The primary motivation for moving the script into git was to get good revision control, diffs, commit messages, "blame" and peer-review via PRs. Jenkins has job config history, but no commit messages and no ability to do diffs or see what was changed.
All that said, I'm very pragmatic in understanding long threads drain resources, so if you feel uncomfortable with the script source in git let's move it back and revisit when things are less hectic. I probably wouldn't mix the two as suggested.
Long-term I think there is room for a super small "script" living in Jenkins that is maybe top 10 lines; just enough to checkout the scripts and invoke one with the right parameters. I didn't do that as that's definitely higher impact.
>
>> 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.
I have the same concern, so took great care to in no way change the existing publishing and simply publish the zips again in a new area. The idea being any existing jobs that expect the script in the known location with the known name will all still work.
However, we now have the perk that a human being could say "Hey Scott, can you promote the TCK with this SHA?" and you'd have some realistic way to find it if it was one of the last 5 builds.
Do you think that strikes the right balance or is there still a concern?
-David
