Use-Case: Developer pipeline?

[Crunsher]

Dev A pushes something into branch feature/xyz. They now want to build packages for a random distro-arch combination, the result must not be pushed to the repository but available for download.

A: snapshot pipeline can be configured at start B: A developer pipeline

[Thomas-Gelf]

...the result must not be pushed to the repository but available for download

As tools like Aptly and Pulp allow one to build dynamic repositories at a low cost, having dynamic builds going to dynamic repos would be a fantastic feature. But that's optional. For the developer pipeline itself I could imagine the following workflow:

• pipelines per product are triggered in an automated way (preferably hook-based) for at least every tag
• developers and release managers can trigger a build at any time by using a defined set of flags in their commit message
• git push should show the expected link to the artifact that's going to be built, or at least the url pointing to the related job in it's pipeline
• in the (optional) variant allowing one to create dynamic package repositories (for given distributions), job details should provide related informations

Short: we shouldn't force a developer to switch context as this distracts and wastes time. GIT is what he uses for it's work, to close tickets and to trigger builds or releases.

[Crunsher]

Here are the notes I took out of my talk with @Thomas-Gelf :

The proposal was to have a pipeline, which would change its publishing behavior based on branch names and create dynamic repos via aptly. This would require us to expand the publish script and either work with Jenkins' conditional steps or an additional developer pipeline (see diagram)

The build could be controlled by the branch name, having Github (or some other solution) start a build whenever a commit is pushed into a 'build/' branch (to use like feature/ and fix/). The following example shows a possible naming scheme: '/build/fix-bug-1234/centos-sles/x86_46' This would trigger a build with the contents of this branch on centos and sles with the architecture x86_46 and push the results to a repo named 'fix-bug-1234'. It'd also be welcome if the git server answers with a link to expected repository to a push into such a branch. A cron job or hook would then upon deletion of the branch delete the corresponding repo with its contents.

TODO

• Explore GitHubs hook capabilities
• Allow Jobs to run in parallel
• Publish script to create dynamic repos
• cleanup
• Figure out parameterized meta jobs needed
• Conditional steps (optional)