Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FIXED JENKINS-28843] Stored the unique value in the job configuration #1

Merged
merged 15 commits into from Jun 11, 2015

Conversation

jtnord
Copy link
Member

@jtnord jtnord commented Jun 11, 2015

JENKINS-28843

unique id plugin stored the unique value in the job configuration.

@reviewbybees

*/
public abstract void make(T object);
public abstract void make(T object) throws Exception;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It causes a binary compatibility issue, but I doubt anybody uses the plugin's API actively. Let's bump the major version digit BTW

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes - but the alternative is to make this return a boolean and have callers check.
Neither are good in my opinion - I could change this to be IOException (but that is specific to our implementation )

@oleg-nenashev
Copy link
Member

I'm working on the failing test

if (jenkins == null) {
throw new IllegalStateException("Jenkins is null, so it is impossible to migrate the IDs");
}
File marker = new File(jenkins.getRootDir(), "IdStoreMigration.txt");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could we use a name that makes it clear what plugin the file is for, e.g. unique-id-migration.txt

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps make this a hidden file i.e. named something like .IdStoreMigrationCompleted.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will change. I'm not convinced about hiding the file so will go with @stephenc's suggestion

@stephenc
Copy link
Member

otherwise looks ok from a code review PoV

*/
public static String getId(Object object) {
public static String getId(Object object) throws IllegalArgumentException, Exception {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a fallback to a legacy store is required here (as I've understood initial test suites)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No - there should be no fallback at all.
The legacy store must be migrated at first run and then removed if it exists.

@tfennelly
Copy link
Member

Are the binary compatibility changes here not a bit risky? Even the fact that there's no longer an Id action on these objects. I would not be at all surprised if external processes have developed dependencies on the Id action and its presence.

Maybe I don't understand the problem fully but would it not be possible to leave all the IdStore impls as they are and just change the Id action impl and how it works. Instead of it storing an id, it instead stores the path to the object, from which the location of the unique-id.txt file can be resolved - store, read etc. I suppose that breaks after a move of the object. Hmmm....

@tfennelly
Copy link
Member

There's no funky Jenkins way for an Action instance to get a handle on the model object(s) with which it is associated?

@oleg-nenashev
Copy link
Member

Added jtnord#1 for post-restart migrations. It also fixes the failing IdTest

Change the filenames so that they are more easily identified with this
plugin.
Fix some typos.
@oleg-nenashev oleg-nenashev mentioned this pull request Jun 11, 2015
@tfennelly
Copy link
Member

So there's no possibility of a post copy/replicate task extension point? Seems like a general thing that would make sense.

If there was, maybe a DeleteUniqueId implementation could clear the unique id on the target after copying.

@jtnord
Copy link
Member Author

jtnord commented Jun 11, 2015

after discussion with the plugin maintainer it has been decided to perform migration of IDs for Runs after startup to not block startup for so long. Also Runs do not need special handling and can use the same text marker as jobs/folders.

@jglick jglick changed the title [WIP] Jenkins-28843 [WIP] [JENKINS-28843] Stored the unique value in the job configuration Jun 11, 2015
import org.jenkinsci.plugins.uniqueid.IdStore;

/**
* Stores id's for runs as an action on the Run.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This Javadoc is obsolete I guess.

Use standardCharset to avoid UTF-8 related issues.
@tfennelly
Copy link
Member

@jtnord I raised some questions/points that were not answered/addressed. Maybe that's coz they were considered to be stupid, but maybe they should be answered in some way (even if they're called out as being stupid questions 😄 ).

@jtnord
Copy link
Member Author

jtnord commented Jun 11, 2015

@tfennelly sorry I thought I had addressed or replied to them all.

So there's no possibility of a post copy/replicate task extension point? Seems like a general thing that would make sense.

If there was, maybe a DeleteUniqueId implementation could clear the unique id on the target after copying.

The internal implementation can filter out files - so it would just filter out these files.
if we want something else I think we can evolve the API in the future?

@jtnord jtnord changed the title [WIP] [JENKINS-28843] Stored the unique value in the job configuration [JENKINS-28843] Stored the unique value in the job configuration Jun 11, 2015
@jtnord jtnord changed the title [JENKINS-28843] Stored the unique value in the job configuration [FIXED JENKINS-28843] Stored the unique value in the job configuration Jun 11, 2015
// all done...
final long duration = System.currentTimeMillis() - startTime;
final long minutes = TimeUnit.MILLISECONDS.toMinutes(System.currentTimeMillis() - startTime);
final long seconds = TimeUnit.MILLISECONDS.toMinutes(System.currentTimeMillis() - startTime - TimeUnit.HOURS.toMillis(minutes));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be TimeUnit.MILLISECONDS.toSeconds()

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TimeUnit.MINUTES at the end?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed - good spot.

@oleg-nenashev
Copy link
Member

👍

1 similar comment
@recampbell
Copy link
Member

👍

jtnord added a commit that referenced this pull request Jun 11, 2015
[FIXED JENKINS-28843] No longer stored the unique value in the items configuration.
@jtnord jtnord merged commit ea9a8df into jenkinsci:master Jun 11, 2015
</scm>

<properties>
<maven.compiler.source>1.7</maven.compiler.source>
<maven.compiler.target>1.7</maven.compiler.target>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May also want to change the Animal Sniffer execution.

Apparently even the current plugin POM does not define java.level like Jenkins core itself does. Something to be fixed in a future version of the POM.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's currently working. I'll leave that to someone for a future excesize (along with using a recent core)

@jglick
Copy link
Member

jglick commented Jun 11, 2015

A bit late to the party but: 👍, with some low-importance comments that could be addressed later.

jtnord added a commit that referenced this pull request Jun 11, 2015
Tweak logging levels andload actions to force lazy loading.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
7 participants