$ git clone https://github.com/42ity/FTY && \
  ( cd FTY && make world )

$ git clone https://github.com/42ity/FTY && \
  cd FTY && \
  make -j 4

The Makefile provides a development-rebuild option, invoked like this:

which takes effect both for components "prepped" as symlinks (e.g. by setting PREP_TYPE_fty-example=cloneln-src or cloneln-obj in the Makefile) and as copies of files (PREP_TYPE_component=clonetar-src or clonetar-obj). This is the default now, unless a recipe for some component defines a different PREP_TYPE because of its build-system quirks.

If the component was already configured, this recipe just runs a make in its custom build directory and so recompiles just the binaries whose sources you have changed right in the common checked-out Git workspace.

Of course, this only works as long as you have not added new source files, etc. — but that sort of change would anyway need a rebuild/fty-example. Other similar limitations may exist but were not yet found or documented.

As a fallback, this would prep/autogen/configure components that were not yet "configured", and would fall back to a full rebuild for components that are not "prepped" as symlinks.

The intended use-case looks like this, to streamline iterations of small changes during development:

…​or this for custom runs (assuming one platform so /*/ is not ambiguous in the short example below):

This Makefile supports make web-test and make web-test-bios recipes to help with in-place testing of the fty-rest component during development.

The make web-test integration simply builds fty-rest with dependencies (including a copy of tntnet from the tracked fork) and runs it with the tntnet.xml generated by fty-rest (pointing to the freshly built copy of bios-web.so), as the developer’s user account on a dedicated port (8000) and using a dedicated directory for data files that the servlets might edit without conflict with the OS — at least as long as sources do not use any hardcoded paths. This recipe has the same effect as if developer went to the fty-rest workspace and executed make web-test there (using same-named recipe in that component), it just provides the depedencies built from the freshest of sources.

The make web-test-bios integration is intended for tests approaching the reality of our product, running in our generated and pre-configured OS image in a container or on a rack controller. As such, this recipe takes the same /etc/tntnet/bios.xml file (presence required) and environment variable files as referred by the production systemd unit tntnet@bios.service, and produces a configuration patched for the compPath reference to the freshly built copy of bios_web.so object with developed servlets. Then this recipe disables the running instance of tntnet@bios.service and uses sudo -E to start the freshly built webserver in its place as root, so it changes credentials according to configuration just as the packaged service does. As you can see, this recipe requires quite a bit of circumstances and intentional system setup to work; in particular this should keep your daily host operating system safe from experimental code ;)

Note that as part of the project’s evolution and legacy, it used to require the czmq version 3.0.2, and since that release was obsoleted by upstream a while ago, we tracked our own fork with small fixes. Subsequently the code of 42ITy™ components where it mattered was updated to support either the CZMQ3 or CZMQ4 APIs, and now the Makefile in this repository allows to automate the builds against either our czmq-v3.0.2 fork or the upstream czmq-master from the GitHub, or using binary packages of zeromq stack as provided in your OS by other means (beware that these can lag behind respective upstream/master or upstream/stable branches and so can lack the features that 42ITy codebase might need). Our current goal is to drop the requirement of the obsoleted version and use the community-supported master branch, where we can collaborate on fixes for bugs that bite us all.

To choose the czmq version to build your FTY components against, you can define the CI_CZMQ_VER=<value> (as an exported environment variable, or as a make argument); suported values are 3 for our "czmq-v3.0.2" fork (it is also the default choice if no value is set explicitly), 4 for the upstream/master which is currently under the 4.x umbrella versions, and pkg for OS packages of the whole libsodium`libzmq`czmq+malamute stack.

The zeromq-related ecosystem of software projects has recently added support for building with the Address Sanitizer in supportive compilers such as the recent GCC versions. You can find more details about this technology at https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html and https://github.com/google/sanitizers/wiki/AddressSanitizer.

This can be enabled in Travis CI tests for projects generated with zproject and now for (Travis or manually executed) builds done with the Makefile provided by this FTY repository, by an exporting an environment variable usually before a memcheck/valgrind build and run:

Note that the actual compilation flags enabled by such toggle can depend on contents of the configure.ac scripts in each component project, and of course functionality of the actual implementation depends on the evolution level of the compiler in use for the build.

Also note that Leak Sanitizer (-llsan) is not currently available in the Travis CI operating environments.

This Makefile has been verified on Debian 8 (devel images for the project build farm); it also passes on Ubuntu-based systems used in the Travis CI cloud. Much but not all of this code can also build under OpenIndiana, more with a purpose to test the approach to portability than to use it there (in the near term at least). Feel free to update the recipes if needed for other OSes and distros, and take inspiration from hooks made for and used by the OpenIndiana/SunOS integration.

:; git submodule add https://github.com/42ity/fty-new-agent

:; git submodule add -b 42ity https://github.com/42ity/third-party-fork

At this time the convention for settling on a certain release of the upstream project is to (assuming you have the admin rights for 42ITy org on GitHub):

• Fork it on GitHub under the 42ITy org;

• Go to Travis CI web interface at https://travis-ci.org/profile/42ity/, click to "Sync account" and enable the new fork in sliders below;

• Fork the 42ITy replica to your developer account (you can also use a fork of original upstream repository — but then take extra care about pull request targeting later on);

• Clone it to a temporary local workspace, outside the FTY directory;

• Check out the commit we settled on as the current baseline, usually some X.Y(.Z) release: git checkout 123cafe or git checkout release/1.2.3;

• Nail it down for easier later comparisons or merging as we’d decide to move on to a new baseline: git checkout -b 1.2.3-release;

• Branch off a stable line we’d use to cut an end-user release at some point: git checkout -b 1.2.3-FTY;

• Branch off a "master-like" line we’d use to develop and stage improvements to this fork, like backported bugfixes or updated Travis integration recipes: git checkout -b 1.2.3-FTY-master — this stuff would be used in daily OS images and eventually passes from here to the X.Y(.Z)-FTY branch;

• Put the new branching info to the 42ITy fork: git push --all origin

• Go to GitHub web interface, select the new 42ITy component and go Settings / Branches, e.g.: https://github.com/42ity/libzmq/settings/branches

• Pick the X.Y(.Z)-FTY-master branch as the default, click accept;

• Prevent inadvertent changes to the non-master branches:

  • Under Protected branches, choose the X.Y(.Z)-FTY and click that we want to "Protect this branch", "Require pull request reviews before merging" (and "Dismiss stale pull request approvals when new commits are pushed" under that), "Require status checks to pass before merging" (and "Require branches to be up to date before merging" as well as CI tests where defined) and finally "Include administrators" so at least two people are needed to push the changes to these branches (an admin can also unset this protection, when in a pinch).

  • Repeat for X.Y(.Z)-release.

  • Do not protect the branches we’d want to track from the original project, like the master for most of them, as you’d pull-push these occasionally (or even automatics would).

• Finally, set up git submodule tracking (e.g. using the sync-repos.sh) in your checkout of the FTY repo;

• Revise that the appropriate X.Y(.Z)-FTY-master is the default tracking branch in .gitmodules for FTY master branch, and X.Y(.Z)-FTY is for the FTY FTY branch;

• Add corresponding commits to the FTY repos to begin tracking the project as submodule;

• Update Makefile etc. as may be needed to track this component and maybe its build variants (like we have done to test various CZMQ versions);

• Possibly update our other projects (project.xml files and Travis recipes) to build by default against our specified fork and branch, rather than the upstream master repositories which may e.g. no longer expose bugs that can plague our builds…​ or vice versa (new bugs are introduced by upstreams from time to time, that we don’t see in our OS images).

• Push back the updates to the FTY repository on GitHub.

To use your local workspace for occasional synchronization from the original project, run the git-myorigin script detailed below to ensure that your upstream refers to the 42ITy fork, and origin is your own private fork. Then add tracking for the opensource reference to the original project and specify that you want certain branches (like master) to come from there:

While here, you can also make sure to push the FTY branches to your private repository, to use for PRs later on:

For projects (currently czmq) where branch and tag naming use the same string values, which is valid but confuses some git operations including checkouts, you might want to forbid pulling remote tags:

Given sufficient rights in the 42ITy org, you can later synchronize the master branch upstream changes, so we can keep track of all changes there (and of how far ahead/behind is our forked project), with:

Do not forget to git checkout X.Y(.Z)-FTY-master after doing this, or perhaps keep aside a workspace with a checkout of the FTY repository just for this job. In particular, take care to not add to the git-submodule tracking the commit IDs not pointing to the latest X.Y(.Z)-FTY(-master) state. The ./git-sub-branch-list can speed up such verification.

When updating the FTY repo itself and transplanting changes between the repositories, make sure that the FTY and master branches keep pointing where they should have (do not merge unexpected changes to .gitmodules). The git checkout master && git diff FTY .gitmodules trick can help here.

Generally a git checkout master && git diff FTY should only show the .gitmodules file and some different submodule references (commit IDs).

:; echo 'GITHUB_USER="mygithubname"' > ~/.git-myorigin
:; ./git-myorigin */