Roots Discourse

Github dist (compiled) Release Workflow

I maintain several plugins (both at the .org repo and proprietary ones for clients that I manage in private satis instance to be used by composer on arbitrary projects)… the plugins typically uses sass and js - and I use a compilation process (gulp, grunt or webpack depending on the project) to builds the CSS, minifies, concatenates, etc.

every time I make a change, I run my compilation (gulp, grunt or webpack), i commit the compiled files then I manually change the version number in the main file and readme, and then run a commit it usually as “preparing for 0.3.0” and then tag it and push up which gets consumed by satis running a cron and I can update my arbitrary projects’ composer files to use the newest version.

I know for sure there’s a better way of doing this – I’d love to keep my repositories clean with just uncompiled files - add a post push hook to run some sort of a build process, set the version numbers, compile and create a dist release on github that would get picked up by my satis and be able to be used my composer for arbitrary projects.

Does anyone have experience doing this? Would I have this build process create a new branch, run the build, create the tag and push up? wouldn’t that pollute my repo with commits of compiled files? Thanks for any advice.

Yes, what you are currently using a “dirty” commits where the
built artifacts are also committed together with the source files.

One approach that is also often used in trellis is to build on
workstation + sync the resulting files separately.

That kinda didn’t answer my question directly.

I figured a build process would be necessary - I’m asking the how not the what :slight_smile:

You commit your source files, the dist/ files are gitignored (by default, e.g. with sage theme).
On deploy, the trellis deploy task will run the gulp build task in your theme and then rsync the dist/ contents to target server.

heh, that’s not answering my question – you’re answering a question about uncompiled files on a specific theme, I’m asking about (potentially multiple [and many]) individual plugins.

I don’t want to add a build process for (potentially multiple [and many]) individual plugins that could get pretty unwieldy quickly.

To summarize this:

  • Plugins in private satis instances
  • These plugins use sass and js and both have to be compiled
  • After each change, manual steps are required for releasing (build + publish) a new version to its satis instance
  • Dist files (build artifacts) are committed together with the source.
  • You’d like to just have the source files in version control without the dist files.

A continuous integration workflow can be helpful here (Jenkins, Travis, CircleCI, …). Each time the stable branch (often master) is pushed to central repository, a CI server pulls, builds and tests the project and pushes a new release to satis when everything passed, optionally with a manual release trigger step.

Concerning the usage of build artifacts for a release in satis, there is a related mailing list thread:
https://groups.google.com/forum/#!topic/composer-users/KTybYqJosNQ
A ZIP file can be used for satis - which can be also generated by the build task on CI server.

Thanks Starsis.

Just adding a bit more clarity:

The idea is to have 1 git repo for each “plugin” – I could set up two repos in git one called my-plugin-name-src and another called my-plugin-name

I could have a build process that will check out the *-src - build it, commit and tag the non-src repo and have my satis (custom packagist for composer) point to that repo - but that would require two repositories for every plugin - I don’t love that solution

What I was hoping for would be some way to build/compile and tag a zip that corresponds to an unbuilt/uncompiled tag in the same github repo - one that allows me to have my composer grab that built one when running composer install/update.

I’ll check out what you linked to. Thanks again.