Skip to content
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

exercising submission in the dev container doesn't leave the submission in the app container's files. #6185

Closed
rjsparks opened this issue Aug 22, 2023 · 7 comments
Labels

Comments

@rjsparks
Copy link
Member

When exercising submitting a draft, the xml and generated formats do not land in a place the app container can see.
In the celery container they appear to be in /workspace/test/id/

@jennifer-richards
Copy link
Member

jennifer-richards commented Aug 23, 2023

Trying to reproduce, I see the files being uploaded to /workspace/test/staging/, then moved to /workspace/test/id/ when the draft is posted. These are visible in these locations both in the celery container and in the app container, but they do not show up on the draft page.

Is that what you're experiencing?

(Just noticed that vscode had spun up using containers I'd manually created, so if it's not what you saw, that might be the cause. Retesting with fresh containers now.)

@rjsparks
Copy link
Member Author

I'd have to repeat the exercise as I've destroyed that set of containers in the interim, but I don't think there was anything in /workspace/test/id/ in the app container. But even if there was, why is it landing there?

But yes, "does not show up on the draft page" is the underlying motivation for figuring this out.

@jennifer-richards
Copy link
Member

It's in submit/utils.py:

def move_files_to_repository(submission):
    for ext in settings.IDSUBMIT_FILE_TYPES:
        source = os.path.join(settings.IDSUBMIT_STAGING_PATH, '%s-%s.%s' % (submission.name, submission.rev, ext))
        dest = os.path.join(settings.IDSUBMIT_REPOSITORY_PATH, '%s-%s.%s' % (submission.name, submission.rev, ext))

where those settings, in the default settings_local.py that a clean vscode checkout sets up, are

IDSUBMIT_REPOSITORY_PATH = "test/id/"
IDSUBMIT_STAGING_PATH = "test/staging/"

whereas, in doc/models.py,

    def get_file_path(self):
        if not hasattr(self, '_cached_file_path'):
            if self.type_id == "draft":
                if self.is_dochistory():
                    self._cached_file_path = settings.INTERNET_ALL_DRAFTS_ARCHIVE_DIR
                else:
                    if self.get_state_slug() == "rfc":
                        self._cached_file_path = settings.RFC_PATH
                    else:
                        draft_state = self.get_state('draft')
                        if draft_state and draft_state.slug == 'active':
                            self._cached_file_path = settings.INTERNET_DRAFT_PATH
                        else:
                            self._cached_file_path = settings.INTERNET_ALL_DRAFTS_ARCHIVE_DIR

is using entirely different paths for drafts. If I change settings.INTERNET_DRAFT_PATH to settings.IDSUBMIT_REPOSITORY_PATH in that method, the draft view finds the file.

@rjsparks
Copy link
Member Author

Good diagnostic change, but not the change to make to fix the issue.
As I feared, we really need to fix this by fixing #6186.

@jennifer-richards
Copy link
Member

Yes, the change was just diagnostic. Short of fixing #6186 we can probably change the values of the paths in settings_local.py to match in a way that makes this work. There's some risk that will encourage incorrect use of those variables but it might be a tolerable stopgap until we untangle that.

@jennifer-richards
Copy link
Member

If I change settings_local.py to keep IDSUBMIT_REPOSITORY_PATH = INTERNET_DRAFT_PATH after the latter is modified and merge the fix in #6217, posting a submission seems to work cleanly for me. That causes posted drafts to end up in /assets/ietf-ftp/internet-drafts/ in the app-assets Docker volume.

@rjsparks
Copy link
Member Author

rjsparks commented Sep 5, 2023

closing this - reopen if there's some action implied that's not already captured by another issue

@rjsparks rjsparks closed this as completed Sep 5, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 13, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants