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%7C1ec483b299574ebfce4608d7cf7148f2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637205957773900779&sdata=HqpX0JqjqDj%2BwoCWc3VMLHf81Cwto7VjJesy3HRG4Uw%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%7C1ec483b299574ebfce4608d7cf7148f2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637205957773900779&sdata=dbX5nKxmAFpan7XU%2BNqPIGfjq5KweF08A02Do0cbc2Y%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%7C1ec483b299574ebfce4608d7cf7148f2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637205957773900779&sdata=WPYeHQJeZ%2B2jrkXltjfI86SUmUMpnWRiREVgMKmBvV0%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%7C1ec483b299574ebfce4608d7cf7148f2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637205957773900779&sdata=ahZXyjAHwir0x7h8HzcikuDeYlacC6acVKxLOFwJe6c%3D&reserved=0
