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" <[email protected]>: 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" <[email protected]> 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" <[email protected]>: On 3/23/20, 2:29 PM, "Christofer Dutz" <[email protected]> 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" <[email protected]>: 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" <[email protected]> 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" <[email protected]>: 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 (<[email protected]>) escribió: > > > On 3/23/20, 11:32 AM, "Christofer Dutz" <[email protected]> > 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
