Skip to content
This repository was archived by the owner on May 10, 2018. It is now read-only.

Conversation

@Aaron1011
Copy link
Contributor

Don't merge this yet.

@Aaron1011
Copy link
Contributor Author

@henrikhodne: Do you know why the database query I'm using doesn't seem to be working?

@Aaron1011
Copy link
Contributor Author

@henrikhodne: Do you know what's wrong with the query I'm using?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure if this is correct. This means that the status image could have "pending" (created/queued/running) as a status instead of just passed/failed/errored.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@henrikhodne: I think you're right. Do you know how I would get the last created (not the last finished) build?

Copy link
Contributor

Choose a reason for hiding this comment

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

Build#last_build_on sorts by ID, so I think that is the current behaviour?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@henrikhodne: I don't think so. Take a look at the builds for this repo. The most recent build is failing, but I restarted an earlier build that's passing. The build status image shows passing, even though the last created build is failing.

Copy link
Contributor

Choose a reason for hiding this comment

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

That's probably because the cache is being overwritten, the DB query still returns the correct data:

>> repo = Repository.where(owner_name: "Aaron1011", name: "travis-npm-deploy").first
=> #<Repository id: 1356021>
>> build = repo.last_build_on("master")
=> #<Build id: 16326767>
>> build.state.to_sym
=> :failed

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@henrikhodne: Okay, then. So it looks like the status image behavior won't need to be changed.

Copy link
Contributor

Choose a reason for hiding this comment

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

No, I think this change needs to be made in the StatesCache addon.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@henrikhodne: I've changed it. I'll write a test soon.

Copy link
Contributor

Choose a reason for hiding this comment

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

Is this change needed?

@sarahhodne
Copy link
Contributor

@Aaron1011 This needs to use the updated method name from #318, then I think this can be merged.

@Aaron1011
Copy link
Contributor Author

@henrikhodne: Okay, I've changed it.

@Aaron1011
Copy link
Contributor Author

@henrikhodne: Can you restart the jruby-19mode job?

@sarahhodne
Copy link
Contributor

Merged as 1b427c8.

@sarahhodne sarahhodne closed this Jan 27, 2014
Copy link
Contributor

Choose a reason for hiding this comment

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

@Aaron1011 @henrikhodne just to confirm, does this change mean that the states cache is only updated when the build is for the default branch? (eg. master)

Copy link
Contributor

Choose a reason for hiding this comment

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

That is the purpose of the PR, yes.

Copy link
Contributor

Choose a reason for hiding this comment

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

The states cache stores per branch info in Redis, so this means we are not storing all info in Redis anymore, meaning requests for other branches (.png?branch=foo) would have to be checked with the DB. Is this really what we want?

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh right, I'm sorry, I forgot that's what the state cache was doing. I agree that this change is wrong, then. Feel free to revert, otherwise I can do it tomorrow.

Copy link
Contributor

Choose a reason for hiding this comment

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

If it's alright I'll leave it for you to look into tomorrow. (I need to disappear shortly)

@BanzaiMan
Copy link
Contributor

I reverted this commit. See c868d4d.

@BanzaiMan BanzaiMan reopened this Jan 29, 2014
@Aaron1011
Copy link
Contributor Author

@henrikhodne @joshk: I think the correct behavior is to only update the cache if the build is the most recent on the given branch, instead of on the default branch. Does that sound right?

@JamesMGreene
Copy link

Ping!

@Aaron1011's last comment sounds like to me after a cursory glance. Can anyone else confirm? @henrikhodne @joshk @BanzaiMan @svenfuchs

@joshk
Copy link
Contributor

joshk commented Jan 12, 2015

Sorry, I'm going to close this for now as we have some big changes in the works which will fix this on the UI level first, then in the back end code.

@joshk joshk closed this Jan 12, 2015
@JamesMGreene
Copy link

@joshk Any publicly accessible reference for those incoming changes that I can track?

@joshk
Copy link
Contributor

joshk commented Jan 12, 2015

Not at the moment sorry. If you would like to apart of some UI testing send an email to support. (the page I am user testing will give you some insight into what is coming in Feb)

@Aaron1011
Copy link
Contributor Author

My head is spinning with all this activity on a PR I made over a year ago :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants