Help

Re: Releasing to additional remotes

Solved
Jump to Solution
2202 2
cancel
Showing results for 
Search instead for 
Did you mean: 

I’m trying to use the --remote feature of the CLI to install my Custom Block into another base, but it doesn’t seem to be working. I’m not sure if I’m doing something incorrectly.

I went through the process of “Install a block”, “Build a custom block”, and saved the appID/blkID, leaving an empty and uninitialized block

CleanShot 2020-09-09 at 17.06.41@2x

Then I ran the CLI commands, with apparently successful results:
Carbonize 2020-09-09 at 5.09.08 PM

But my block remains uninitialized. I’ve tried refreshing multiple times, and I’ve tried running the CLI commands again, and it doesn’t look like it’s done anything.

I tried running just $ block release as well (not specifying a --remote), and my default installation of the block was updated (tooltip indicates “last updated” with today’s date). So it appears it is only the remote option that is not working as I expected.

@Kasra
@Michelle_Valentine

1 Solution

Accepted Solutions
Emma_Yeap
Airtable Employee
Airtable Employee

@Jeremy_Oglesby double checking, are the asterisks in the app***/blk*** screenshot added by you? (The actual block list-remotes command should not redact the ids).

To help debug, could you please check/share these things:

  • Version of the CLI you are using
  • On your custom block installation in the new base, click the name, “Edit block”, “How do I run blocks locally”, “Continue”, and check the app.../blk... shown in step 2 matches the content of .block/agenda_base_test.remote.json
  • Check whether block run --remote agenda_base_test works and allows you to run the block in that installation
  • Check the other block dashboards in your new base to double check the remote corresponds to the installation you are looking at (vs updating a different block in your base)

See Solution in Thread

3 Replies 3
Emma_Yeap
Airtable Employee
Airtable Employee

@Jeremy_Oglesby double checking, are the asterisks in the app***/blk*** screenshot added by you? (The actual block list-remotes command should not redact the ids).

To help debug, could you please check/share these things:

  • Version of the CLI you are using
  • On your custom block installation in the new base, click the name, “Edit block”, “How do I run blocks locally”, “Continue”, and check the app.../blk... shown in step 2 matches the content of .block/agenda_base_test.remote.json
  • Check whether block run --remote agenda_base_test works and allows you to run the block in that installation
  • Check the other block dashboards in your new base to double check the remote corresponds to the installation you are looking at (vs updating a different block in your base)

Thank you so much for the quick response, @Emma_Yeap.

Yes, I redacted the ID’s myself for the screenshot - they list fully when I run $ block list-remotes.

And it turns out I had the wrong appID/blkID… Thank you for that instruction on how to retrieve them.

Using the correct appID/blkID worked.

And now I’m left scratching my head as to where I got the incorrect appID/blkID from… I only installed and copied the ID of one block, that I can remember :confounded: . I must be getting old…

No problem, glad it’s working now!