nemerosa / ontrack Goto Github PK

As a project owner, I want my branches to be created automatically according to a template.

The branches could be sync manually or automatically.

• Wiki documentation for the templating of branches
• Branch decorations
• Model for the templating (impact on the branch model itself)
• A SCM branch name given by the sync. source cannot be used directly for creating the name of a branch since naming conventions can be different. The name of the ontrack branch must be normalised.
• Listing the branches (Git) - see git ls-remote
• Listing the branches (Svn)
• Template expression engine
• Sandbox for the expression engine (other issue)
• Model for the templating synchronisation
• Specific function for the creation of a template definition
• Cannot get a template definition from a branch that contains builds
• Generic template engine (for recursion over the branch and its components)
• Creation of a template definition
• Template instance type
• Template definition cannot be enabled (see for a dynamic computation of the state of a branch)
• Decorations of template branches
• Simple creation of a template instance from a definition
• A template instance cannot be updated. Not changing anything here, a template instance can be edited, but any change might be overridden by a new synchronisation
• Displays a report about the manual synchronisation
• Reports synchronisation events through the event service
• On sync, take into account the linked instances that are now outside of the sync list (absence policy)
• Decorations of template instances
• A template instance can be disconnected from its definition - it becomes then a normal branch. Note that we cannot just remove the template instance record ; this would just make the instance recreated again at the next synchronisation It is enough to delete the template instance record, any synchronisation will not erase this branch - it will just be marked as not being able to be updated and should be be marked as excluded by the synchronisation definition.
• Creation of a template synchronisation
• When updating the template definition, resync automatically Not needed, the resync can be done either manually or at the next schedule
• GUI - being able to remove a parameter
• GUI - no manual mode when no parameter

Authentication works only for Github. The authentication process should work with other git repositories like Stash, Gitblit, ...

When a project's branch has too many promotion levels, they overflow on the right, under the properties section.

They should flow in the branch section.

Allows authorised users to manage the authorisations of groups and users in each project.

Having a page for the admin to see the list of registered and running jobs.

On the job administration page, add additional information like:

• number of runs
• time of the last run
• time of the next run

Allow also the administrator to launch manually a scheduled job.

Validation stamps Jenkins decorations are displayed once, but are not refreshed regularly.

On the branch build view, the Refresh button is not aligned with the other buttons (Filter or Change log).

When displaying the issues for a SVN change log, detects the issues which have revisions beyond the range the change log.

If the issue status is not Closed, this is an anomaly.

This kind of validation must be generic enough is order to be parameterised.

Since Maven 3.2.1, there is a way to have CD-friendly versions in POM: https://jira.codehaus.org/browse/MNG-5576

This may allow us to switch back to Maven and simplify the build when compared to Gradle.

Upgrade SVNKit to the latest version.

Create a build filter on names:

• build name regular expression
• optional promotion level
• do we keep the first build that does not comply?

This can be useful for getting the change log between two versions.

The Artifactory extension creates a new promotion at each run.

An extension could be configured at branch and/or project level to synchronise the builds of a branch with the builds found in Artifactory.

There should be a configuration (like for SVN or JIRA) that holds the URL and the credentials to access Artifactory.

A branch or project level, a configuration can be added with the following parameters:

• the build name
• the synchonisation schedule (number of minutes)

For each sync session, we must fetch the builds and check their promotion level (status in Artifactory) and create the associated promoted run if needed.

As a project owner, I want to create a branch from another one, only changing some parameters.

Existing filters for the builds should be editable.

Support authentication through a LDAP.

If i try following rest url :

http://localhost:9080/structure/entity/branch/JNode/0.2.9

I receive following json as result :

{"status":404,"message":"Branch not found: JNode/0.2"}

As a project owner or administrator, I should be able to copy (and override, and/or replace) promotion levels from another project or branch.

This is of course restricted by visibility.

The same procedure can be applied for the other data of branches:

• validation stamps.
• properties
• user filters

When loading the list of builds, indicate something is happening.

When clicking on the version link, we get the following error:

Error: [$injector:unpr] Unknown provider: aProvider <- a

It is likely an error in the ngmin task. Think about using ng-annotate (olov/ng-annotate) instead.

On the promotion level page, display the list of promotion runs. Note that there may be several runs for one same build.

Events are associated to some actions, like creating a branch or promoting a build, and are displayed on the associated pages.

Events visibility is associated to the corresponding rights, typically the right to view a project.

• Event repository: saving
• Event repository: querying & filtering
• Navigation in event list
• Auto refresh for event lists
• List of events per page
• All types of events
  • Structure events
  • Property changes events

java.lang.NumberFormatException: For input string: "ITEACH-14"
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
    at java.lang.Integer.parseInt(Integer.java:580)
    at net.nemerosa.ontrack.extension.github.GitHubIssueServiceExtension.getIssueId(GitHubIssueServiceExtension.java:119)
    at net.nemerosa.ontrack.extension.github.GitHubIssueServiceExtension.containsIssueKey(GitHubIssueServiceExtension.java:126)
    at net.nemerosa.ontrack.extension.issues.model.ConfiguredIssueService.containsIssueKey(ConfiguredIssueService.java:53)
    at net.nemerosa.ontrack.extension.git.GitIssueSearchExtension$GitIssueSearchProvider.scanIssue(GitIssueSearchExtension.java:130)

The containsIssueKey must be able to filter out non-GitHub keys.

Authorised people could disable/enable projects and branches.

What has to be defined:

• which levels of authorisations?
• how to show the disabled projects and branches (option in the tool menu on the home or project page)?

The custom images (promotion levels, etc.) are not visible on Safari, because it seems the ngSrc attribute is not supported.

The current icon is difficult to identity from far away.

Some fields (like SVNBranchConfigurationPropertyType#tagPattern) should allow HTML to be used as help.

A special @file could be used and translated into extension/form/file.tpl.html by the client.

I want to have somewhere on the page (logo?) and indicator that shows that something is happening, linked to AJAX calls.

Some calls, like getting the application info, etc., should be able to disable this.

Given a branch and two build names, I want to get the change log as HTML in order to automate the change log generation.

It should be possible to configure the grouping of issues by type or label. Since this depends heavily on the issue service (GitHub, JIRA...), see what can be done.

In a SVN-configured branch, one can generate builds based on tag names found in Subversion.

There must be an option to override or not the existing build tags.

Note that the same option exists for Git (v1).

The synchronisation can be launched on demand or executed regularly using an interval in minutes.

The synchronisation is configured through two extensions:

• a property extension at branch level to define the setup of the synchronisation (override settings, interval). This can be done only if the branch is configured correctly with SVN
• an action extension at branch level to launch the synchronisation manually

Add filter based on dates (before/after) in the standard filter.

When the number of builds in a branch is high, the query to get them takes too much time, whatever the filter being selected.

1. Wait for first maintenance releases
2. Check compatibility with Spring Security and upgrade also if necessary

Support for JSON views and request interceptors

On the branch page, have a dropdown that allows the user to switch between all the branches of the same project.

On the validation stamp page, display the history of the validation runs. Note that there may be several runs for a same build, and that the same run can have several statuses.

When a branch has only /trunk as a path in the repository, and not something like /project/trunk, the /trunk is not identified as a trunk path and the SVN history is not collected correctly.

Having a way to generate the documentation of the ontrack REST API, either dynamically or statically at build time (to be determined).

1. Create a GitHub configuration with an OAUth2 token
2. The list of configurations cannot be displayed

The difficulty comes here from the fact that both the indexation & the sync can be triggered manually.

There must be a way to trigger a registered job automatically via a triggering mechanism, that would not wait for one minute to elapse.

An additional difficulty comes from the range indexation.

There could be a JobQueue service, where client jobs may post their request for a job to be executed.

The range indexation can be a specific type of job that can be posted on this queue.

In the nemerosa/iteach project, we have tags which are "detached" from the master branch:

* f1caffa Adapt some FIXMEs
* dfdbbcf ITEACH-28 Contracts from v1.1.1 can be null (cherry picked from commit bbd2208)
* 634c6b2 Prepare for release 1.3
| * 0f782dc (tag: 1.2.0) Version 1.2.0
|/  
* f8d8653 ITEACH-22 No need to reload the page
* 196996a ITEACH-22 Loading the calendar preferences

When looking for the earliest tag from f8d8653, 1.2.0 is not found because we look from the HEAD only down to the target commit.

When apply a filter:

• with promotion level A
• since promotion level B
  builds are shown with promotion level A, but not until promotion level B (they stop before)