[
https://issues.apache.org/jira/browse/BEAM-4691?focusedWorklogId=121444&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-121444
]
ASF GitHub Bot logged work on BEAM-4691:
----------------------------------------
Author: ASF GitHub Bot
Created on: 10/Jul/18 15:20
Start Date: 10/Jul/18 15:20
Worklog Time Spent: 10m
Work Description: lgajowy edited a comment on issue #5831: [BEAM-4691]
(do-not-merge-yet!) Move perf tests to a separate directory and rename them
(conventionally)
URL: https://github.com/apache/beam/pull/5831#issuecomment-403860530
@swegner @Ardagan ok, today I learned a little bit more about the
possibilities we have. I've done another PR to dig into this from a different
angle (https://github.com/apache/beam/pull/5915).
__I think we cannot have both:__ directories and common files (such as
`CommonProperties.groovy`). I successfully moved `HadoopInputFormatIOIT` to a
separate directory but no matter what I tried (keeping CommonProperties in
.jenkins and import or moving it to a "common" directory and then import) I
couldn't run the seed job successfully.
One last idea that comes to my mind is to merge job files that have the same
category. We would then have `PerformanceTests.groovy`, `PostCommit.groovy`,
`PreCommit.groovy`, etc. I consider this idea because:
- we could have multiple jobs per one file
- we could extract some handy methods for creating jobs per each category.
Such methods could be hidden in corresponding files (eg. method for creating a
post-commit job would reside in PostCommit.groovy class)
- because we're using groovy here, methods for creating jobs could accept a
map as a parameter. Such map can be very readable and clean. We do something
like this in
[FileBasedIOIT](https://github.com/apache/beam/blob/master/.test-infra/jenkins/job_PerformanceTests_FileBasedIO_IT.groovy)
- we could keep stuff like CommonProperties etc. where it is now and use it
as before. At the same time, category specific methods can remain hidden in
categories' files (eg. kubernetes related methods could be hidden in a
PerformanceTests.groovy file).
The drawbacks I see:
- it may be harder to find a specific job in a common file
- it may be easier to break many things at once due to common code (IMO,
we're vulnerable to this either way)
- ???
WDYT? I ask for your opinions first because you recently worked on some
refactoring and maybe have some thoughts in this matter.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 121444)
Time Spent: 1.5h (was: 1h 20m)
> Rename (and reorganize?) jenkins jobs
> -------------------------------------
>
> Key: BEAM-4691
> URL: https://issues.apache.org/jira/browse/BEAM-4691
> Project: Beam
> Issue Type: Task
> Components: build-system
> Reporter: Lukasz Gajowy
> Assignee: Lukasz Gajowy
> Priority: Minor
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Link to discussion:
> [https://lists.apache.org/thread.html/ebe220ec1cebc73c8fb7190cf115fb9b23165fdbf950d58e05db544d@%3Cdev.beam.apache.org%3E]
> Since jobs are Groovy files their names should be CamelCase. We could also
> place them in subdirectories instead of prefixing job names.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
