[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ee4j-build] First working release job
|
Dne 04/10/18 v 23:32 Bill Shannon napsal(a):
There's so much magic in that script, I'm not sure what to do to adapt it
for my job.
For example, what do I do about this:
# Setup jaxb-impl-bot account information
git config --global user.email "jaxb-impl-bot@xxxxxxxxxxx"
git config --global user.name "Eclipse JAXBimpl Bot"
Does every project have an automatically created "bot" user?
I requested "bot" user for all metro/jersey/json projests to be able to
push branches and tags to github from release job.
Eclipse guys will create it when you need write access from Jenkins to
GitHub
There is no default git user config in docker image so we have to do
this setup manually.
And then for this:
echo '-[ Deploy artifacts to staging repository
]-------------------------------------'
mvn -U -C -s /home/jenkins/.m2/settings-jaxb-impl.xml \
-DskipTests -Ddoclint=none -Prelease \
clean package source:jar javadoc:jar gpg:sign install:install ${MVN_DEPLOY_ARGS}
First of all this maven call will probably differ a bit for different
projects. I do not expect that people will just copy-paste it. Someone
may also use release plugin instead of doing it manually like me.
You're using a "release" profile, but the parent pom has an "oss-release"
profile. Does that mean you had to duplicate all that configuration in
your pom? If you had renamed your profile to "oss-release" would it have
been simpler? Can Maven be told to use two profiles and "merge" them?
This is historical piece of metro project pom.xml - there was
"javanet-release" profile and I just simplified the name when adding
--pinentry-mode loopback into gpg config.
But you are right that we should use some common name based on parent
pom. I'll have to update all projects to reference new parent so I can
take care of all those non standard things too.
What's the difference between "install:install" and "install"?
Ditto "deploy:deploy"?
Aren't some of those Maven steps implied by install or deploy?
If this just deploys to a staging repository, how does it get pushed out
to the real repository?
Some of the metro projects could not be deployed and closed when using
simple maven lifecycle targets. For example some jars were packaged
again after being signed and this caused nexus deployment close to fail.
So I'm using this set of targets which seems to be working well almost
everywhere.
gpg:sign, install:install and deploy:deploy are targets related to
specific maven plugins
But real cause may be some pom.xml inconsistency. Unfortunately we don't
have time to fix such things now.
If the artifact I deploy is a SNAPSHOT release, do I need to change anything
in the above mvn command?
I think not. Even something like mvn clean build gpg:sign deploy can
work fine too.
Tomas
