qbicsoftware / cookiecutter-templates-cli Goto Github PK

After having the real need to release some libraries (deadline is nigh), I feel that we still don't have an automatic way to handle releases. For now, I will do it manually via command-line. We are also "releasing" binaries in our Maven repositories, so it isn't that bad.

But instead of writing a long tutorial on how to do releases, I might as well automate it and document the code (that, in the end, will be just an implementation of our standard operating procedures).

It would be nice to apply the following rules to push events done on the master branch:

• All builds will be treated as release candidates.
• Artifacts will be deployed to our Maven releases repository (this has been implemented already).
• If deploying to Maven worked, Travis will create a .tar.gz archive containing all the .jar and .war files generated during the build. Deployments to maven would fail if the tests fail, if the code doesn't compile, if there is a release with the same version already deployed, etc., so we know that once Maven gives us the "OK", we're good to go and this will be treated as a release.
• Travis will somehow create and push a git tag by reading the version from the pom.xml file (there's a Maven command to print the value of a property, like mvn eval:property ${project.version}).
• Travis will use GitHub's API to create a GitHub release.
• Travis will use GitHub's API to upload the generated zip file as an asset of the generated GitHub release.

All this release-specific code should be packed in a separate script.

In the future, when we actually are able to ask for release notes and documentation, we can update this rules to simply include additional files in the archive that will be uploaded as an asset. Implementation of this updates would mean to edit one script across all repositories (so maybe this could be automated).

The bot created this issue to inform you that pyup.io has been set up on this repo.
Once you have closed it, the bot will open pull requests for updates as soon as they are available.

It's nice to see some sample code already working, but whenever one needs to create a new project or migrate an existent one, it would be nice to have a barebone application which developers could immediately use to work. Sample code gets in the way.

Perhaps generation of sample applications should be an extra command, such as:

$ ./generate.py --type cli --generate-sample

Developers might waste a few hours trying to figure out which Python version they need and how to get pip to nicely cooperate.

It would be nice if version 1.0.0 is offered not only as a normal GitHub release, but also as a conda package in the Anaconda cloud or somewhere easy to find.

After doing this, instructions will look like:

Installation

1. Download and install conda.

This tool is offered as a conda package named cookiecutter-templates-cli in the qbicsoftware channel. You can use the latest release or the development version.

See: https://docs.travis-ci.com/user/deployment/releases/

Update the developer.properties.example file to reflect all possible configuration variables.

A new command line parameter, i.e., -v/--version should be added to display the version. Now that we have made the first release, having identifiable versions will help us a lot for future releases/patches.

It is possible to define variables on Travis CI without editing .travis.yml. A useful feature to troubleshoot erroring builds would would be to be able to rerun a build in "debug mode" without having to edit any files.

It would be nice to have the project generator to ask if you would like to add the vaadin-charts dependency in your portlet's pom.xml

<!-- Vaadin charts -->
<dependency>
  <groupId>com.vaadin.addon</groupId>
  <artifactId>vaadin-charts</artifactId>
</dependency>

Same as CLI, but with a window I guess.

(qbicsoftware/parent-poms#3)

Our builds already generate javadocs and some documentation via some maven plugins and the site phase.

It would be nice to publish these reports somewhere, like our Wiki, GitHub pages, readthedocs.io, etc.

Of course, we don't have to publish reports to all of these places, we just have to choose one.

Related links

https://www.sonarqube.org/
https://pages.github.com/
https://readthedocs.io/

We have been experimenting with several things in Travis. It's time to apply that knowledge.

I just started a new cli project and it was kind of a clumsy experience. The following improvements should be implemented to improve the user experience:

I did a few new projects and I was annoyed at the fact that I had to re-enter my email address every single time.

Add a configuration file where one can always overwrite variables whose names and values are very unlikely to change over time, such as name, email, license holder, etc. As usual, command-line given arguments via the extra_context should always take precedence.

Or, alternatively, find a way to interact with this file: http://cookiecutter.readthedocs.io/en/latest/advanced/user_config.html

The CLI section could need a few improvements.

The class name given in main_class should always be suffixed EntryPoint, because this is the class that will interact with picocli to set all given command-line arguments, load configuration files and whatnot. This should be split in two classes to make development of new CLI tools a bit easier: an EntryPoint class will invoke the Tool class.

Make sure to also consider these improvements when adding the new GUI type.

https://keepachangelog.com/en/1.0.0/

These look promising:

• https://github.com/olivierlacan/keep-a-changelog
• https://github.com/tomasbjerre/git-changelog-maven-plugin

Also, make sure that, using the latest POMs, integration tests are not executed unless the verify Maven goal is executed.

Check if the skipITs property is needed for this. Perhaps it is enough with our current POMs.

Once this issue has been addressed, update all of the pom.xml files to reflect the changes.

Do not forget to include changes in the provided sample-code folder.

Neither after_script nor after_deploy phases are executed when before_deploy succeeds but deploy fails. This means that we could potentially "leak" sensitive information by leaving files in a build that passed but could not be deployed (maybe our testing instance is not reachable).

Not sure if this is a big deal. Also, not sure what Travis does with "worker nodes" after a build has completed. Apparently only logs and some information about the build are available after a build finishes, regardless of its status.

The first solution that comes to my mind would be to leave the deploy phase like so:

deploy:
- skip_cleanup: true
  provider: script
  script: ( mvn deploy && rsync ) || rm -f sensitive_data

This will mean that, for Travis, all of our deploys will "succeed" (no matter what happens, the return code of the deploy script will always be 0). This might be confusing.

Maybe there's a Travis CI way to do it. More research is needed.

Maven does resource filtering and we should take advantage of it.

This:

<display>
	<category name="QBiC Portlets">
		<portlet id="{{ cookiecutter.artifact_id }}" />
	</category>
</display>

Should be:

<display>
	<category name="QBiC Portlets">
		<portlet id="${project.artifactId}" />
	</category>
</display>

This reference has been added in portlet-parent-pom, so it should be removed.

When performing a commit to the master branch, we recognised that the war files are deployed to the Nexus repository server, and there is no check, if a Github release has been done.

This way, "release" Maven artifacts can be deployed on Nexus, without having a connected Github release tag, which is bad. The line responsible for this is:

Adding ... AND tag = true' to the condition will fix this and only deploy, when a Github release has been made.

Everything in this project is related to Java projects. We also require shared .travis.yml along with configuration for unit testing.

Everytime there's a change in the base .travis.yml (the one in cookiecutter-templates-cli), all other repos should be updated.

Sadly, we cannot use git's modules to use this because Travis needs .travis.yml even before being able to issue the first git command.

I think the best way is to simply write a script that updates all .travis.yml files. This means that, in order to avoid fancy file parsing, we should have 100% generic .travis.yml files.

Perhaps we will need to create additional support files, such as .travis.options where developers could override the default .travis.yml. At the top of my head, some values that are not the same across all repos are:

• jdk: JavaFX-based projects use Oracle's JDK.
• Location of the main pom.xml: javafx-d3-lib is a forked repository and the pom.xml file is in the javafx-d3 folder.