Hi Alex, I finally said Chris to try it myself, so going with that now :) El mar., 24 mar. 2020 a las 15:40, Christofer Dutz (< christofer.d...@c-ware.de>) escribió:
> Hi Alex, > > I added a call to set a fixed timezone to the simpledateformat in the > SWCWriter ... could you please review this? > > Chris > > > > Am 24.03.20, 15:26 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>: > > Hi all, > > so today we made progress ... not only did we fix the version skipping > we observed yesterday. For this the commands done manually in the 001a step > had to be changed. > > Now we managed to get the compiler part reproducible, but not so much > the typedef part. > We are observing that the same timestamp is passed in to the build > when building the release on the ci server and when building the release > locally. However the timestamps have a strange constant offset 36 in two > digits of the timestamp in the catalog.xml > > 1585054125000 on the CI server > 1585057725000 locally > > I am assuming that perhaps there is time-zone information leaking into > the parsing of the date as we are using a date-format without time-zone > information. > > I would assume that Alex, perhaps you could have a look at what's > happening in the SWCWriter constructor, where the parsing of the timestamp > is implemented. > > Thanks, > > Chris > > > Am 24.03.20, 09:36 schrieb "Christofer Dutz" < > christofer.d...@c-ware.de>: > > Hi Alex, > > I had another look ... I think the version skips one is in step > 001a ... > There the job checks out develop, applies the update to the new > version of the build tools and jburg types, but then this is pushed and > then again to the release branch (hereby overwriting the old > release-branch) ... I'll try out a way with cherry picking the change from > develop into the release branch. Unfortunately I haven't been able to find > where the text in the emails comes from ... > > I'm talking about the order of the constants in the class > ProblemID. I forced that to be sorted now. That's why we have to re-release > the build tools. > > Chris > > Am 24.03.20, 08:14 schrieb "Alex Harui" <aha...@adobe.com.INVALID > >: > > Re: credentials: Feel free to disable the credential store. > I did not have to both login and go through 2fa to Git Push. There is > some long password/token/credential/hash-like thing you get when you sign > up with Apache Git that seems to work when you use it as a password. > > Re: the utils steps. I just looked and it appears that > compiler-jburg-types and compiler-build-tools are no longer > child/submodules of the root pom.xml in royale-compiler. So now I get how > why the development version won't get bumped up twice. I think the way it > was working may be that the updated dev version never got pushed to > develop. If you are satisfied with that setup, that's fine with me. So > then it might make more sense to get rid of 1a and create a whole new set > of steps for each of compiler-jburg-types and compiler-build-tools. If I > understand correctly, those new steps would run mvn release:branch, mvn > release:prepare and mvn release:perform in compiler-jburg-types or > compiler-build-tools, stopping if there are interim pushes that need to be > done, then start their own vote emails by copying other CI steps. > > I use a Mac and thought I got all binaries to match from the > . I'm not sure what properties you are referring to. > > I'm done for tonight. Will catch up in my morning. > > -Alex > > On 3/23/20, 11:15 PM, "Christofer Dutz" < > christofer.d...@c-ware.de> wrote: > > Good morning all, > > well I didn't disable anythig as I didn't want to break > anything. So I thought before simply changing something I'd ask first. > So I would consider it a "bug" that it's there and when we > continue today, we'll try to find out and disable the thing. > However I would assume then the RM will not only have to > do his usual login but also the 2fa thing at every step too, correct? > > And, just a kindly meant question ... would it be possible > to reply at the top instead of inline? I sort of have missed several > Of your Inline comments in the past as at least in my mail > client it's hard to spot what's mine and what's not. > (I could start counting spaces) > > (I first missed this question of yours ... but discovered > it after counting spaces ;-) ) > > Well to release the build tool with maven you would simply > do the: > mvn release:prepare > mvn release:perform > for each of them, then adjust the main pom and do the mvn > release:branch ... then prepare and perform after that. > > Currently also jburg types and the build-tools are sort of > released in parallel. With maven you would simply release only the module > that's needed to be released. In our case build-tools would have been > enough. > > Speaking of build-tools ... are you possibly using Windows > as OS on your system? Just asking because the build-tools seem to have > always generated a sorted set of properties on windows and an unsorted one > on Mac (Seems to be differences in the way the filesystem works) ... in > that case it would have been impossible to have a release manager not using > Java 8 on a Windows machine. (My changes recently never touched this) > > Chris > > > Am 23.03.20, 22:59 schrieb "Alex Harui" > <aha...@adobe.com.INVALID>: > > > > On 3/23/20, 2:29 PM, "Christofer Dutz" < > christofer.d...@c-ware.de> wrote: > > Hi Alex, > > sorry for the confusion ,... I meant the 1a ... > the one if you build the utils too. > > And regarding the credentials: Something must have > changes as I have never seen that gui thingy pop up before and as soon as > you login, it saves them in the password manager thingy of windows. > > Did you try to disable the password manager? > > It is true that I took those two out of the main > maven reactor, but that's actually a good practice. In plc4x we setup a > dedicated git repo for releasing these build tools. I have never seen any > good coming from the old setup (I know ... I did it, but I learnt a lot). > > I am not opposed to moving those two projects to a > different repo. It would require that we have a truly separate release > vote for them, so more work in that regard, and the Ant build would have to > be adjusted to download those jars. I'm not sure now is the time to make > that change, but maybe. Let's see what others think. > > Regarding the banches ... we did a git status > after step 001a (the utils step) and indeed it was done on develop. As the > maven release isn't doing any selecting and switching of branches it must > have always been this way. If not the utils release versions would only be > updated in the release branch and not develop. I couldn't find any cherry > picking of commits in the process. > > Well in the end the steps are way more complicated > than I would be doing on my local machine. Especially this tolling around > checking out branches and tagging and pushing is pretty complicated, in my > opinion. Especially as most the stuff is fully automated. > > The Maven Release plugin automatically pushes and > signs, so yes, the CI steps are more complicated because they have to > continue on, but if there is a better way to stop and continue, let us know > what that is. But I was mainly addressing the branch/version issue for > those two "utils" projects. What would be the correct set of Maven Release > commands to manage that locally without updating the develop version > twice? Or maybe as you mention above, there really is no good way and a > separate repo is essentially the only way. > > I think we managed to get the steps 1-4 (including > the utils stuff) working again, while keeping the cleanup I did a while > ago. > > I hope tomorrow it'll be simper to adjust the > typedefs and the framework part. > > One thing we did notice however that even after > addressing the memory issues, the build sometimes simply stuck and the > build wouldn't continue. > In these cases simply killing the job (and the > processes on the CI server) didn't really help much ... we then had to > reboot the machine in order to continue. I think we rebooted the thing 5-6 > times today. > > My experience was that the Jenkins slave would > occasionally disconnect and the job would fail right away. Rebooting > didn’t help. I didn't see it get stuck so unfortunately you are seeing > something new that I haven't seen. Did you search the internet to see if > anyone else reported something similar with Jenkins? > > Signing off for today, > > Chris > > > Am 23.03.20, 21:38 schrieb "Alex Harui" > <aha...@adobe.com.INVALID>: > > Re: credentials: Does that mean that the git > config is set to use the credential manager? If so, maybe that should be > turned off? When I did the release, I had to type my password many times. > Not sure what Piotr's experience was. > > Re: Branches: I don't remember what the > steps are. I didn't think there was a 1b, I don't see it in my emails, > just a 1a that did both compiler-jburg-types and compiler-build-tools. > Assuming 1a and 1b now reference these two projects, the thing to keep in > mind is that they are optional projects and so 1a (and probably 1b) won't > be run for every release. So, IMO, the branch should be made for the main > projects in royale-compiler. > > But if the changes you made effectively change > the way the poms are run (when there was a -utils profile for those two > projects, the main pom still got loaded and that may not be true now), then > the set of steps may need to test for existence of the branch or something > like that, not sure. > > In the end, the steps are just what you would > run on your local computer to fill the nexus staging repo, but broken into > discrete steps at each point Maven would normally push or sign. If you > haven’t, it might be worth just running Maven locally to fill a staging > repo with and without the jburg-types and build-tools projects to see how > to control when Maven makes branches and updates versions. Then come back > and break that down into steps on the CI server. > > HTH, > -Alex > > On 3/23/20, 12:30 PM, "Christofer Dutz" < > christofer.d...@c-ware.de> wrote: > > Another thing we just discovered. > > The current setup seems to mess up the > branches: > - 001 creates the branch and updates > develop rel = 0.9.7-SNAPSHOT, develop = 0.9.8-SNAPSHOT > - 001b updates DEVELOP and not the release > branch > - 002 pushes develop to the release-branch > hereby bumping the release branch to the next version rel = 0.9.8-SNAPSHOT, > develop = 0.9.8-SNAPSHOT > > If the 001b changes would have been done > in the release branch, develop would still be using the old version. > > So I would propose to change the order of > 001 and 001b to "release" the build tools before branching. > > And I would propose to fix 002 to work on > the right branch. As I could see in maven central you have been releasing > only even version number so I assume this problem exists for quite some > time now. > > Chris > > Am 23.03.20, 20:12 schrieb "Carlos Rovira" > <carlosrov...@apache.org>: > > Hi, > we just saw that windows stores a > personal access token in Windows > Crendetials, so the RM is responsible > to remove it when finish all the > operations. > > > El lun., 23 mar. 2020 a las 19:44, > Alex Harui (<aha...@adobe.com.invalid>) > escribió: > > > > > > > On 3/23/20, 11:32 AM, "Christofer > Dutz" <christofer.d...@c-ware.de> > > wrote: > > > > Hi Alex, > > > > I did check and I didn't > directly find any .git .ssh or whatsoever > > directories ... do you have an Idea > where that would be saved on windows? > > The commits are authorized by > Carlos and it's his RDP connection, > > that's why I'm asking if there is > any RDP magic going on. I didn't see him > > entering anything anywhere and he > said he didn't do it before. > > > > I don't know for sure, but here's a > few links: > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F46878457%2Fadding-git-credentials-on-windows&data=02%7C01%7Caharui%40adobe.com%7Cadba3ac479404cecf3a308d7cfbab263%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637206273081855711&sdata=CdxIgAjWiYoxXGFyPx4fXwXKaFvflCSjWPlmOCxl0Ew%3D&reserved=0 > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit-scm.com%2Fbook%2Fen%2Fv2%2FGit-Tools-Credential-Storage&data=02%7C01%7Caharui%40adobe.com%7Cadba3ac479404cecf3a308d7cfbab263%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637206273081855711&sdata=iHekeRaCHbjA0Jl7pRtNVHsVTX5dV2tWTFdtf7LpL94%3D&reserved=0 > > > > I'm wondering if Carlos can remember > if he did.anything like that back > > when he wrote this: > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread.html%2F8ae38cea0c736418b432b2353f967161c4f8448261a3bdce390e8c46%2540%253Cdev.royale.apache.org%253E&data=02%7C01%7Caharui%40adobe.com%7Cadba3ac479404cecf3a308d7cfbab263%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637206273081865700&sdata=7volq8njVi1oM0woTaFPOFsJ%2BNGpCQAz4iH5a9lA3Fs%3D&reserved=0 > > > > As I replied back then, we shouldn't > have GPG signing on the CI Server, > > and hopefully no other credentials > got added either. > > > > HTH, > > -Alex > > > > PS: I'm purposefully not looking > myself so as not to accidentally boot > > someone off the RDP connection. > > > > > > > > > > > > > > > > -- > Carlos Rovira > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cadba3ac479404cecf3a308d7cfbab263%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637206273081865700&sdata=kNz57NOLjbvDHEG5fyhWphM9uiI1f1EzdmaDKEvWhCw%3D&reserved=0 > > > > > > > > > > > > > > > > > > > -- Carlos Rovira http://about.me/carlosrovira
