Skip to content

Update build with "Pulling cache" when downloading the cache #6800

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 7 commits into from

Conversation

humitos
Copy link
Member

@humitos humitos commented Mar 20, 2020

This is the simplest way to communicate to the user that their builds are already running, but we are pulling down the cache to start from there instead from scratch.

We could discuss other options as well, but I think this is the easiest one and it's a good start for now.

Related to #6793

Copy link
Member

@ericholscher ericholscher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense -- we should likely set this status during the end stage of the build when we're saving it as well. I found it confusing when waiting on the build that looked done.

I'd love to have a state that is also "Uploading files" or similar, because for the WTD builds, it sits for a minute in that state when it appears the build is already done.

BUILD_STATE_CLONING = 'cloning'
BUILD_STATE_INSTALLING = 'installing'
BUILD_STATE_BUILDING = 'building'
BUILD_STATE_FINISHED = 'finished'

BUILD_STATE = (
(BUILD_STATE_TRIGGERED, _('Triggered')),
(BUILD_STATE_PULLING_CACHE, _('Pulling cache')),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to call this something that works for both pushing & pulling, perhaps Updating cache.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we want this, we will need to change how we handle the FINISHED status.

Currently, the build is first marked as FINISHED and then the push is performed. The FINISHED status is sent when we leave the context manager of the environment (__exit__) and the cache is pushed after that only if the build was successful.

Taking a look at the code, it seems that our options are:

  1. update the state of the build to FINISHED outside the environment __exit__ method
  2. use update_on_success=False when initializing the environment and update the build status to FINISHED manually after pushing the cache.
  3. push cache always (not only on successful builds)

I think that 2) is our better option since it uses the API we already have in the code to avoid updating the status automatically.

If we are going in this direction, why not to add an specific status for each operation? Pulling/Pushing or Downloading/Uploading or similar.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went ahead and implemented 2).

It shows "Pushing cache" if the project has the feature and the build is marked as finished outside the __exit__ method. With these changes, the total build time will count pulling/pushing the cache as well, so it will be more realistic.

@humitos
Copy link
Member Author

humitos commented Mar 24, 2020

I'd love to have a state that is also "Uploading files" or similar, because for the WTD builds, it sits for a minute in that state when it appears the build is already done.

I opened a new PR for this at #6810

@humitos
Copy link
Member Author

humitos commented Mar 24, 2020

@ericholscher I added a new state. It may worth to review these changes as well.

@agjohnson
Copy link
Contributor

I think we need to think this through a bit more, I'm -1 on the approach of further overloading the concept of build state to accomplish this.

A better approach would be to include this in the list of build command output, so that you can see the progression through the stages. It's not as meaningful to keep updating the build state, as this information is lost as soon as the state is updated again. Will the user even ever see this state? With checkouts, we can see the checkout commands progress.

This feels like a short term hack to bake in some UX that might not even be needed. I'd rather find a future proof solution and hold off on making any changes to this UX until we know more about how we'll use caching. If feels premature to make this change.

@agjohnson agjohnson added the Needed: design decision A core team decision is required label Mar 24, 2020
humitos and others added 2 commits March 24, 2020 16:59
Show "Uploading" build state when uploading artifacts into storage
Copy link
Member

@ericholscher ericholscher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably close this one until we have a better caching solution, since we aren't using it.

@humitos
Copy link
Member Author

humitos commented Apr 16, 2020

Agree 👍

@humitos humitos closed this Apr 16, 2020
@stsewd stsewd deleted the humitos/pulling-cache-status branch September 15, 2020 17:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needed: design decision A core team decision is required
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants