| clarkb | corvus: oh if we did then the config wasn't removed from static I guess? | 00:04 |
|---|---|---|
| corvus | yeah working on that now | 00:04 |
| opendevreview | Merged opendev/system-config master: Add tonyb to statusbot nicks https://review.opendev.org/c/opendev/system-config/+/900955 | 00:05 |
| opendevreview | James E. Blair proposed opendev/system-config master: Revert registry.zuul-ci.org https://review.opendev.org/c/opendev/system-config/+/900961 | 00:05 |
| opendevreview | James E. Blair proposed opendev/zone-zuul-ci.org master: Revert registry.zuul-ci.org https://review.opendev.org/c/opendev/zone-zuul-ci.org/+/900962 | 00:06 |
| corvus | clarkb: there's cleanup for that, sorry about that! | 00:06 |
| corvus | (i think the fact that the rewrite url points to "corvus" is a pretty good indicator as to the final status) | 00:07 |
| fungi | hah, excellent point | 00:20 |
| fungi | we'll presumably need to manually delete playbooks/roles/static/files/50-registry.zuul-ci.org.conf from the server, since just removing it from configuration management doesn't actually take it away, right? | 00:21 |
| clarkb | correct | 00:22 |
| fungi | er, i guess really /etc/apache2/sites-{available,enabled}/50-registry.zuul-ci.org.conf | 00:24 |
| opendevreview | Merged opendev/zone-zuul-ci.org master: Revert registry.zuul-ci.org https://review.opendev.org/c/opendev/zone-zuul-ci.org/+/900962 | 00:30 |
| opendevreview | Merged opendev/system-config master: Revert registry.zuul-ci.org https://review.opendev.org/c/opendev/system-config/+/900961 | 02:46 |
| *** benj_6 is now known as benj_ | 02:47 | |
| *** benj_5 is now known as benj_ | 02:53 | |
| opendevreview | Thierry Carrez proposed opendev/irc-meetings master: Move Large Scale SIG meetings one hour later https://review.opendev.org/c/opendev/irc-meetings/+/901004 | 08:31 |
| *** ykarel|away is now known as ykarel | 10:06 | |
| opendevreview | yatin proposed openstack/project-config master: [Neutron] Update Grafana Dashboard https://review.opendev.org/c/openstack/project-config/+/901010 | 10:48 |
| opendevreview | Merged opendev/irc-meetings master: Move Large Scale SIG meetings one hour later https://review.opendev.org/c/opendev/irc-meetings/+/901004 | 13:49 |
| *** d34dh0r5- is now known as d34dh0r53 | 15:00 | |
| opendevreview | Merged opendev/system-config master: Add letsencrypt_certs for mirror02.ord https://review.opendev.org/c/opendev/system-config/+/900953 | 15:02 |
| *** gthiemon1e is now known as gthiemonge | 15:55 | |
| fungi | infra-prod-letsencrypt succeeded after that ^ so we should be back in working order again | 16:05 |
| fungi | i'll go ahead and delete the old registry.zuul-ci.org apache config left behind on static.o.o in the wake of 900961 | 16:06 |
| fungi | done and reloaded apache on the server | 16:07 |
| frickler | do we have the "Move Change" API disabled in gerrit? should there be an UI option for it? I was thinking about the move to unmaintained/ and what should happen with open reviews on stable/(yoga in the current case) | 16:07 |
| fungi | i wasn't aware of its existence, but looks like https://review.opendev.org/Documentation/rest-api-changes.html#move-change documents it in the version we're currently running | 16:09 |
| fungi | i can't imagine we would have disabled it | 16:09 |
| frickler | but I do remember right, that in order to delete the stable/yoga branch in gerrit, all open reviews need to be abandoned or merged, right? | 16:10 |
| fungi | looks like it would need to be done by an account with abandon permission for the original change's branch | 16:10 |
| fungi | yes, open reviews would have to be closed (merged or abandoned, or possibly moved) before we can delete the stable branch | 16:11 |
| tonyb | fungi: Correct. | 16:11 |
| tonyb | ahem s/fungi/frickler/ | 16:11 |
| frickler | o.k., I'll discuss in #-tc first which way we want to handle this, then we can look into how to implement it | 16:12 |
| fungi | frickler: in light of that, i suppose the the process could be 1. eom tag stable branch, 2. create unmaintained branch from tag, 3. move open changes from stable to unmaintained, 4. delete stable branch | 16:12 |
| tonyb | I was kinda thikning we could add a tag to make them easy to find, and then abandon them | 16:12 |
| frickler | fungi: yes, that was my idea for if we do want to keep the reviews instead of abandoning | 16:13 |
| fungi | yes, i was previously assuming (because i didn't know about the move option) that we would 1. eom tag stable, 2. abandon open stable changes, 3. delete stable branch, 4. create unmaintained branch from eom tag | 16:13 |
| fungi | frickler: i agree it seems like a good idea | 16:14 |
| Clark[m] | Ya I don't think we have disabled that api | 16:15 |
| Clark[m] | It should work but I'm not sure we have ever tested it. Could add it to our gerrit testing in system-config though | 16:15 |
| fungi | i'm pretty certain we've never tested it, i think it must be a relatively new addition | 16:17 |
| fungi | or else we just somehow missed that it existed (it's not often we have need for that exact workflow anyway) | 16:17 |
| Clark[m] | It came with notedb iirc | 16:19 |
| frickler | according to https://stackoverflow.com/questions/59796736/how-do-you-move-a-gerrit-change-to-a-different-branch where I found this, it has been there for quite some time | 16:20 |
| fungi | the notedb transition is relatively "recent" to me | 16:21 |
| fungi | i mean it wasn't in the 2.x rest api | 16:21 |
| fungi | but looks like they added it in 2.13 | 16:22 |
| tonyb | oh so a similar timeframe to adding the delete branch api | 16:23 |
| tonyb | .... probably related | 16:23 |
| clarkb | tonyb: https://mirror02.ord.rax.opendev.org/ lgtm at first glance. I think we're ready to update the dns CNAMEs | 16:30 |
| tonyb | cool. I had a little look at it also. so yeah today I'll play DNS switcheroo | 16:34 |
| clarkb | infra-root https://opendev.org/opendev/system-config/src/branch/master/playbooks/roles/gerrit/tasks/main.yaml#L161-L177 this is where we currently write out the gerrit -> gitea replication key data on Gerrit. https://opendev.org/opendev/system-config/src/branch/master/playbooks/roles/gitea/tasks/main.yaml#L122-L158 this is where we configure the public key in gitea. And this is how | 16:53 |
| clarkb | the replication plugin documents configuring key selection: https://gerrit.googlesource.com/plugins/replication/+/refs/heads/master/src/main/resources/Documentation/config.md#file-3 | 16:53 |
| clarkb | given all that I think we can use a key type of our choosing then using the ssh config file to select the appropriate key. The tricky part (which was unexpected to me) is that our gitea management wants only one key at a time | 16:54 |
| clarkb | I suspect that we may need to refactor the gitea bit to be a little more flexible | 16:55 |
| clarkb | maybe track an old key and a new key and only cleanup keys that don't match either. And finally maybe treat a null oldkey as an indication to clean it up too | 16:56 |
| fungi | clarkb: does our gitea management remove old keys? if it's only additive (installing the key if it doesn't exist) then we could probably get by with that for a brief transition | 16:57 |
| clarkb | fungi: it removes keys that don't match the one key it wants in gitea | 16:57 |
| clarkb | or at least that seems to be the intention | 16:57 |
| fungi | ah, okay, so no dice | 16:57 |
| fungi | another possibility is that we take the hit to swap keys out and then rereplicate everything after | 16:58 |
| clarkb | I think we can refactor this without too much trouble | 16:59 |
| fungi | we were talking about needing to do a full replication at some point anyway, after observing missing branches and whatnot | 16:59 |
| clarkb | I think it is buggy as is as well | 17:00 |
| fungi | oh, fun | 17:00 |
| clarkb | it checks the number of keys if >0 it tries to delete old keys. But then it only adds new keys if key length is 0 and it doesn't refetch the key list after deletion | 17:00 |
| clarkb | so if we try to swap keys out as is we'll end up with no keys on the first pass then have to wait for the playbook to run again to create the new key | 17:00 |
| clarkb | Roughly I think our process is 1) fix/refactor gitea key management 2) decide on the keytype and size for the new key 3) add new key to gerrit 4) coordinate addition to gitea and config update in gerrit to use new key to swap over | 17:02 |
| clarkb | it doesn't look like Gerrit is currently using a .ssh/config file to set the key info so we're relying on defaults there | 17:02 |
| clarkb | so step 3 above would include that config file | 17:02 |
| tonyb | We aren't in a "rush" for this right? | 17:15 |
| fungi | right, probably won't merge it until a couple of weeks from now | 17:16 |
| tonyb | Okay. | 17:18 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Add ssh key rotation to gitea ssh key management https://review.opendev.org/c/opendev/system-config/+/901082 | 18:18 |
| clarkb | something like that maybe | 18:18 |
| clarkb | now to update the gitea 1.21 change to use the release | 18:18 |
| clarkb | https://github.com/go-gitea/gitea/pull/27757/commits <- I feel like this is why Gerrit's model is better | 18:45 |
| JasonF | There are configurations you can mash in github to make that not crap all over the overall git history (e.g. enforcing squash+merge or using CI/review to enforce sane commits) | 18:47 |
| *** JasonF is now known as JayF | 18:47 | |
| clarkb | the problem is the PR itself is indecipherable | 18:50 |
| clarkb | there are multiple commits saying it renames a file from foo to foo.sh but the end result of the PR is the file is not renamed | 18:50 |
| clarkb | whether or not that is in the git hiustory or recorded in a single commit's commit message its completely confusing and a mess | 18:50 |
| JayF | You can have (and I've seen) the same thing happen in gerrit as a change evolves and the update doesn't include the commit message | 18:54 |
| JayF | (as always with those things, it seems like you find them after they land, but I'm sure I've -1'd a couple for that kinda oversight before, too) | 18:55 |
| JayF | Regardless of tools, creating a good git history require concious effort on the part of everyone in the process. Although I do generally agree that github-style-workflows enable whatever pattern you want them to enable for the most part; even ones that you and I would consider bad patterns. Gerrit is more strongly opinionated. | 18:55 |
| opendevreview | Merged openstack/project-config master: [Neutron] Update Grafana Dashboard https://review.opendev.org/c/openstack/project-config/+/901010 | 18:56 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Update gitea to 1.21.0 https://review.opendev.org/c/opendev/system-config/+/897679 | 19:00 |
| clarkb | JayF: the difference with gerrit is you get the iterative history pretty well laid out in the change history | 19:00 |
| clarkb | so even if the commit itself was missed you'll generally have some indication of why the thing stopped getting renamed for example | 19:00 |
| clarkb | and yes it takes discipline. But Gerrit forces you to think about that with a commit per change model | 19:01 |
| clarkb | you can still get it wrong but you can't ignore it | 19:01 |
| clarkb | infra-root 897679 is updated for the gitea 1.21.0 release with changelog info accounted for. If that passes CI I'll rebase the force fail change on it and hold a node we can look at | 19:01 |
| fungi | thanks! | 19:03 |
| JayF | clarkb: heh, github used to actually have a nastier bug; if you force pushed, the commits used to just completely disappear along with the comments | 19:04 |
| JayF | clarkb: so you could essentially rebase out someone's comment and if they weren't being vigilant, pretty easy to miss | 19:04 |
| fungi | i thought that was intentional, and didn't realize github had stopped doing that (good on them for deciding the discussion was worth preserving after all) | 19:05 |
| JayF | I always viewed it as an unintended side effect | 19:05 |
| clarkb | I'm slightly worried the dockerfile refactor has some bug in my update to mimic upstream | 19:05 |
| clarkb | we should know soon enough | 19:05 |
| JayF | but I also force-push more than most github users because gerrit taught me how to git better than most other folks (<--- this is why even though I like gerrit personally; I think it's a barrier to entry; you have to know git better than you do to use git{hub,lab} style workflows) | 19:06 |
| fungi | it seems to me that, because those workflows force you to maintain separate forks, you actually have to know more about git | 19:07 |
| fungi | or, at worst, you need a grasp of different aspects of git | 19:08 |
| clarkb | I waffle on that my self. I think in our bubble that anyone writing python that is expected to safely, without data loss, manage virtual machines, networks, and storage can be expected to know git. People writing docs probably don't have similar backgrounds and expecting git of them is a bigger order. But also ya I'm not convinced github is inherently easier. I just think it is more | 19:08 |
| clarkb | familar | 19:08 |
| JayF | fungi: that's actually not true for everyone; many folks just give access to create branches on the base org and don't require forking | 19:08 |
| JayF | fungi: especially for single-company projects/oss teams (this is how it is setup for armada contributors, for instance, because armadaproject github org has faster CI runners) | 19:09 |
| clarkb | a lot of people also conflate github and git which makes it harder to break down the idea that you can use git outside of the github world | 19:09 |
| JayF | clarkb: do not forget about the extensive tooling and docs. There are GH cli/gui apps, and howtos for everything. | 19:09 |
| JayF | Yes and yes. | 19:09 |
| JayF | I don't like github the business model. I do think they provide a value to the community we've walled ourselves off from in a set of tradeoffs that I don't always love :) | 19:10 |
| clarkb | meanwhile I think I'm still one of the only few that actually tracks the github mirrors... | 19:12 |
| clarkb | there is a comment there against openstackclient I need to respond to | 19:12 |
| JayF | That is on my list to pick up this cycle; I just ended up with a large number of things on my plate :/ | 19:12 |
| JayF | and Eventlet sorta shoved itself into my life | 19:12 |
| JayF | realistically monitoring github will probably die at the altar of eventlet work | 19:12 |
| clarkb | https://github.com/openstack/openstacksdk/commit/d17b23f63109a1cac0c6d01ae9e278b6e83bcc02#commitcomment-132631626 fwiw. The issue is they are using python3.6 and need to install python3.8. I plan to respond as soon as I get signed back in | 19:12 |
| clarkb | JayF: the good thing about it is that it is interrupt driven. So I just try to read thigns like ^ if I have time and respond or forward as necessary | 19:13 |
| fungi | my whole existence is interrupt-driven. too bad my brain is single-threaded | 19:15 |
| JayF | I've been working over the last ... well really since taking this GR-OSS job at trying to flip from being interrupt-driven to project-oriented | 19:15 |
| JayF | with mild success | 19:15 |
| clarkb | this is interesting the docker file update seems to be failing beacuse it is running a copy instruction before the workdir and make complete so there is no data to copy | 19:24 |
| clarkb | oh interesting this is happenign beacuse it thinks the data is cached | 19:28 |
| clarkb | but it isn't becuase it is new?But why would it be cached if we are starting from scratch on a single use VM to build the image | 19:29 |
| fungi | maybe they only tested upgrades and not new installs? | 19:34 |
| clarkb | I think this is somethign to do with how we are building the images and this change upstream is just exposing it | 19:36 |
| clarkb | docker image builds take a --no-cache flag optionally | 19:36 |
| clarkb | but it doesn't make any sense to me that docker would be finding cached data here | 19:36 |
| clarkb | because it is a fresh node that we are running on | 19:37 |
| fungi | could it be getting called more than once in the job? | 19:37 |
| clarkb | I don't think so. I'm wondering if it is somehow finding old builds in the intermediate registry. Howver this is the build image in our multi stage builds and we don't push those anywhere iirc | 19:39 |
| clarkb | it should be almost impossible to cache that without running docker image builds twicei n the same env | 19:39 |
| clarkb | I'm going to revert those changes to the image I guess and see if it still explodes | 19:41 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Update gitea to 1.21.0 https://review.opendev.org/c/opendev/system-config/+/897679 | 19:45 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Add ssh key rotation to gitea ssh key management https://review.opendev.org/c/opendev/system-config/+/901082 | 19:46 |
| clarkb | here is where it says a bunch of stuff is cached then it gets to the step wheer I modified things and it fails to copy properly https://zuul.opendev.org/t/openstack/build/382d990a92ba447f99a3b008777f5355/log/job-output.txt#781-797 | 19:47 |
| clarkb | corvus: ^ you don't know off the top of your head why that would be happenign do you? It seems like nothing at all should be cached in those image builds | 19:48 |
| clarkb | I can reproduce the problem locally and adding --no-cache does not help | 19:54 |
| fungi | did someone accidentally check in cache files? | 19:55 |
| clarkb | I think maybe this is part of build setup and because we use RUN git clone ... to create the directory that COPY copies it doesn't know about that directory | 19:56 |
| clarkb | we need to use ADD | 19:56 |
| clarkb | I'm working on testing this | 19:56 |
| fungi | one thing that's come up with mm3 feature parity is that there's no place in postorius to set the footer boilerplate text for each list like you could in mm2 | 20:03 |
| fungi | instead you have to create a text file in /var/lib/mailman/core/var/templates/lists/$LIST_ID/$LANG/list:member:regular:footer.txt | 20:04 |
| fungi | we currently have 5 on lists01: openstack-discuss.lists.openstack.org, starlingx-discuss.lists.starlingx.io, zuul-announce.lists.zuul-ci.org, zuul-discuss.lists.zuul-ci.org, service-discuss.lists.opendev.org | 20:05 |
| fungi | i suppose we could stick those files in git and then have ansible install them to the server | 20:07 |
| fungi | but all 5 are empty files, specifically overriding the default footer with nothing in order to make mailman not add a footer to messages | 20:07 |
| fungi | so another option might be to add a config flag for whether we want ansible to create an empty file there | 20:08 |
| fungi | opinions? | 20:08 |
| clarkb | the existing ones were pulled in via the migration but now end users can't create them via the web ui? | 20:09 |
| fungi | correct. well, 4 of those were created on import from mm2 data, the starlingx one i added manually yesterday | 20:09 |
| ildikov | Hi Team, I have a weird question. I'm trying to "find" the edge-computing ML on the mailman GUI to check on the moderation queue, etc. I think it's on the openinfra.dev domain now, but it doesn't get listed on the web GUI. Can someone help me figuring out what I'm doing wrong? | 20:10 |
| fungi | ildikov: lists.opendev.org for that one. if you're logged in, by default the https://lists.opendev.org/ page will default to an owner+moderator+member filter. try clicking "all" | 20:14 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Update gitea to 1.21.0 https://review.opendev.org/c/opendev/system-config/+/897679 | 20:14 |
| clarkb | I think ^ is a compromise between what upstream is doing and what we are doing | 20:15 |
| fungi | ildikov: if you have a message from the list, you can always double-check the domain part of its e-mail address, that will also be the server name for the management interface and archives | 20:15 |
| fungi | i need to step away to drop christine at an appointment, but will be back in 10 minutes | 20:15 |
| clarkb | fungi: if we set no footer file is that not equivalent to setting an empty one? | 20:15 |
| clarkb | I'm wondering if we can just avoid setting it entirely. If not then I think a per list config option in the ansible vars for the lists to copy in an empty file is how I would do it | 20:16 |
| ildikov | fungi: the to address that I used was openstack.org, but I couldn't find the edge-computing ML listed there either | 20:22 |
| clarkb | ildikov: the adress you email is edge-computing@lists.openstack.org ? I don't think that shoudl work | 20:25 |
| ildikov | clarkb: I'm trying to access the moderator dashboard of the list | 20:28 |
| ildikov | I can send emails to it | 20:28 |
| fungi | ildikov: oh, that's an old address we have forwarding to edge-computing@lists.opendev.org | 20:28 |
| ildikov | fungi: right, that's what I thought | 20:28 |
| ildikov | oh, ok, never mind | 20:28 |
| ildikov | I mixed up opendev with openinfra | 20:29 |
| ildikov | I wish we had more distinctive names :) | 20:29 |
| fungi | yeah, since the edge-computing wg isn't directly a function of the openinfra foundation, it went on opendev (like the openinfralabs ml) | 20:29 |
| ildikov | my bad, I knew it was something stupid like this, but couldn't figure it out | 20:30 |
| fungi | and i agree, openinfra.dev and opendev.org are very similar names, i mistype one for the other all the time | 20:30 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Add ssh key rotation to gitea ssh key management https://review.opendev.org/c/opendev/system-config/+/901082 | 20:30 |
| clarkb | fwiw we do have distinct names we just setup a redirect to make them more confusing | 20:30 |
| ildikov | fungi: I understand the reason, just my brain failed to process today that there is an opendev.org domain for MLs too | 20:31 |
| clarkb | I feel like this wouldn't be an issue if we didn't have the redirect | 20:31 |
| fungi | clarkb: which redirect? | 20:31 |
| clarkb | rather than openinfra.dev and opendev.org being similarish | 20:31 |
| clarkb | fungi: 'oh, that's an old address we have forwarding to edge-computing@lists.opendev.org' | 20:31 |
| fungi | that was forwarding from an old edge-computing@lists.openSTACK.org address | 20:32 |
| clarkb | yes and ildikov checked lists.openstack.org | 20:32 |
| clarkb | because the address ildikov uses is edge-computing@lists.openstack.org | 20:32 |
| fungi | yet a third very-similar domain in that case | 20:32 |
| clarkb | I'm saying if the address people use is edge-computing@lists.opendev.org only then all the ambiguity goes away | 20:32 |
| clarkb | but we've created a forward that adds ambiguity and makes it unclear | 20:33 |
| fungi | yeah, the main reason we added address forwarding was because people may reply to an older message and we wanted them to not just get a confusing ndr bounced back | 20:33 |
| fungi | but maybe we want to alter our policy for that and instead have exim reject those addresses with explicit error messages that say what the new posting address is | 20:34 |
| fungi | fwiw, i still see posts all the time to the old openstack-dev address | 20:34 |
| ildikov | yeah, I would not get rid of the forwarding | 20:46 |
| ildikov | I'm just one of those lazy people who go with the autocomplete in her mail client... and that's in me to fix that :) | 20:47 |
| fungi | clarkb: wrt the templates, there is a default template that gets used, but lists can substitute their own specific template instead. the substitution only occurs if a list-specific template file exists. for the majority of lists, there is no directory under /var/lib/mailman/core/var/templates/lists and so they use the default template instead | 20:59 |
| fungi | only if a list wants to replace the default template (e.g. with empty content so that no footer gets added) will there be a file for them | 21:00 |
| opendevreview | Julia Kreger proposed openstack/diskimage-builder master: Drop py36 support https://review.opendev.org/c/openstack/diskimage-builder/+/901093 | 21:14 |
| clarkb | fungi: and there is no way to set that template via the ui so we need to manage it out of band for people | 21:14 |
| clarkb | in that case ya I would make it a list attribute in our list of attriutes and have ansibel write the file out | 21:15 |
| fungi | right. in the case of starlingx i did a `mkdir -p ... && touch ... && chown -R x:y ...` | 21:15 |
| fungi | oh, good point, we could make it an ansible string, defaulting to empty | 21:16 |
| clarkb | yup | 21:16 |
| fungi | then if someone does want a non-empty but non-mm3-default template, they could put the string in | 21:16 |
| fungi | i'll ponder how to go about that. unlike the values we set for lists in inventory currently, this is one that is likely for people to want to apply after list creation | 21:17 |
| fungi | the commit message on 897679 is epic now, but it's passing!\ | 22:15 |
| Clark[m] | Ya I'll work out a node hold after this school run | 22:17 |
| tonyb | [tony@thor system-config]$ git show HEAD --no-patch | wc -l | 22:17 |
| tonyb | 82 | 22:17 |
| tonyb | [tony@thor system-config]$ git diff HEAD^ | wc -l | 22:17 |
| tonyb | 647 | 22:17 |
| tonyb | That's a pretty good ratio ;P | 22:17 |
| opendevreview | Clark Boylan proposed opendev/system-config master: DNM intentional gitea failure to hold a node https://review.opendev.org/c/opendev/system-config/+/848181 | 23:09 |
| clarkb | I've put an autohold in place for ^ | 23:10 |
| tonyb | ++ | 23:10 |
| JayF | clarkb: I can't find where you were talking about it; are you still digging that gitea dockerfile thing? | 23:11 |
| JayF | clarkb: I had some brain cells fire and had an idea | 23:11 |
| JayF | clarkb: tl;dr basically curious if the build works if env DOCKER_BUILDKIT=0 is set | 23:11 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Add ssh key rotation to gitea ssh key management https://review.opendev.org/c/opendev/system-config/+/901082 | 23:13 |
| clarkb | JayF: it broken with and without buildkit locally. I'm not sure which way its set in the CI. But I think the problem is COPY wants to operate on files it knows about and it doesn't know about these files because they exist due to side effects of RUN commands | 23:13 |
| clarkb | JayF: supposedly you can use ADD to work around that, but I couldn;t make that work with git either (because the flag to include the .git dir wasn't working). I ended up just not bothing with the COPY and modify files in place intead | 23:14 |
| clarkb | infra-root I think 901082 should be ready for review now. That should make itpossible for us to manage to pubkeys for gerrit in gitea | 23:14 |
| clarkb | then we can generate a new key, add it to gitea and gerrit then flip gerrit over to it | 23:14 |
| JayF | clarkb: ack, this is usually where I'd say 'makes sense', but it really doesn't, and this is a place where it seems like Dockerfiles have just gotten worse and not better as they have matured :( | 23:15 |
| JayF | but glad to hear you figured it out | 23:15 |
| clarkb | ya it feels a bit overoptimized honestly | 23:16 |
| clarkb | like ya caching is great but if it means you can't run a RUN command and then COPY the results of that later maybe we've gone too far | 23:16 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!