Skip to content
This repository has been archived by the owner on Apr 6, 2021. It is now read-only.

Changed plugin #15

Open
nathankleyn opened this issue Sep 22, 2015 · 1 comment
Open

Changed plugin #15

nathankleyn opened this issue Sep 22, 2015 · 1 comment

Comments

@nathankleyn
Copy link
Contributor

We will have need of a way to tell if a project has changed between executions to speed things up. At the moment, we execute all projects every single time regardless of whether they have changed.

The proposed design is as follows:

  • We use the tree of files provided by Plugin globs do not respect .gitignore #14 to get everything to be considered, sans anything ignored by a .gitignore file.
  • We load up any existing index we have stored. If none, we consider it empty.
  • For each of these files, we check the modified and created at times against those stored in the existing index and if they're newer or they're missing, the file is changed.
  • If they're the same, newer or missing, we SHA the contents of the file and store that in the index along with the created at and modified time.

This gives us as quick index from which we can see if any file has changed at any time.

One issue arising when considering when to save this index. Many workflows could potentially be composed of multiple commands only after which you want to save the index. To make this work, we can perhaps introduce a shanty checkpoint task which actually does the saving of the index. After this point, that will be the baseline to which everything will be compared. A project being changed will simply add a changed tag which can be used to only run the changed things.

shanty test --tags changed

Finally, one notes that the calling of shanty checkpoint can actually be automated in most workflows by doing one of the following:

  • Adding a Git/SVN hook to call it when the current commit changes.
  • Configuring CI plugins to run this at the end of a CI build.
@nathankleyn
Copy link
Contributor Author

Part of addressing this will undoubtedly touch on #13, as we will using an index for getting at the tree of files now instead of globbing the disk over and over.

nathankleyn added a commit that referenced this issue Sep 28, 2015
This allows work that will depend on this functionality to get started
in parallel by agreeing an API upfront that we can all work to.
janstenpickle added a commit that referenced this issue Sep 28, 2015
(#15) Add initial interfaces for changed functionality.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant