Change Details

> 11:36 <@jgirault> Hi there > 11:38 <@jgirault> Yesterday I wanted to update beta portals http://www.wikipedia.beta.wmflabs.org/, so did I (git pull in portals folder, and then sync-dir portals), and the page was up. Today the old page is back though. > 11:39 <@jgirault> not sure what caused it, but portals is a submodule, and I’m thinking maybe a `git submodule update` reverted my stuff > 11:40 <@jgirault> how should I do, to make sure what I deploy to portals beta stays in beta? > 11:53 <@thcipriani> jgirault: lemme look at how beta updates portals, it's likely it's an automated deploy > 11:55 <@jgirault> thcipriani: so far it is manual, but we want to automate it eventually https://phabricator.wikimedia.org/T124848 > 11:57 <@thcipriani> jgirault: ah, I see. I'll bet you're right that beta-mediawiki-config-update overwrote the change...looking at that job now > 11:59 <@thcipriani> yeah, I think that is what did it: https://github.com/wikimedia/operations-puppet/blob/production/modules/beta/templates/wmf-beta-mwconfig-update.erb > 12:00 <@jgirault> thcipriani: yeah, looks like it. what do you recommend? > 12:05 <@thcipriani> jgirault: that's tough. It seems like this is a little at odds with automated deployment of mediawiki config submodules > **12:05 <@thcipriani> I think this patch is what caused the current behavior: https://github.com/wikimedia/operations-puppet/commit/f4baf22e8622c40fed66c49ab38372ddb9af2a13 ** > **12:06 <@thcipriani> what we could do is just change it to a submodule update --rebase** > 12:10 <@jgirault> thcipriani: ok I see.. do you see any issue? I don’t want portals to mess everything else > **12:14 <@thcipriani> jgirault: submodule update --rebase shouldn't cause too much of an issue (pretty sure it's the default behavior for core extensions). Does that solve your issue though? you have changes on top of the current commit pointed to by the submodule that you'd like to persist?** > **12:18 <@jgirault> thcipriani: yes. the submodule points to master in production. and we’d like to run git pull to test new commits on beta before we update the references and deploy to production** > 12:20 <@thcipriani> jgirault: kk, I think that should work fine for others as well. Mind creating a ticket? I can add a pull request and get a few more folks to check my thinking.

> 11:36 <@jgirault> Hi there > **11:38 <@jgirault> Yesterday I wanted to update beta portals http://www.wikipedia.beta.wmflabs.org/, so did I (git pull in portals folder, and then sync-dir portals), and the page was up. Today the old page is back though.** > **11:39 <@jgirault> not sure what caused it, but portals is a submodule, and I’m thinking maybe a `git submodule update` reverted my stuff** > 11:40 <@jgirault> how should I do, to make sure what I deploy to portals beta stays in beta? > 11:53 <@thcipriani> jgirault: lemme look at how beta updates portals, it's likely it's an automated deploy > 11:55 <@jgirault> thcipriani: so far it is manual, but we want to automate it eventually https://phabricator.wikimedia.org/T124848 > 11:57 <@thcipriani> jgirault: ah, I see. I'll bet you're right that beta-mediawiki-config-update overwrote the change...looking at that job now > 11:59 <@thcipriani> yeah, I think that is what did it: https://github.com/wikimedia/operations-puppet/blob/production/modules/beta/templates/wmf-beta-mwconfig-update.erb > 12:00 <@jgirault> thcipriani: yeah, looks like it. what do you recommend? > 12:05 <@thcipriani> jgirault: that's tough. It seems like this is a little at odds with automated deployment of mediawiki config submodules > **12:05 <@thcipriani> I think this patch is what caused the current behavior: https://github.com/wikimedia/operations-puppet/commit/f4baf22e8622c40fed66c49ab38372ddb9af2a13 ** > **12:06 <@thcipriani> what we could do is just change it to a submodule update --rebase** > 12:10 <@jgirault> thcipriani: ok I see.. do you see any issue? I don’t want portals to mess everything else > **12:14 <@thcipriani> jgirault: submodule update --rebase shouldn't cause too much of an issue (pretty sure it's the default behavior for core extensions). Does that solve your issue though? you have changes on top of the current commit pointed to by the submodule that you'd like to persist?** > **12:18 <@jgirault> thcipriani: yes. the submodule points to master in production. and we’d like to run git pull to test new commits on beta before we update the references and deploy to production** > 12:20 <@thcipriani> jgirault: kk, I think that should work fine for others as well. Mind creating a ticket? I can add a pull request and get a few more folks to check my thinking.

> 11:36 <@jgirault> Hi there > **11:38 <@jgirault> Yesterday I wanted to update beta portals http://www.wikipedia.beta.wmflabs.org/, so did I (git pull in portals folder, and then sync-dir portals), and the page was up. Today the old page is back though.** > **11:39 <@jgirault> not sure what caused it, but portals is a submodule, and I’m thinking maybe a `git submodule update` reverted my stuff** > 11:40 <@jgirault> how should I do, to make sure what I deploy to portals beta stays in beta? > 11:53 <@thcipriani> jgirault: lemme look at how beta updates portals, it's likely it's an automated deploy > 11:55 <@jgirault> thcipriani: so far it is manual, but we want to automate it eventually https://phabricator.wikimedia.org/T124848 > 11:57 <@thcipriani> jgirault: ah, I see. I'll bet you're right that beta-mediawiki-config-update overwrote the change...looking at that job now > 11:59 <@thcipriani> yeah, I think that is what did it: https://github.com/wikimedia/operations-puppet/blob/production/modules/beta/templates/wmf-beta-mwconfig-update.erb > 12:00 <@jgirault> thcipriani: yeah, looks like it. what do you recommend? > 12:05 <@thcipriani> jgirault: that's tough. It seems like this is a little at odds with automated deployment of mediawiki config submodules > **12:05 <@thcipriani> I think this patch is what caused the current behavior: https://github.com/wikimedia/operations-puppet/commit/f4baf22e8622c40fed66c49ab38372ddb9af2a13 ** > **12:06 <@thcipriani> what we could do is just change it to a submodule update --rebase** > 12:10 <@jgirault> thcipriani: ok I see.. do you see any issue? I don’t want portals to mess everything else > **12:14 <@thcipriani> jgirault: submodule update --rebase shouldn't cause too much of an issue (pretty sure it's the default behavior for core extensions). Does that solve your issue though? you have changes on top of the current commit pointed to by the submodule that you'd like to persist?** > **12:18 <@jgirault> thcipriani: yes. the submodule points to master in production. and we’d like to run git pull to test new commits on beta before we update the references and deploy to production** > 12:20 <@thcipriani> jgirault: kk, I think that should work fine for others as well. Mind creating a ticket? I can add a pull request and get a few more folks to check my thinking.