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
9 years, 12 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
9 years, 12 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
10 years
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
10 years
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>
10 years
