Create account / Log in

Moving on with deployment and build handling

Discussion area for the development team.

Moderators: uckelman, Tim M

Moving on with deployment and build handling

Postby Flint1b » July 21st, 2020, 12:26 pm

I would very much like to get these things done, and we are very close to achieving them, there's just a little bit of work left, and they are all interconnected:

a) deploy the Vassal jar and also the source-jar and javadoc-jar as their own maven artifacts, there are several options where we could deploy it, we could even deploy them right there in the github repo and this would be enough for others (module designers) to use them as a dependency their pom.xml.
b) start using the maven clir plugin to test for API compatibility changes, for this we would need something to compare to, and the jar from a) would be the baseline. once this is established we would never again have to manually search for API compatibility changes in every PR, this would free up time for more important matters including all these Vassal NG plans
c) create a template maven project for module designers, this would also need a)

Right now all of this depends on a single step--making the jar it's own build artifact, and there is a PR that does just that: https://github.com/vassalengine/vassal/pull/57

It is a somewhat bigger change, not as big as the switch to maven but it could still mean that development environments need to be setup again. I keep this PR merge-able as almost every commit to master introduces conflicts, but it's somewhat tedious and since I don't know when/if this will be accepted at all I am not sure whether it's worth the trouble updating it every day.
User avatar
Flint1b
 
Posts: 461
Joined: May 19th, 2020, 12:27 am
Location: Colonia Agrippina

Re: Moving on with deployment and build handling

Postby uckelman » July 21st, 2020, 12:31 pm

Thus spake Flint1b:
> I would very much like to get these things done, and we are very close
> to achieving them, there's just a little bit of work left, and they are
> all interconnected:
>
> a) deploy the Vassal jar and also the source-jar and javadoc-jar as
> their own maven artifacts, there are several options where we could
> deploy it, we could even deploy them right there in the github repo and
> this would be enough for others (module designers) to use them as a
> dependency their pom.xml.

This would be a helpful thing for VASL, as they're using Maven, but
not using it for VASSAL and it's dependencies, so they have somewhat
of a mess because of it.

> Right now all of this depends on a single step--making the jar it's own
> build artifact, and there is a PR that does just that:
> https://github.com/vassalengine/vassal/pull/57[1]
>
> It is a somewhat bigger change, not as big as the switch to maven but it
> could still mean that development environments need to be setup again. I
> keep this PR merge-able as almost every commit to master introduces
> conflicts, but it's somewhat tedious and since I don't know when/if this
> will be accepted at all I am not sure whether it's worth the trouble
> updating it every day.

I haven't made it to trying this PR yet; it's been in line behind bug fixes.
If you resolve the conflicts, I'll look at it this evening.

--
J.
User avatar
uckelman
Site Admin
 
Posts: 8847
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Moving on with deployment and build handling

Postby Flint1b » July 21st, 2020, 1:00 pm

Just resolved them by rewriting history and force pushing, it is now a couple commits based on current master, should be much cleaner than these constant merges from master.

And yes it can help VASL right away, I have seen how they use maven but copy the Vassal jar and all its dependency jars into their code.

I've just yesterday realized we can deploy the jar ourselves inside GitHub, here is one project that does this, look at how easy it is to pull the dependency right from github: https://github.com/javaterminal/Termina ... dependency

We could deploy the released jars inside the main repo, or make a separate github repo for it under the vassalengine organization.
User avatar
Flint1b
 
Posts: 461
Joined: May 19th, 2020, 12:27 am
Location: Colonia Agrippina

Re: Moving on with deployment and build handling

Postby uckelman » July 21st, 2020, 6:12 pm

Thus spake Flint1b:
> Just resolved them by rewriting history and force pushing, it is now a
> couple commits based on current master, should be much cleaner than
> these constant merges from master.

Merged.

--
J.
User avatar
uckelman
Site Admin
 
Posts: 8847
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Moving on with deployment and build handling

Postby uckelman » July 21st, 2020, 6:14 pm

Lots of conflicts in PRs behind this one now, but I expect they'll be
mostly trivial to resolve.
--
J.
User avatar
uckelman
Site Admin
 
Posts: 8847
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Moving on with deployment and build handling

Postby Cattlesquat » July 21st, 2020, 6:19 pm

Even the ones I'd think would be simple say "too complex to resolve in the web thing".

So I guess I need the lesson in how to resolve them w/o the web thing. (what git commands, in other words)
User avatar
Cattlesquat
 
Posts: 890
Joined: December 2nd, 2019, 4:57 pm
Location: Baltimore, Maryland, USA

Re: Moving on with deployment and build handling

Postby uckelman » July 21st, 2020, 6:22 pm

Thus spake Cattlesquat:
> Even the ones I'd think would be simple say "too complex to resolve in
> the web thing".
>
> So I guess I need the lesson in how to resolve them w/o the web thing.
> (what git commands, in other words)

These won't be very hard to resolve, as they're not due to overlapping
edits. (I'm not sure why there are conflicts, to be honest, since these
are just due to moving files around.)

--
J.
User avatar
uckelman
Site Admin
 
Posts: 8847
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Moving on with deployment and build handling

Postby Cattlesquat » July 21st, 2020, 6:27 pm

Right. It just won't let me resolve them with the normal "resolve conflicts" button which is greyed out "because it's too complex". But if I check out the branch for one of them and then type "git mergetool" it says there are no files that need merging. So just confused.
User avatar
Cattlesquat
 
Posts: 890
Joined: December 2nd, 2019, 4:57 pm
Location: Baltimore, Maryland, USA

Re: Moving on with deployment and build handling

Postby uckelman » July 21st, 2020, 6:27 pm

Thus spake Cattlesquat:
> Even the ones I'd think would be simple say "too complex to resolve in
> the web thing".
>
> So I guess I need the lesson in how to resolve them w/o the web thing.
> (what git commands, in other words)

Try resolving conflicts on the selection toggle one first, as that's
the one I'd like to merge next.

--
J.
User avatar
uckelman
Site Admin
 
Posts: 8847
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Moving on with deployment and build handling

Postby Cattlesquat » July 21st, 2020, 6:34 pm

Yeah that's the one I started with because I thought it would be "easiest".

I tried a rebase on master command and now I'm in a world of hurt.
User avatar
Cattlesquat
 
Posts: 890
Joined: December 2nd, 2019, 4:57 pm
Location: Baltimore, Maryland, USA

Re: Moving on with deployment and build handling

Postby Cattlesquat » July 21st, 2020, 6:40 pm

Okay it was a total disaster I did "git rebase --abort" and will await professional help :)
User avatar
Cattlesquat
 
Posts: 890
Joined: December 2nd, 2019, 4:57 pm
Location: Baltimore, Maryland, USA

Re: Moving on with deployment and build handling

Postby Cattlesquat » July 21st, 2020, 6:56 pm

...oooooor maybe I must have typed something wrong the first time. Second time worked as if "duh nothing's even wrong".

If it passes its travis check it's ready to merge.

Any particular priority order for other PR's to hit and attempt not to destroy? I don't have a feel for your 3.3.3 plans / target schedule / etc, so I'm just assuming "at some point we're cramming this all in a beta"
User avatar
Cattlesquat
 
Posts: 890
Joined: December 2nd, 2019, 4:57 pm
Location: Baltimore, Maryland, USA

Re: Moving on with deployment and build handling

Postby Cattlesquat » July 21st, 2020, 7:02 pm

Whew, the "crown jewels" are safe -- I got HTMLChatter to rebase :D
User avatar
Cattlesquat
 
Posts: 890
Joined: December 2nd, 2019, 4:57 pm
Location: Baltimore, Maryland, USA

Re: Moving on with deployment and build handling

Postby uckelman » July 21st, 2020, 8:11 pm

Thus spake Cattlesquat:
> ...oooooor maybe I must have typed something wrong the first time.
> Second time worked as if "duh nothing's even wrong".
>
> If it passes its travis check it's ready to merge.
>
> Any particular priority order for other PR's to hit and attempt not to
> destroy? I don't have a feel for your 3.3.3 plans / target schedule /
> etc, so I'm just assuming "at some point we're cramming this all in a
> beta"

I'm tyring to work though the bug fixes first, though I'm also picking off
ones which are easy to review as I go.

The list of changes over 3.3.2 is getting to be rather long now; keeping
the releases smaller makes user reports of problems more useful, as it
narrows the range of chances which can be involved. So I'd like not to
include too much beyond what's already open in 3.3.3.

--
J.
User avatar
uckelman
Site Admin
 
Posts: 8847
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Moving on with deployment and build handling

Postby uckelman » July 21st, 2020, 8:22 pm

Thus spake Cattlesquat:
>
> I tried a rebase on master command and now I'm in a world of hurt.
>

There's more than one way one can get to a state where a conflicted PR can
be merged. Our experience so far makes me think GitHub doesn't handle one of
those ways very well.

The two ways:

1) Rebase your branch onto master.

2) Merge master into your branch.

Either of those should make your branch mergeable into master. A rebase can
be cleaner sometimes because that can mean the merge of your branch into
master is just a "fast-forward". (A FF is just a merge where HEAD in the
target is some number of commits behind HEAD in the source, in a straight
line.)

GitHub seems to be including as changes in a PR where you've rebased all
the commits which were involved in the rebase---which is totally wrong
and obscures what the actual changes were. The whole point of a rebase
in this case is to apply your changes in one shot directly over master,
so one would expect GH to see that those commits involved in the rebase
are already on master. (BitBucket works like this...)

I just tried updating my Windows LaF PR by merging master into it instead:

https://github.com/vassalengine/vassal/pull/64

Note that this is showing one file changed---the one file I actually
changed---instead of zillions of files.

So... I'm not sure what's going on here. I'm going to test a bit, because
the changed files display it has for PR 64 after I merged master into my PR
branch is how it should also look if I'd rebased. Either GitHub is being
stupid or Brian's doing it wrong---I just don't know which one yet.

--
J.
User avatar
uckelman
Site Admin
 
Posts: 8847
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Next

Return to Developers

Who is online

Users browsing this forum: No registered users and 2 guests