Merge PRs from GitHub UI
by Fred Bricon
Hi,
In April, GitHub introduced squashed merging[1] to their web UI. It's now
OK to use the big green "merge" button for PRs in Github for openshift, as
commits in a PR will be squashed commits and put at the tip of the branch. It's
not as nice as having rebase support but that's better than before.
It works beautifully for >90% of the PRs (from my very unscientific
estimations). However there are cases where you shouldn't use that button:
- when there are merge conflicts (but the UI won't let you anyway)
- if you really intend on keeping distinct commits in the PR. This is
especially important when the PR contains commits from different authors.
*Everything* will be squashed, only one author will remain.
But there are 2 added benefits of using the merge button: it marks the PR
as merged, not closed (also shown in JIRA), and it adds the PR # in the
commit message, so it's easy to link back to the original PR.
So I went ahead and disabled merge commits for all (I think) jbosstools
repositories on GitHub, to make it easier to merge PRs (and prevent
accidental merge commits). If anyone wants me to undo that change for
specific repos, please lemme know.
Fred
[1] https://github.com/blog/2141-squash-your-commits
8 years, 7 months
Can we have a jenkins build triggered upon github PR?
by André Dietisheim
Hi
I'd love to get a build triggered when I create a PR in github. That
would allow me to force awareness of breaking tests with a change.
When talking to Nick he was pointing out that there are actually 3 items
that he's after currently, where my suggestion is the 1st of these aims.
a) does the PR break my tests / want a green light on the PR page
b) does the PR break downstream (eg., API change in Base breaks Server
or UI change in Server breaks Openshift)
c) does the PR need to be aggregated into JBT or JBDS so we can see it
in the larger context
a) is what I'd love to get and is good enough for me now.
b) is imho a nice-to-have but wasnt that much of a problem in OpenShift
lately.
c) I guess is the larger picture where we want to achieve continous
delivery.
Nick wants to know about the need of other component leads. So please
speak up. a), b), c), all of them, etc?
Cheers
Andre
8 years, 7 months
FYI :: Alpha1 released in JIRA, all issues moved to Alpha2
by Nick Boldt
Since Sprint 113 is done, and Alpha1 bits are staged for QE, I've
released the 4.4.0.Alpha1 and 10.0.0.Alpha1 fixversions in JIRA, and
moved all existing issues to Alpha2.
This should resolve a lot of jiralint's complaints about issues
targetting a codefrozen/released version.
Onward to Sprint 114 / Alpha2!
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
8 years, 7 months
Vagrant tooling in JBoss Tools 4.4 ?
by Xavier Coulon
Hello,
So far, we've included the Docker tooling from the Linux Tools project (http://eclipse.org/linuxtools), but this project also provides with tooling for Vagrant.
The Vagrant tooling comes with 2 views which list boxes and virtual machines. The "Vagrant Boxes" view has a toolbar to create/add/remove boxes, and the "Vagrant VMs" view's toolbar lets the user stop/start/destroy and SSH into the VMs.
Also, all those commands are exposed as an API, so they can be invoked by third-party plugins.
As far as OpenShift and CDK tooling are concerned, would it make sense to include the Vagrant tooling in JBoss Tools TP ?
I'm thinking about the CDK Server Adapter in particular.
Best regards,
Xavier
8 years, 7 months
m2e and new execution plugins?
by Brian Fitzpatrick
Hey guys,
We've hit some maven plug-ins that aren't supported yet by m2e that we use
in the Fuse world... if I was to log a feature request for some of these,
should I put it in Eclipse? or in JBIDE?
Or a better question, what is the policy for additions to m2e? How do we
petition to have plug-ins added or contribute back? These may not be
broadly applicable to other projects, so less apt to be pushed upstream.
Thanks in advance.
--Fitz
p.s. For a bit more detail about what we're looking for...
Importing the camel-cxf example (
https://github.com/jboss-fuse/quickstarts/tree/master/cxf/rest) we hit
three issues.
We have an org.apache.cxf plug-ins that isn't supported yet...
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-java2wadl-plugin</artifactId>
<version>3.0.4.redhat-621084</version>
<executions>
<execution>
<id>parsejavadoc</id>
<phase>generate-sources</phase>
<goals>
<goal>parsejavadoc</goal>
</goals>
</execution>
<execution>
<id>process-classes</id>
<phase>process-classes</phase>
<goals>
<goal>java2wadl</goal>
</goals>
<configuration>
<classResourceNames>
<classResourceName>io.fabric8.quickstarts.rest.CustomerService</classResourceName>
</classResourceNames>
<docProvider>org.apache.cxf.maven_plugin.javatowadl.ResourceMapJavaDocProvider</docProvider>
<attachWadl>false</attachWadl>
</configuration>
</execution>
</executions>
</plugin>
And a fabric8 plug-in that isn't supported yet.
<plugin>
<groupId>io.fabric8</groupId>
<artifactId>fabric-cxf-plugins</artifactId>
<version>1.2.0.redhat-621084</version>
<executions>
<execution>
<id>process-classes</id>
<phase>process-classes</phase>
<goals>
<goal>java2swagger</goal>
</goals>
<configuration>
<classResourceNames>
<classResourceName>io.fabric8.quickstarts.rest.CustomerService</classResourceName>
</classResourceNames>
<attachSwagger>false</attachSwagger>
</configuration>
</execution>
</executions>
</plugin>
8 years, 7 months
Known issues w/ JBT 4.4.0.Alpha1 & DS 10.0.0.Alpha1 bits staged for QE
by Nick Boldt
Before people report these issues, I wanted to mention I'm aware of
them. Thankfully, this is just a first Alpha build, so there's lots of
time to fix these publishing issues.
* Cannot install all of DS Central into DS 10.0.0.Alpha1 on Neon.0.M6
(BYOE), as Central includes an older version of o.e.mylyn, 3.18 but
3.19 is already installed https://issues.jboss.org/browse/JBIDE-22279
[will be fixed by moving up to Neon.0.M7 next week, JBIDE-22200]
* Wrong JBT IS site is used in JBT 4.4.0.Alpha1
https://issues.jboss.org/browse/JBIDE-22280
* JBT 4.4.0.Alpha1 loads too many update sites (for EA and JBT IS)
https://issues.jboss.org/browse/JBIDE-22281
* Publishing of JBDS Central & EA zips is broken
https://issues.jboss.org/browse/JBIDE-22282
So for now, JBTIS content can't be installed into JBT 4.4.0.Alpha1,
but that's OK because anything we'd be installing is the Mars-based
stuff, not the Neon-based stuff. And there are no JBDS Central/EA zips
for offline installation. Unsure if anyone actually ever uses those.
The Mylyn issue is just an annoyance because it slows down installing
from Central as Eclipse figures out you have a newer version of Mylyn
installed and works around it.
Cheers,
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
8 years, 7 months
