NEW: support for
Continuous builds with Gradle! Adds a CI-like package to your status bar, showing you the last build-status and let you access the latest build-reports.
GradleCI watches your current project and invokes builds, everytime you're saving a file.
The previously released versions of GradleCI were unintenional buggy. After getting informed that my package will be deprecated during the 1.x-API-release, i took the opportunity to rewrite the mechanisms behind the scenes. During the rewrite i found out that my vision of the package-functionality is unlikely to become realized with the tools of the Atom-environment.
I was - for example - planning, that the builds will be invoked by Git-commit. Unfortunately there's currently no efficient and non-intrusive way to catch commit-events. For every functional aspect i tried and tested different approaches to find the best way to solve it. This is how GradleCI currently works:
During startup GradleCI tries to call all given build-commands (f.e.
gradle) via commandline to find out if Gradle is callable in general and which Version of Gradle will be invoked. The version-number might be used in the future to behave correctly - currently there is no known dependency on your Gradle-version.
If the invokation was successful, the statusbar-item is renamed to the version of Gradle and in the result pane the invoked build-command is being displayed.
After successful startup of the package and everytime you're changing the project-paths (f.e. by adding or removing a project-path), GradleCI tries to find and set the available build-paths.
Currently the identification of build-paths is limited, GradleCI takes every project-path and tries to access a build-file on its base-path. In other words, GradleCI does not recursively search for build-files (although this feature is planned for a future-release).
Every project-path which contains a build-file, which is readable by the current process is added to the list of available buildpaths (this is necessary to handle multiple project-files in a correct manner).
GradleCI observes every pane you have opened. Everytime you're saving a pane, GradleCI tries to get the corresponding build-path. If a build-path can be identified the build is scheduled. You're also able to invoke build manually by using the menu-entry.
GradleCI enqueues all builds after the FIFO-principle. If you're changing a file in a project-directory, which currently gets built, a second build is scheduled for that directory. This is done because GradleCI is not caching your project (for performance reasons) and i'm not able to predict if your file changes will be recognized by the actual build.
Every result of the run will be appended to a list of results, this list keeps 3 results as a default. You're able to change the number of results kept in the package-preferences.
If you already have some results you have the possibility to toggle the result-pane either by clicking on the statusbar-item, by invoking the command in the command-pane, by using the menu- or contextmenu-item and using the keyboard-shortcut.
After the result-pane is opened, you may change its size with drag'n'drop. You can close the result pane the same ways you used to open it.
apm upgradefrom your command-line.
All preferences of the package are elucidated in the preferences of the package.
Issues, suggestions and pull requests are more than welcome.
Good catch. Let us know what about this package looks wrong to you, and we'll investigate right away.