782237 - Please update treestatus stage/prod to 257a811e8ef1e05e97eda144247b94cb62403015 to pick up no-cache fix

Status: RESOLVED FIXED

(Infrastructure & Operations Graveyard :: WebOps: Other, task)

Description

[Ed Morley [:emorley]]

+++ This bug was initially created as a clone of Bug #781579 +++

Please may treestatus stage/prod be updated to:
https://github.com/catlee/treestatus/commit/257a811e8ef1e05e97eda144247b94cb62403015

(Blocking bug 756027, which we were hoping to roll out today).

Thanks :-)

Comment 1

[Jason Crowe [:jd]]

Ed,

I updates stage to this point.  Please verify and I can push prod.  Also please note that stage is now in a detached head state and will not update normally until we rejoin the origin/master branch.  This will be true for prod if we attach it to a specific point.  Optionally we can change the push procedure to always use a tag, but that means you will always have to provide a tag.

Feel free to hit me up on IRC to coordinate prod push.

Comment 2

[Ed Morley [:emorley]]

Staging looks good.

Not sure what you mean about detached head state? Is this a git thing?

We just needed to update to the tip of master in this instance, if that helps clarify. I don't believe we've ever used tags for this repo.

Comment 3

[Ed Morley [:emorley]]

Oh and thank you! :-)

Comment 4

[Jason Crowe [:jd]]

Ed,

Okay, in that case I switched stage back to origin/master (AKA HEAD) and pushed an update (nothing changes).  This resolves the detached head state.

I pushed master to origin/master (HEAD).  Can you please verify things look good?

Also, in future if you just want to be a the tip of master, please forgo the git hash as that just confused me (well that and going on 25 hours without sleep probably does not help).

Let me know if I can help you any further :)

Comment 5

[Ed Morley [:emorley]]

(In reply to Jason Crowe [:jd] from comment #4)
> I pushed master to origin/master (HEAD).  Can you please verify things look
> good?

All looks good, thank you :-)

> Also, in future if you just want to be a the tip of master, please forgo the
> git hash as that just confused me (well that and going on 25 hours without
> sleep probably does not help).

Ah ok. When specifying mercurial changesets (eg for TBPL pushes to prod), I tend to give the exact changeset, since there is no guarantee someone won't have pushed another changeset to the repo, between me filing the "push to production" bug and the push being performed - and we'd otherwise end up with other changes being pushed prematurely. 

I take it if I wish to cover that scenario with Git pushes, I should say 
"master/tip as long as it's git hash <foo>, otherwise... <?????>"  ?

Comment 6

[Jason Crowe [:jd]]

Well we have a number of projects that we checkout a specific point (tag, hash, branch, etc) for this exact reason. The issue is that if the normal script is set up to just push tip or head or whatever you want to call it, then if I checkout an earlier point we end up in this detached head state so it is not possible to do a simple git fetch.  It is nothing more major than that, the real issue is that the scripts for this site are set up to do a simple fetch.

If you would like to move to a tag (hash, branch) procedure, that is fine just file a bug and we can switch over real quick.  IMHO this is a better approach but it is not our default as it seems a lot of folks find it to annoying to have to provide a tag or hash for each push.

Any way you want to do it that works for you and your team is fine with us, just let us know and we are happy to comply.

Comment 7

[Ed Morley [:emorley]]

Thank you for the explanation - we'll keep as is for now.

Cheers :-)