[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [birt-dev] Build Infrastructure
|
Hi Alexander,
I suggest to use GitHub Actions to validate PRs prior to the merge
and to use JIPP to produce signed consumable binaries (integration,
stable, releases). That means two distinct build processes, yes.
Since both of them will rely on Maven build the duplication will be
minimal.
I just submitted PR [1] that enables GitHub Actions for BIRT it was
triggered on the fork, but was not triggered for the eclipse/birt
repository, perhaps GitHub Actions needs to be activated in
repository settings.
Thank you for your review effort.
As for points you enumerated I believe they are all actual and I
would start from "make the tests pass" since it will give more
confidence for all the rest of changes.
So, it means to switch from "mvn package" to "mvn verify" and start
enabling tests. I suggest to start this after we will have GitHub
Actions checks active for eclipse/birt.
[1]
https://github.com/eclipse/birt/pull/586
Regards,
AF
04.03.2021 10:22, Alexander Lehmann
пишет:
Hi Scott,
You're right, a green build is not the end of
the flagpole (as we germans say 😄), but should be prio-1.
Currently the build fails because it runs on Java 11.
@Wim since you mentioned GitHub Actions: Did you suggest
running two distinct build processes, one on JIPP and one on
github? Shouldn't we stick to either?
I'm not that familiar with Eclipse plugin development, so
I might need to refine my ideas in the process (or someone
can correct me right away 😉), but these would be my
follow-up ideas to get to a more "mainstream" build process:
* bump tycho to the newest version
* move to a pom-less tycho build?
* use a target platform definition file with
tycho, which can be loaded into the IDE as well -> makes
IDE and maven build consistent
* replace all hard-linked libs (lib folders)
with their orbit-equivalents (we might need to put some libs
into orbit by ourselves)
* get rid of the ant scripts where possible
* make sense of the packaging scripts and
fix/replace them (the non-equinox package is broken since a
long time, hard-linked libs might be the main reason)
* make the tests pass
How to go on from here? I would open issues
for those points in github and create/reopen pull requests
which address them. Detailed discussion then in github?
Best regards
Alex
Alex,
Green builds would be great, but more than that my
hope is that the build makes sense to someone that is
familiar with other Eclipse projects.
My sense is that BIRT started a long time ago,
before many of the CI tools and version control
systems were in place. As the project has moved
forward, BIRT has picked up some of these features,
but in many cases the BIRT created workarounds rather
than embraced the new technology. So if what we do is
fix it to work in a non-standard way, that's a step,
but really we want to get rid of any idiosyncrasies
that are unique to BIRT.
So yes Green Builds from GitHub,
- but also easy to build locally
- follows best practices
- makes sense to someone new to the project
- easy to pick up and join the team
- easy uptake by people using the project (e.g. Maven)
I know that is not going to happen overnight, but I
am really encouraged by a bit of progress after almost
2 years of nothing.
On Wed, Mar 3, 2021 at
4:08 PM Alexander Lehmann <
a.lehm@xxxxxx>
wrote:
Hi,
So if I understood correctly, we're
going forward with the Eclipse CI infrastructure
[1] (it has the credentials needed to push to
download.eclipse.org)
and verify pull requests via GitHub Actions. I'll
look into it the next few days, opinions and
experience appreciated. Goal: a green build
triggered by GitHub 😃.
Best regards
Alex
_______________________________________________
birt-dev mailing list
birt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/birt-dev
--
Scott Rosenbaum
Innovent Solutions, Inc.
612 220
6006 cell
_______________________________________________
birt-dev mailing list
birt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/birt-dev
_______________________________________________
birt-dev mailing list
birt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/birt-dev