1. 04 Apr, 2019 1 commit
  2. 29 Mar, 2019 1 commit
  3. 27 Mar, 2019 1 commit
  4. 25 Mar, 2019 2 commits
  5. 21 Mar, 2019 1 commit
  6. 16 Mar, 2019 1 commit
    • Jürg Billeter's avatar
      Rename cache-buildtrees option value 'failure' to 'auto' · 3951eb56
      Jürg Billeter authored
      We anticipate other cases than build failures where buildtree caching
      will be required.  E.g., incremental workspace build with remote
      execution. Or running tests in a buildtree in parallel with the build of
      reverse dependencies.
      
      This renames the option value 'failure' to the more generic 'auto' to
      cover these other cases as well.
      3951eb56
  7. 14 Mar, 2019 1 commit
    • Raoul Hidalgo Charman's avatar
      Integrate source cache with rest of buildstream · 6a1e7461
      Raoul Hidalgo Charman authored
      This involve introducing new Consistency states `STAGED` and `BOTH` that
      represent when the source is just in the local CAS and in both the local
      CAS and unstaged in the source directory.
      
      Sources are staged for each element into the local CAS during the fetch
      stage. If the sources are in the local consistency state `STAGED` when
      wanting to open a workspace, the original sources are fetched.
      
      Relavant tests this affects have been changed.
      
      Part of #440
      6a1e7461
  8. 28 Feb, 2019 2 commits
  9. 19 Feb, 2019 3 commits
  10. 15 Feb, 2019 1 commit
    • Angelos Evripiotis's avatar
      userconfig: rm really-workspace-close-project-inaccessible · c24f2971
      Angelos Evripiotis authored
      Remove the need for the 'really-workspace-close-project-inaccessible'
      config option, as well as the option itself.
      
      As agreed on the mailing list [1], all the 'are you sure?' prompts on
      workspace reset and close were removed. While that discussion was going
      on, this new prompt and option was added. At the 2019 BuildStream
      Gathering, it was verbally agreed between myself and Tristan VB that we
      would also remove this instance.
      
      It was also agreed that we should have a notice to let the user know
      what they'd done, this was already in place if interactive. Moved it to
      be unconditional so that there's no difference in non-interactive
      behaviour. Made it output to stderr, as it's diagnostic meant for the
      user. Made it the last thing echo'd so it's next to the prompt - it's
      very relevant to what they type next. Added a test to make sure the text
      makes it to stderr in the appropriate case, and not in an inappropriate
      one.
      
      This is the last instance of any prompt configuration, so BuildStream
      can also forget all of that machinery.
      
      [1] https://mail.gnome.org/archives/buildstream-list/2018-December/msg00111.html
      c24f2971
  11. 13 Feb, 2019 1 commit
    • Tom Pollard's avatar
      Add cli main & user conf option for 'cache-buildtrees' context · 118644b2
      Tom Pollard authored
      _context.py: Add cache_buildtrees global user context, the default
      of which is set to by default to 'always' via the addition of
      cache-buildtrees to userconfig.yaml cache group. 'failure' & 'never'
      can be given as valid options.
      
      app.py & cli.py: Add --cache-buildtrees as a bst main option, which
      when passed with a valid option can override the default or user
      defined context for cache_buildtrees.
      
      tests/completions/completions.py: Update for the added flag.
      118644b2
  12. 12 Feb, 2019 1 commit
  13. 29 Jan, 2019 1 commit
    • Angelos Evripiotis's avatar
      BREAK:remove unconditional 'are you sure?' prompts · 86c8e414
      Angelos Evripiotis authored
      This is a breaking change, as it affects behaviour that people might be
      relying on. An entry has been added to NEWS.
      
      As proposed on the mailing list, this change removes the unconditional
      prompts on:
      
          o: bst workspace reset
          o: bst workspace close --remove-dir
      
      If interactive, these commands would always interrupt you with a prompt
      like this:
      
          This will remove all your changes, are you sure?
      
      This seems like it may just save someone's work some time. It may also
      condition folks to hit 'y' quickly without thinking.
      
      This change also makes the non-interactive behaviour consistent with the
      interactive behaviour in the default case. There is also the case of the
      prompt configured by 'really-workspace-close-project-inaccessible',
      which may be tackled in later work.
      
      This change also removes the new config options to suppress those
      prompts, and their associated news entry.
      
      The relevant bit of the mailing list conversation is here:
      https://mail.gnome.org/archives/buildstream-list/2018-December/msg00106.html
      
      The issue to make interactive and non-interactive behaviour consistent
      is here:
      #744
      86c8e414
  14. 24 Jan, 2019 2 commits
  15. 16 Jan, 2019 3 commits
  16. 09 Jan, 2019 1 commit
  17. 20 Dec, 2018 1 commit
    • Angelos Evripiotis's avatar
      BREAK: remove auto-init behaviour · 46efc91d
      Angelos Evripiotis authored
      In the event that the project could not be found, stop BuildStream from
      asking if the user would like to create a new project. Exit with error
      instead, and give a hint to the user in case they're new.
      
      As proposed on the mailing list here:
      https://mail.gnome.org/archives/buildstream-list/2018-December/msg00082.html
      
      The new interaction looks like this:
      
          $ bst show nonsuch.bst
          No project found. You can create a new project like so:
      
              bst init
      
          Error loading project: None of ['project.conf', '.bstproject.yaml']
          found in '/src/temp/blah' or any of its parent directories
      
      Fixes #826
      46efc91d
  18. 11 Dec, 2018 4 commits
    • Jonathan Maw's avatar
      Make specifying elements optional in bst commands · a1dee91e
      Jonathan Maw authored
      Known issues:
      * `bst shell` works, but `bst shell COMMANDS...` doesn't, because click
        has no way of separating optional args from variable-length args.
      * `bst checkout` and `bst source-checkout`'s usage strings mark LOCATION
        as an optional argument. Because click gets confused if there's an
        optional argument before a mandatory argument, I had to mark LOCATION
        as optional internally.
      * `bst workspace open` makes no sense with element being optional, so
        I skipped it.
      * `bst workspace close` will probably need to be revisited when multiple
        projects can own one workspace.
      * `bst workspace reset` will happily delete the directory you're
        currently in, requiring you to `cd $PWD` to see the contents of your
        directory.
        I could exclude the top-level directory of the workspace being
        deleted, but it is entirely valid to run workspace commands from deeper
        in the workspace.
      
      This is a part of #222
      a1dee91e
    • Jonathan Maw's avatar
    • Jonathan Maw's avatar
      cli: Interactively warn if the user is trying to close the workspace they're... · f145a3e4
      Jonathan Maw authored
      cli: Interactively warn if the user is trying to close the workspace they're using to load the project
      
      This involves changes in:
      * _stream.py:
        * Add the helper Stream.workspace_is_required()
      * userconfig.yaml:
        * Add a default value for prompt.really-workspace-close-project-inaccessible
      * _context.py:
        * Load the prompt 'really-workspace-close-project-inaccessible' from
          user config.
      * cli.py:
        * If buildstream is invoked interactively, prompt the user to confirm
          that they want to close the workspace they're using to load this
          project.
      
      This is a part of #222
      f145a3e4
    • Jonathan Maw's avatar
      Create and store data inside projects when opening workspaces · 67c7a58d
      Jonathan Maw authored
      Changes to _context.py:
      * Context has been extended to contain a WorkspaceProjectCache, as there
        are times when we want to use it before a Workspaces can be initialised
        (looking up a WorkspaceProject to find the directory that the project is
        in)
      
      Changes to _stream.py:
      * Removed staging the elements from workspace_open() and workspace_reset()
      
      Changes in _workspaces.py:
      * A new WorkspaceProject contains all the information needed to refer back
        to a project from its workspace (currently this is the project path and
        the element used to create this workspace)
      * This is stored within a new WorkspaceProjectCache object, which keeps
        WorkspaceProjects around so they don't need to be loaded from disk
        repeatedly.
      * Workspaces has been extended to contain the WorkspaceProjectCache, and
        will use it when opening and closing workspaces.
      * Workspaces.create_workspace has been extended to handle the staging of
        the element into the workspace, in addition to creating the equivalent
        WorkspaceProject file.
      
      This is a part of #222
      67c7a58d
  19. 27 Nov, 2018 1 commit
  20. 21 Nov, 2018 1 commit
  21. 20 Nov, 2018 4 commits
    • Angelos Evripiotis's avatar
      Add prompt.workspace-... options · 7ae3a3d2
      Angelos Evripiotis authored
      Provide options in project.conf to disable the 'Are you sure ...'
      prompts when making destructive changes:
      
      - Add prompt.really-workspace-close-remove-dir
      - Add prompt.really-workspace-reset-hard
      
      Add a NEWS item for these.
      7ae3a3d2
    • Angelos Evripiotis's avatar
      Add prompt.auto-init buildstream.conf option · 27ca6593
      Angelos Evripiotis authored
      Provide an option in buildstream.conf to disable the 'Would you like to
      ...' prompt when we cannot resolve a project.
      
      Some users prefer not to be interrupted by such prompts, so pave the way
      to creating options to disable all those that might get in the way.
      
      Follow the example of the advice.* options 'git-config', and create a
      namespace for these UI options grouped by behaviour, rather than an
      over-reaching 'ui.*' namespace. In later work perhaps we'll also add
      'advice.*' options.
      
      Add a NEWS item for this.
      27ca6593
    • Angelos Evripiotis's avatar
      _context: refactor, extract _node_get_option_str · b81c4333
      Angelos Evripiotis authored
      Use a new helper function to simplify working with nodes that can only
      accept certain strings. This will be used when adding the prompt.*
      config options.
      
      In later work we can see if this function would be useful elsewhere, and
      could be added to '_yaml.py'.
      b81c4333
    • Angelos Evripiotis's avatar
      _context: allow 'terminate' for scheduler.on-error · eb2d376f
      Angelos Evripiotis authored
      Enable this option of 'terminate', which is mentioned in userconfig.yaml
      and handled in _frontend/app.py:_handle_failure(). It appears to have
      been left out of the valid_actions as an oversight.
      
      Originally introduced in
      2622d5da
      eb2d376f
  22. 19 Nov, 2018 1 commit
  23. 17 Nov, 2018 1 commit
    • Tom Pollard's avatar
      Add cli main and user config option for 'pull-buildtrees' context. · 199bfff1
      Tom Pollard authored
      _context.py: Add pull_buildtrees global user context, the default
      of which is set to False via the addition of pull-buildtrees to
      userconfig.yaml cache group.
      
      _frontend/app.py & cli.py: Add --pull-buildtrees as a bst main
      option, which when passed will override the default or user defined
      context for pull_buildtrees.
      
      tests/completions/completions.py: Update for the added flag.
      199bfff1
  24. 05 Nov, 2018 1 commit
  25. 25 Oct, 2018 1 commit
  26. 18 Oct, 2018 1 commit
  27. 27 Sep, 2018 1 commit